>> Eric Chung: It is my pleasure to introduce James Hoe from Carnegie
Mellon. For those of you who didn't know, James was my beloved advisor for seven years at Carnegie Mellon University. James is a very, very good advisor.
>> James Hoe: You got your degree.
[laughter]
>> Eric Chung: He's interested in many aspects of computer architecture, reconfigurable computing, security. He's done work in synthesizing DSP cores to hardware. So a lot of different areas.
James is the associate department head at Carnegie Mellon, and very recently was elected as an IEEE Fellow. So that's very, very nice.
So today James is going to come and tell us about making reusable IPs usable.
>> James Hoe: It's over here, too.
>> Eric Chung: Oh, yeah.
>> James Hoe: It's less obvious.
>> Eric Chung: All right. So without further ado, go ahead, James.
>> James Hoe: All right. Thank you. So actually I'll say Eric was a very, very good student. Now, was it seven or eight years?
[laughter]
>> James Hoe: No, I heard a lot of good things about what's happening here, so I had to come out and take a look for myself. So thank you for hosting me, actually both Eric and Derek. And thanks for coming to the talk.
So the talk today is making reusable IPs usable. IP here means hardware IPs, building blocks, you know, so just to make that clear. The rest of the title is nonsense. What I'm going to talk about will become clear in a few minutes, and coming from a NoC perspective. So actually before -- to start the talk, actually I want to do a small demo, okay. So this is a live Web site. You can go to this Web site right now if you want to play along with it.
What this is -- oh. I forgot to introduce my coauthor. So the work I'm talking about is Michael Papamichael, my Ph.D. student, this is his Ph.D. -- current Ph.D. thesis. Work is happening right now. So this is all very fresh work.
Okay. So this is the work that Michael actually did previously. So this is what's called CONNECT. What it is is a network design -- it's a network on

chip design generator. And what this thing will do is allow you to come in and pick a configure, an NoC design, and it will spit out a [inaudible] RTL for you to incorporate into your -- whatever application -- system you have.
Okay.
And it's quite flexible. Right? So here you come in and, you know, you can -- you have a lot of options. For example, here is [inaudible] give you the double ring topology, but here you can actually choose all kind of different thing. You want a mesh, we can give you a mesh. You can change the number of nodes. Right.
And as you make different choices, right, the manual says it's dynamic, it will actually give you is a add or remove additional options that goes with particular options, will guide you along that way. Right.
And also starting with the basic options. There are actually more detail options. So if you are someone who is more familiar with NoC, right, you can actually go ask for more careful thing, things like what kind of -- what type of router, do you want virtual channels, how many virtual channel, what kind of flow control you want. Right.
Now, if you are a black-belt NoC, right, there's actually hidden options.
Which if you're interested, you can actually dive all the way down.
So by having a very, very rich set of parameterization, what this allow you to do is to generate very, very specific NoC to fit whatever you need to do.
Okay. And you think about it, if you go put something in hardware, it's because you want efficiency. And to get at efficiency, you need something that fits. Okay. So the parameterization is important. It's -- you need it both to get the right fit and to cover the full design space. Okay?
And we even have things like -- I want to show you. So here we have some basic topologies. If you don't like the topology, you can actually add -- you know, make one for yourself. So here is actually an add-on tool that allow you to edit -- edit, you know, a specific topology for NoC. Here you go. So you just drag on some random things and play with it. So here's two routers. And I can wire them up in all kind of different ways. Okay. And you have endpoint.
And one of the things this does is that it actually has built-in error checking so that whatever you're able to wire up is actually valid and legal.
Because if you go back to where we started, when first -- when we first did this, what option we gave people is if people want some custom options, we actually had this -- there's a spec. You can write a spec and we generated.
And what we found is, you know, most people are not very careful. Right.
Either -- and so we find out it's actually much safer to actually -- to help them along with a GUI so that we can do some basic shifting and enforce what's possible, what's not possible. So whatever you can generate here, I don't know if it's going to be good or not, but at least just from an operational perspective, it's legal.

>>: So what kind of routing protocol are you assuming?
>> James Hoe: You can actually -- so for this you can fill the table -- you can actually fill a table one by one. And if you use the GUI, there's some basic ones we can populate for you. So one thing you notice, in this Web site, right, we're supporting user many in many, many levels. Okay? So depending on how expert you are in the NoC trade, you know, there's some questions that they're very detailed things you can control, right, and some people don't need access to that. Okay.
And, you know, I'm pretty confident that, right, given the -- kind of the coverage we have, okay, this should suit most people's purpose. And because
Michael, you know, did a good job, right, it's going to be pretty competitive with anything that you if you knew you wanted, you ask for it, you get a pretty good implementation out of this.
So this is the CONNECT work. Okay? And that's the perspective. This is not what I'm going to talk about. What I'm going to talk about is this idea of
IP. So this is just some backups in case the Web doesn't work you can look at the static one. So let's actually get to the talk.
What I showed you is the NoC generator. What I want to assert now is, right, you really should think of it as IP. Right? IP started out as these very simple modules. Adders, multiplier. All the time became more and more complicated. Right? Nowadays IP can be very complicated, something like the
NoC. And at this point imagine if you want to be able to cover all the different corners of the design space in an NoC, it's infeasible to do that in a static Verilog, even if you use the generated -- the generated facility.
Okay.
At this level of complexity, you have to do it in a dynamic way. Right? You have to go through the configuration and be able to generate on demand the design you need. Okay.
So as IP become more complicated, really think a generator is the next IP.
Now, I can ask you the question, right, we saw the tool. Actually, let me -- a quick demographic check. How many people work with NoC on day-to-day basis? So would you claim to be an intermediate or advanced user?
>>: Beginner.
>> James Hoe: Beginner. And the rest of you are less than beginners? Or you would call yourself a beginner?
>>: We had a lot of projects that we retired that we were doing.
>> James Hoe: Okay. Well, actually, so I'll -- the reason I want to ask this, later on it will become clear is, right, what I'm going to talk about

is actually not so important for the advanced users. The most interesting people to me are the intermediate people, more so than the novice people.
I'll tell you why. Right? So the tool. The generator. Right? I hope you agree with me that it's powerful. It does everything you want to do and saves you the work of coding up the RTL yourself. Right? And even if you're advanced user, you can build an NoC by yourself, it's easier to have someone do it for you.
Now I ask you a different question. Is it easy to use? Okay? That's actually a trick question. If you think about it a little bit, you may come to realize the ease of use I showed owe, all this nice GUI interface, it's actually very superficial. Yes, you know, you click different buttons, RTL pops out, and we're even nice enough to give you documentations. We give you a testbench you can simulate and see it work. Okay?
But the reality is starting with an IP as complicated as this, next thing you got to do is take this and put it into your design. Right? Are you really -- will you really be able to integrate to invalidate that NoC without becoming intimately knowledgeable of what's inside. Right? So just because
I gave you RTL, I really only have done a little bit of work for you. For hardware IPs, I haven't really isolated you from all the details that you may or may not know, may or may not want to know.
Another question, right, that take a look at those options. So it's -- since there's no one -- I can't see the cursor. Okay. All these options, do you know what VCs are? Do you know when you need them? Right? Do you know how to achieve what you need with them and then all these -- then we get to the low level [inaudible]. There's a lot of details. I need to give you all those options so you can get exactly what you want.
But what about those novice or immediate user who don't know what they want?
How do they -- you know, has this really made things easier? So this is the kind of thing. Think about this. Hopefully all of you will go home and boot up your computer and go play with it. You go to CONNECT, you ask for NoC.
What do you think is the first configuration you're going to -- you will choose the download. I can tell you what the most -- most ones are. Okay?
Most people get the double ring because it's the default. You know what's number two?
>>: I know what we would download, yeah.
[laughter]
>> James Hoe: Well, unfortunately, hopefully -- hopefully you worry about the same meshes, right, the number two choice meshes. In fact, four by four.
And for the reasons we don't even discuss. Okay. People don't necessarily know what they want and for what reason. Even trickier. Right? You go there, you click something, here's the RTL. You actually got it to work.

It's not good enough. It's not fast enough. It's too big. Too high power.
What are you going to do to make it better. Right?
You already don't know what those parameters mean. Are you going to not be able to dial it in to improve what it does? Right? And then, you know -- then what if you're really intermediate user, do you even know what good enough means? Right? This is kind of the obvious bandwidth latency issues.
But in the real NoC usage, there are actually much deeper questions, right?
Things like quality of service, isolation. How do you -- how do you do all of this without understanding the detail by the time you're done with it?
So we started with moving from static IP to generated IP. Now I want to go to the next step. The next step is, okay, we accept generator as the 21st century IP. It is now a dynamic thing. Now there's a big opportunity to go beyond a structural view of design as IP. I can give you a lot more. Right?
Why not include things like some knowledge of the design options. Right? I can precharacterize -- I can precharacterize some design points, okay, so that for the different requests I know what needs to be done. I can even precharacterize some of the tradeouts so that if you needed to make some choices I can give you guidance.
For those parameterizations, rather than asking you what is the structure you want so I can build it for you, can we not ask more meaningful questions, things that at an application level that makes sense to the user IP.
So, you know, imagine I could ask you how fast instead of how many. Right?
How many -- you ask how many, you get what you get. Good or not, that's what you asked for. Why don't we ask you what is it you really need to do and let me, who build the IP, who understand how the IP should work, generate the right answer for you from scratch.
And you can generalize. There's actually a lot of things, capabilities, X, where the IP author, the one person building the IP, is in a much better position to do the right thing, to do it faster and do it easier. And all those things, by having a full-blown generator, which I can run any execution, I can just embed the expertise, that knowledge, into the IP and make that available.
And all this will make it much easier for someone to actually pick up the IP and use it. And what we're doing is we're kind of shifting the burden from the user to the author who are better positioned and so that those -- the author's knowledge and expertise become reusable as well as the structural design itself. Okay.
So that's what we're going to talk about. Kind of just the demo, the motivation.
What I want now is to tell you a little bit more about what we call the
Pandora project. Right? This is kind of what we think is -- we call it the smart IP. This is the -- kind of the knowledge encapsulated IP paradigm we

wanted to push. Once I go over that, I'll say a little bit more about kind of the work that we've been doing to take the generator, right, we had in the beginning, expand it with these new ideas to make it more powerful and really easy to use.
Any questions at this point?
All right. So all right. So just to level the -- clarify the context here.
So imagine the IP ecosystem where there are users and there are authors, right? And user, these are people who take IP and build stuff. Right?
There's a capability they're looking for, and their job is to integrate.
They take IPs, put them together as quickly as they can to make the function -- the capability happen. They -- they don't -- they don't have to have knowledge and understanding of the application, they may not know the details of the kernels and the primitives, right? That's why they're using the IP.
Separately there's another set of people who has a narrow scope in their expertise. These are -- you know, these are, you know, people who build IP.
And here I further separate them into kind of the domain experts and the hardware experts. Right? There's a set of people who knows the theory, the algorithm, behind what needs to be done. Right? To build an IP, a good IP, there's a separate set of expertise in being able to hack hardware. Right?
If you're lucky, you can find someone with both sets. Sometimes you need actually -- these indeed are two separate people working together. But here, right, you might -- you treat -- well, I'll treat them together. When I say
IP authors, they're these people. Okay. People with deep knowledge of the primitive and the application that the user -- people who just want to use the IP.
If you -- well, what this Pandora project wants to do now is somehow, right, through the IP make the author's expertise available to the user. One way you can imagine is that, right, ideally if I'm building the application, I don't want an IP. I actually want an actual -- the author to work for me, and I can work with him face-to-face and ask him what I need. In that case certainly, you know, you would not go to -- if I'm building something, say, for the DSP core, right, you would never go -- you know, go to a -- go to a designer and say, you know, build me a fast -- a fully [inaudible] this wide with this many bits. Right? You would ask something at the level you understand. I need this numerical accuracy, I need to have this performance floor. I can afford this much area. Make it work for me.
We want to move from this low-level structure view to have the end of phase come up to a level where, even though it's an IP, by going through the dynamic generator, the user can interact with it as if he's interacting with the author himself. Okay. And that's -- and now we can work with the high-level goal requirement, right, and this extra thing we're adding, right, was bridging the gap between what the user wants and the structure.

Now, it may feel like what we're doing is asking the IP author to do a whole lot more work. Right? But I think later on I'll show you a case situation where, right, it's actually possible sometimes to actually do -- at least make the work more efficient. Okay?
What I want to do is now talk about kind of four specific points that we have thought about and that's important to build into this new IP paradigm.
Right? The first I think we touched on already is we want to embed this expert knowledge. Okay. Once the knowledge is part of the IP, we can build -- we can use that to support new interfaces, new capability.
I think the most interesting question is the second one, how do we bring the level of the interface to the level of the user. And there there's actually a lot of different things we can do.
There's some ancillary things, things like instrumentation and introspection, and actually supporting collateral. By this I mean things like test benches, things like documentations, and synthesis strips. Okay. I'm going to run through these four ideas and say a little more about each one.
All right. So number one. Embedding knowledge. So title is IP know thyself. There's really no reason why every user should pick up the RTL and for himself figure out how big, how fast. Right? These things, you know, can all be done, can be precharacterized. Right? And the IP author is actually in a much better position. By knowing what -- because right here we're not talking about general purpose thing. I'm building a generator for a particular design, because I know what a design does. All right. The IT author also know what's interesting and can actually -- has a lot of leverage in sampling the right places and extrapolate where things, you know, doesn't need to be sampled as quickly.
And by having this building information, now, right, the user, as I go through the picked choices, I can get immediate feedback. Going one step further, using this elimination, I can also build -- not even build a feedback-driven search optimization now to -- to work on queries.
And here you can think about two kinds of things. When I say characterization, there are the kind of thing where it's generic to all hardware design. These are things like how many gates, what's the frequency, how much power does it dissipate. Right? These are the more basic things.
But because we're doing generator that's specific for a particular design, we can actually ask characteristics that are much more specific to what the design actually does.
So in the case -- in the case of NoC, right, I can ask these questions that are meaningful only in the NoC context such as saturation bandwidth, latency, et cetera. Right? And also we can even ask even higher-level properties, right, which actually need deeper understanding to extract. These are going from your basic performance counters to higher level counters to something

that actually requires some interpretation and more detailed observation of sequences of events to extract. Okay?
>>: [inaudible]
>> James Hoe: All right. And I don't want you to think that, you know, this is all nuts and bolts. Right? Yes. One of the simplest that you can do, especially with the hardware characterization you just built, right, you have a -- we have this generator, we can search the design space and just run on the cluster to get all the points we need. Right? We could be more -- a little bit more intelligent. Once I have now points, what we can do is actually, because we know the dimensionality of the design space and we even can understand how things react in a particular dimension, from the subset of data points, we can even try to extrapolate to get the coverage, a full map of design space with some interpolation. Right? And these will give you very quantitative kind of things.
Now, right, those are information, but there's also things like knowledge.
When you speak to someone who design NoC, a lot of times there's a lot of insight that doesn't require measurements. They just know. Right? So we can actually without doing measurements, right, a lot of thing you can even build in analytical formulas, maybe less precise, but I can give you faster, more complete coverage.
But there's also things that are much more ad hoc. If you tell me what kind of traffic pattern you have, sometimes there are just no good answers that we can jump to. And for this ad hoc knowledge, right, especially with a novice user who can't tell you very much, can't ask very precise questions, that may be all you need to give the best answer possible to an imprecise question.
Okay. So all these are a possible. Yes.
>>: So you haven't talked about dimensionality, the curse of dimensionality.
>> James Hoe: The what?
>>: The curse of dimensionality. It just a term for it. I mean, when I have a lot of parameters and a piece of ID, and especially as things get more complicated, it's just very -- it becomes intractable to explore and characterize the entire space. Are you going to talk about that? Like even in an NoC --
>> James Hoe: Not -- not in deep --
>>: Like every parameter I don't -- I don't have [inaudible] even if it just -- like I can't brute force -- like I don't know how to construct that mapping for all the combinations [inaudible] like if I want to just find the right answer.
>> James Hoe: Right. But the point is, you know, it's actually much easier for -- right. Certainly you don't -- the user who's not the NoC expert,

that's the wrong person to ask to do that. Right? As the person who built the NoC who works, you know -- who understands the NoC deeply, right, there you have leverage. And by dimensionality, you know, we're talking about the different parameters. Okay? That's a very thorough parameter, right? If I know to expect a behavior, then, you know, I can have pre-knowledge on, you know, there are interesting regions, there are boring regions, and I can skip to look for the interesting regions. And so I don't have to do a blind search across everything because I know what's going to happen.
>>: So you're sending the IP author to actually do these sweeps, to essentially --
>> James Hoe: Of course. That's the whole point. Right?
>>: Okay. But, I mean, at some point you're going to start assembling these
IP blocks, and there may be something that the IP author didn't consider which the higher-level assembler would be okay with. So, for example, if I was building an NoC, most NoCs are losses, right?
>> James Hoe: Right.
>>: But, you know, I might be an application author that says, look, I'm okay with packet drop, you know, in these cases. And then, I mean, how do I then push that back into the IP or the IP generator?
>> James Hoe: Well, the IP -- right. So, remember, there's no magic.
Right? When I say smart, right, the smart came from somewhere. Right? The
IP -- the smart IP will only do what the author anticipated. And you have to assume, right, whatever the author choose to export is what the author deemed important. Right? And you -- and so if you come -- right, if you come ask for something more advanced than the author, well, then that's a different question. Okay? If you ask for something that hasn't -- doesn't exist, well, there's nothing we can do about it.
Okay? But I think the -- you know, the author will want to try to be as complete as possible. Certainly we can't cover everything. But I think -- also I think at the same time, right, hopefully the author actually filter out the frivolous ones as well. Right? These -- you know, these are the important dimensions. There are a lot of other options I'm not even showing to you because I -- as an author I don't think it's important. I don't even want to tell you, right?
And then taking advantage of my knowledge. Well, certainly you agree, well, whatever difficulty you're pointing out, it's even harder for the person who didn't build the IP. Right? The author is the right person to go after this problem. Okay?
And I always talk about it's -- don't imagine that I need to give you the perfect answer. That's not the point. I'm using the IP. What I -- as a user, what I want is something better than I can do myself. I want something

that's very close to the best I can get, right, in real designs, and I don't need -- you know, it's not about finding the highest point. I just don't want this point. Okay. And you as a naive user, you're clueless. I just need to -- if I just nod you in the right direction, you should be happy with anything. In practice, you're pretty happy with anything in that space.
Right? You have to -- you have to have the right mindset about this.
Okay. So this next point is raising the level of abstraction. And, you know, I describe this, you know, don't ask me what I don't know. Okay. You can ask me all you want about this and that knob. If I don't know what they mean, it doesn't matter what I put in there. Okay.
And this is a problem with -- this is kind of the paradox of IP. I need to be richly parameterized, otherwise I can't get exactly what I want. If I can't get exactly what I want, kind of defeats the purpose to put it in the hardware. I want the efficiency. But then things get complicated.
By going to generators, what Pandora wants to do is move from structural parameterization to goal-oriented parameterization, particular, right, parameterization expressed at a level that makes sense to the application.
So I mentioned earlier, you know, how fast, things that have numerical accuracy. Right? These are the requirements and goals the application user care about. Even though he -- that he or she doesn't understand how to turn the knobs to get there. Right?
And sort of imply with moving the abstraction, this -- now we created this gap. The difficulty we introduce is somehow this built-in expertise knowledge need to on behalf of the user be able to coordinate those low-level structural changes to achieve those -- that goal. Okay. And this is where that knowledge, the characterization we built into it can help drive this process.
Right? Either from just, you know, ad hoc knowledge, okay, this is -- if you want nearest neighbor traffic, pretty safe, just go with this, this, okay.
To more personalizing where I can actually allow -- work with detailed heuristics or even allow the user to write queries and then based on my map do an optimization search for that kind of thing. And this is example where once I've taken the knowledge expertise built in now building more intuitive interface for the user.
And here also they can take many different forms at different position. And here because I'm interfacing with the user, right, what I really want to do is match up to what the user can do. Okay. What high level means depends on what the user's level of expertise is. And you can imagine there are two kinds of things. Right. One is kind of the straight configuration, right, here I need NoC, what do you know about it. Okay. For a novice user, it may be very simple information.
For that, the configuration really should just give you three choices. You know, large, medium, small. Fast, you know, high power, low power. Okay?
For a novice user, there's not much more you can do. Okay? For the more

advanced user, now you can get into these where you actually have -- imagine having a language, you can actually write queries. You know, make it this fast, make it as small as possible. And then, you know, requiring actually a search engine to actually go through the optimization [inaudible].
You can go to something more supported, something like a tuning interface.
Here you have to imagine the example where you started with the design. You tried it out. You found out that it's not -- it's deficient in certain ways.
Then you say just give me a little bit more performance, give me a little bit more bandwidth. I need the thing to be a little bit smaller. Okay? Or more extended, right, we can even have built-in ways to make tradeoffs across things.
So all these things now -- so as the user -- at the level the user understand, they can ask what's what more -- what more's needed, let the author and the search engine do the hard work. Okay? All right.
Next. Number three. This is what we call instrumentation and introspection.
Here, you know, this -- I'll tell you what I mean by those things before I talk about them. So instrumentation, these are basically performance counters. Here we're simply going in and measure different -- you know, different event, different counts. Okay? And when we use introspection, you're using it to mean something deeper. Taking these raw data, actually try to make sense of it. Try to extract high-level information for the user.
Okay.
So here I give you some more example, right? So, again, these are the things that if you as a user had to do, all right, trust me, you would know the IP line by line before it's done. Right? So it's unrealistic -- it's very useful, right, but it's unrealistic to expect the user to be able to do this on their own. Right? So why not ask the author who actually has deep knowledge of how the design works, make him do it and let the user simply choose what to include and not to include.
And here [inaudible] in addition to the -- kind of the basic performance counting, the result now, the IP author can also help with interpreting the data to return those high-level feedback, all right, that's meaningful to the user.
And now -- right, so now instead of having just IP, you know, this really a black box IP, right, imagine the IP can actually tell you, you know, you're sending a packet right now but your protocol isn't quite right. Okay? How does the author convey that information to the user in the stack of documentation. Instead, what I can do is have built in a monitor that can dynamically check with those things. If you ever make a mistake, I slap you on the hand.
Now, one thing that's important here is that, right, so realize everything we're talking about, because we're generating things on demand, this is not a single Verilog file with [inaudible]. This is actually running a full-blown

program. And generating hardware design from it, we can generate very, very specific kind of things. Okay.
So we don't have to worry about, you know, I put this in but this, you know, doesn't make sense across the board so I have to limit myself to things that work everywhere. I can do case by case and instrument and look at things -- you know, very specific things as they pertain to that particular instance of
IP. I can be very detailed, very powerful. And -- all right? And you cannot ask, right, is this ancillary or should this actually be part of the design. These introspection instrumentation mechanisms, I can actually make
[inaudible] sizable. Why not. Right?
I can use them in simulation, but if you're doing FPGA prototyping, wouldn't it be very nice to be able to run this at speed and look over billions of cycles and track down something that -- a mistake that rarely happened.
Okay. Why not even -- you can even imagine putting this in a deploy system to help [inaudible] because everything's in hardware, it doesn't have to be -- you know, doesn't have much be overhead and doesn't have to be that expensive.
So these -- you know, but -- you know, these are all very powerful things.
If you can do it specifically per instance, we can do it very efficiently, very cheaply, and give you exactly what you need to know.
All right. This is the kind of the -- this is the thing that, you know, a little bit -- little bit lighter, but I think, you know, again, this is important. When I give you an IP, there's actually a lot of support I need to get it to work. Okay. So this is kind of, you know, do you want to use self-service or full-service gas station. You know, like give IP, yes, I should give you documentation for sure, right, I've done this [inaudible] for a while.
Giving people simulation test benches that gives one example of how the interface work is better than anything else in the world. It answers a lot of questions. People can actually run it and say, okay, it does work. And it works like this. If I can reproduce this, at least I know that one instance should work.
And you can actually extend this, you know, to -- by the time you're done with design, there's a whole lot of other things, things like synthesis scripts, right, tools to help you configure IP, tools that help you process those data logs to output the high-level information. All these, right, is very important to lower the barrier entry for someone to really be able to come here, pick out an IP and start using it without having to become knowledgeable of what's inside.
All right. So that's the high-level picture. Now I just want to start going in and give you some -- more specific examples of what we have done or, you know, will do in the context of CONNECT.

Any questions? Any challenges? All right.
Okay. So just some quick things. So here, again, characterization. I mentioned earlier, right, there's the kind of thing where that's generic cost hardware. This is actually easy. Especially, you know, with the brute force approach. I can just go and just twiddle all the knobs until I get a table.
Where it gets interesting is I don't want to do that and I really can't afford to do that. And also I do this for my library. You may not be using the same library as me. So as a research problem, what we're looking at here is developing the methodology where I don't -- I can give you this, what I can also give you is the script to help you traverse the design space. To pick the points for you, you generate the data points on your own cluster with your own library. Okay. But by using my script, my choice of points, you can generate less points.
And next step is I can give you kind of the interpolation procedure so that you can -- you know, even with -- you know, so you actually -- you can go -- use -- extract -- get a map -- get a detailed knob map of the design space with as few points as possible. Okay. That's what we can -- that's -- even that's possible to embed into a -- into an IP at this next level.
So this is kind of thing that's easy. Everybody knows these things. But if you think about it, right, it's actually very -- it's a very incomplete story of what IP does.
I give you a table like this. Say it's totally complete, it's perfect, you know, it's really not appropriate to simply walk around and pick something that gives you the right number. Because for IP as complicated as NoC, right, there are a lot of other requirements that don't show up here. You can pick the smallest, fastest topology here. If your design requires something like, you know, data lock freedom, that's all hidden here. You don't know that. Okay.
So we also need to kind of now do the characterization at the next level, taking into the information, the knowledge of the particular instances of the network you're generating. Right. So now, right, we can look at things like, right, metrics that are specific to network on chip, okay, and by doing deeper -- you know, more detailed analysis, looking at model -- synthesizing for multiple points, multiple measurements, right, we can also extract qualitative properties while on network. I can tell you what is the traffic isolation property and what's the quality of service property and help you in this high-level design knowledge.
All right. And this, I do this next point, the raise level of abstraction, I keep on going -- I think this is what -- this is what the richest -- the research problem are. Right. So I mentioned earlier what you want is to have many interfaces match to the different user expertise. So in the beginning I say, you know, if you're an expert, I don't really care about you. Right? You should be perfectly happy with my current CONNECT

generator. I assume you as an expert knows what you want and you get what you want. Just go to CONNECT [inaudible] exactly you're done. Everything else, you know, you can do everything yourself. Right?
For the novice, also not very interesting because, you know, you don't even know what you're asking for. So it's, you know, I can give you some help, but in a very imprecise way. It's really in this intermediate region there's a lot of variation, lot of different things we can do.
So something we're trying right now, right, is to work with something, doing something more quantitative. So one of the things a lot of people have been trying to -- automating NoC design, if we can -- if we have a streaming base application, especially in SSC community, right, if I can represent the communication pattern by a graph, weighted graph, right, then there's a way to build exactly what you need. Right? Or I can work with something that's -- something other than [inaudible] the more you can tell me about your particular requirement, your particular -- your traffic, it gives me more information to work with to come up with some more specific design.
Right?
And then we can also work with things, you know, a little bit qualitative, but still, right, deeper knowledge than what a novice may know. If I know my application is mostly nearest neighbor, you know, there's things I can do.
If you know where the hot spots are, you know where the traffic actually needs to happen, then I can provision exactly what's needed at the right place rather than having to do it in a general -- a wasteful, general way.
But this last part is where we're actually spending the most time thinking about, is to coming up with a framework we can actually let the user do query based. These are kind of the goal-based parameterization. And here the idea is that we need to let the user ask questions, like, you know, I want it to be this fast, make it as small as possible, and also I need it -- and while maintaining this bandwidth. Right?
And keep in mind none of this is magic. You ask for something -- you ask for something that can be done or you get back an answer that says no. Okay.
And also you can't ask for things that the IP author has chosen not to support. I'm assuming, you know, the guy doing the work has to make the decisions. I know that in NoC I know what's important, I know what you as a user should be thinking about, work within my framework. It's a limitation, it's assumption, but, you know, that makes this work possible. Like, you know, it's not magic. You can actually do this.
All right. So the runtime monitoring, right, here is -- these are the kind of things -- we actually have it all built in already. We use a lot of these things internally for debugging. We just don't export it yet. Okay.
So now we got -- we actually can do very, very detailed instrumentation. And like I said earlier, because we can add these things specifically to the topology, to the design choices, you know, we can do very precise

measurements, because we don't have to worry about measuring things that doesn't exist or measuring things that are meaningless.
Okay. And one of the very powerful things, so we can measure both the basic things, we can measure sequence as the temporal things, but I think one of the more -- so these -- for temporal things, let us look at more complicated behavior. Okay.
But, nevertheless, right, these are just still events. The really powerful use comes at the next level where I take -- I look at those events and extrapolate feedback that the user understand. I mentioned earlier I saw things like somehow you do everything -- the user did everything they think is correct, but in operation something doesn't work. Okay? Something -- you choose the wrong full control, right, you know, the -- your routing packets, right, packet never -- packet never seem to get from A to B. Right?
So these are the kind of things we can look at and say, you know, when you fill the router table, we do this added check. There's no way to get from A to B. At that point I don't know that's because you know there's never a packet from A to B or you made a mistake. But if at runtime you send a packet from A to B, I can't route it, right, now I can come back. You made a mistake. Right?
And even more specific, like, you know, just similar things like the handshakes. Right? You're sending a packet, your timing is off by a little bit, you know, you made a mistake. Go back and read the documentation one more time. So we can help the -- we can help the user with all these -- by looking for these high-level events or properties.
That would be very difficult for the user to reconstruct by themselves. One, they may not know how to look for it. Two, they may not -- they would not know how to insert the necessary mechanism. And these kind of things, it's very, very powerful when it comes to debugging. And then we actually, you know, this -- all right. We don't -- we have these things in our design, we don't export interfaces, but we have had example where our user comes back and say I'm getting this warning message. Right? We look at it, we know exactly what's going on. Either we made a mistake or they made a mistake.
Both has happened in the past. You had a question earlier.
>>: I was just -- you know, going back to your previous slide, you know, what you really -- I don't know if it's this slide. It was basically that you want the IP author to kind of define the range in which you're going to be operating in, right? It's kind of don't ask me what I don't know. But the IP author might not know everything about his own IP, right, that's a possibility as well. So if you ask a question like find a minimum area that can [inaudible] whatever, the author may say, look, you know, these are the areas that you should look in, but it could be that another configuration he has actually he supports could be --
>> James Hoe: That's right.

>>: It could actually be better. I mean, are you hoping to provide provision for that, or you're just going to stick with what the --
>> James Hoe: You're saying what if I don't give exactly the best?
>>: What happens if the IP author doesn't know everything about -- it may be that his IP composed with something else or he didn't -- he was tired that night when he was writing out, you know --
>> James Hoe: Okay. The way I'm picturing this, you know, like I'm -- you know, is if I'm personifying the IP. Right? Read in IP, imagine, you know, if I had my buddy, you know, my -- actually, my graduate student, Eric, go fill me this NoC --
>>: Yeah. So you're trying to replace Eric.
>> James Hoe: I'm trying to replace him. Okay.
>>: Yeah.
>> James Hoe: Now he can make the same mistake. How do I fix that. At the end I needed to either accept or don't accept. Right. I needed to get the best I can out of either a real designer or the IP. Right? It's -- it's --
I don't think, you know -- it's better to give a better answer. I don't think it's definitely not necessary to give, you know -- to find the global maximum.
>>: Okay. All right. So you're just going to trust your grad student.
He's going to tell you, James, this is how fast as it's going to go.
>> James Hoe: Well, when you have a design team, hey, go build me this. Do you -- are you implicitly saying, hey, if you don't give me the best one, if
I find out tomorrow there's a design that's 10 percent faster, you're fired?
That's now how things work. Right? You know -- you know what's good enough.
[laughter]
>> James Hoe: Right? When you give an engineering spec, there's a functionality. What's good enough. You meet it, you're done. All right?
That's -- that's -- that's -- you know, that's how you use these things.
>>: I guess what I'm asking is you could imagine having, you know, something which would go and try to learn the knobs, maybe even better than the IP author did himself, and then potentially try to do better than the kind of the range that --
>> James Hoe: No. So that's why, right, if you want these guys, we have a command line interface. You can build your own search engine to traverse the design space to find things out.

>>: All right. But that's not [inaudible].
>> James Hoe: But these people, I don't have to worry about.
>>: Okay.
>> James Hoe: They're happy with the tool we have today.
>>: Okay.
>> James Hoe: Right? The generator is already useful to them. It's the rest, you know, these other people, right, who needs to build a design, who needs the NoC to CONNECT things. But they themself are unable to build NoC.
Okay? That's an IP. But when I get an IP, I need more than RTL. I need more support so that I actually -- actually use it without having to learn the whole thing from scratch.
All right. So I think we're almost done. The last point, supporting collateral. I mentioned some examples earlier. I'm actually, you know, kind of going a different direction here. Right.
If you think about the CONNECT, right, so I already, you know -- if you believe me, generator is the new IP. The next step is taking IP to a service. Everything's a service nowadays. IP's going in the cloud. It's not -- it's not completely facetious, right?
What is CONNECT? Think about you as a user, you want a NoC today. All you need is Internet connection and a browser. You can -- you can -- you can -- you get it, right? You don't have to go and buy the right -- have the right
PC, the right version of the operating system and get everything set up.
Okay? This is another kind of thing where we can make the IP easier to use.
We do lowering the barrier to entry.
The benefit to the IP author is since everything is with me, right, the user just sees the interface. I control everything behind the front door. If I, you know, make improvement or if I made a mistake and you just fix it, these -- all these things can happen transparently behind. Right? I just -- so -- right now we actually -- when you generate the design, we actually give you a string. So it is -- you know, so even as we make patches, you can come back with a string to actually -- you know, it is -- you can deterministically get back whatever you asked for the last time. But if you don't do that, then, you know, you automatically benefit from all the changes. I don't need to go out and send everybody a patch. You all come to me.
And even if we need to run this in a way where you run on your system, okay, it's better for you to call from your program in a socket into my program.
Rather than having you to install, we build the whole environment just so you can generate this IP.

And also by doing this collectively, this, you know, this is cloud speak, you know, so I can crowd source. I know what people are asking for. So over time I can build up knowledge about, well, I can figure out what people are doing. But I can also in a way infer what are kind of the -- everybody's doing this. Maybe something -- there really is something good about this, I should look at it. Okay. Then we -- you can build knowledge over time that way.
Okay. So that's it. Just want to quickly summarize. So imagine what I said. What I said today is, right, what we have today is kind of the naked
IP, the structural RTL. Right? And this Pandora, what we want to do, right, first add knowledge to it. Right? Once you add knowledge, then you use that knowledge to build things around it, to build the right interface, the right capability. So now you wonder why we call this Pandora, right? It's a box to keep the evil inside.
[laughter]
>> James Hoe: Hi, Michael. I did that for you. All right.
Now, it's ongoing work. We're thinking about this constantly. Those are kind of the thoughts we have. There's still a little bit, but there's actually a lot more questions we can ask. One of the simple ones, we picked four things that we think are most important first thing we should do, but you can imagine X. There's a lot more things you can -- but what else can the author do on behalf of the user?
There are actually kind of deeper extensions. Right now what I discussed today is smart IP. It's your one IP. You pick it up and you use it. And the design, usually multiple IPs. Okay. And when I build an IP, it's actually hierarchy of IPs.
So I think at some point we're going to run into the question, is to really make things easy to use, developing some standard interface schema where to make that composition itself simpler. Now, if you do that, you can imagine something even more powerful. Now I got all these smart IP who knows their characteristic in the way they also know how to tune themselves. Can we get to the point where the IP to CONNECT that can tune themselves.
So imagine I'm building -- I have hierarchy IPs. At the top level I ask -- I need -- I don't care about area, give me a fast one. And that design goal can percolate down, propagate down to the lower level IPs. Each one based on that goal will make the choices so the whole design is tuned and optimized automatically. Right?
And, you know, again, this doesn't have to be magic. I can remember the IP author is involved, right? He's doing a lot more work. So in this -- in this example where you have the hierarchy IP, right, I'm building current IP,
I'm importing IP below me. I'm deciding what goal-based parameters that are

meaningful to the user, right? I have no control over what's exported to me by the IPs I'm using. So I have to inject my knowledge, my expertise to do that translation to close -- to bridge that gap.
So all this, right, whatever seems like magic, is actually the IP author's knowledge and expertise being written as a program inside IP generator.
Whatever the IP author doesn't know, the IP's not going to know either. It is a limitation. Okay. I think the next thing is also like so now if you embrace this idea, generated-based IP, IP with much richer capability interfaces, well, Verilog is definitely not good enough.
So now we can ask what is a new kind of design framework that supports this kind of interleaved development where it makes it possible to build generator and to embed all these [inaudible]. So, example, Mark [phonetic] with
Stanford has been working on this genesis framework. It's very -- it's something very, very good for this kind of thing. Bluespec is another example where it's a structural language but there's actually -- there's a full programming language behind that. You can use it to express meta-information, meta-knowledge and build capabilities on top of that.
Okay.
And so, you know, we just got started. You know, I think all these will probably take another few more graduate students, but we'll get there eventually. Thank you.
[applause]
>> James Hoe: Any questions?
>>: Yes, I have a comment, or maybe it's a question too [inaudible]. So it sounds like a software problem to me. It sounds like the problem that you're writing a big piece of software, and you have lots of software engineers that don't talk to each other working together. How do you make sure that group A can use the it guys that are exposed by group B and the libraries from group
C and proprietary cloud service D and all that stuff? So you might find inspiration in software engineering community, which seems far away from this, but I think might be closer than at first glance.
>> James Hoe: No, actually I agree with you entirely. And maybe because I'm a hardware person. I actually always imagined these problems are much better solved in software development.
>>: Absolutely.
[laughter]
>> James Hoe: Okay, you guys could argue, but I also think it is in a way simpler in software simply because the dimensionality is simpler, right? A function calls a function call. You know, I can give you two Verilog modules

with the same, you know, line-level interface. But they can do completely different things because of some timing assumptions.
>>: [inaudible].
>> James Hoe: And also because of optimization -- there's many more dimensions. I want, you know -- there are many more dimensions on what's good and what's not good.
>>: I think that might depend on the software, because --
>> James Hoe: I understand.
>>: [inaudible] known as this huge perimeter, perimeter space problem too.
The second thing I was thinking just along those lines is if you're trying to find misuses of these IP blocks, that's really in the last few slides, one of the things that made me think of is also from the software engineering community, is look at how it's been used over and over in lots of other places, and if you see something that's way different from how all the other, you know, parts of this program, you know, piece of hardware, all the other uses of it in the world by any other user are different, then you might want to, you know, either produce a warning or automatically change the parameters or something else.
>> James Hoe: That would require some of the IP get back to me.
>>: Yeah. Yeah, it absolutely would. You need to --
>> James Hoe: I'm not sure the hardware designers would like that.
>>: Well, you talk to -- you talked about the cloud and stuff. Maybe there's --
>> James Hoe: Well, you know, if there is, you know -- there is still once
IP leaves, you know, they own it. But I -- I understand what you mean. So there's definitely a lot of parallel between what I'm saying and what the software engineering community have done. And I want to talk -- all right.
You know, I actually I should research more, because I have always naively assumed things are prettier on the other side.
>>: I think they might be just as ugly, but they [inaudible].
[laughter]
>>: Well, just to pick up on that for a moment, we -- if you look at the domain of people writing, say, native code in C++ versus managed code in Java or C#, in the C++ code community, if I'm going to use your module, I have to go and look at the source and see what your mailing management system that you're using is, what your error handling discipline is, et cetera.

Whereas in these more modern frameworks where there's been some rules or consistency that's been driven down across the entire design, you don't have to do that so much. I know you're all using the same memory allocator, you're all using the same exception handling facility, et cetera, and because that low level standardization of basic facilities has been done, that makes the composition easier and safer. In fact, sometimes too easy. I can now use your code without reading it, and that's not necessarily [inaudible].
So in the hardware world, there's so many more problems with compensation components, underneath a node, you know. If you're going to use a memory controller, I'm going to use the memory controller, that can't be abstraction anymore. It's got to be brought up into the -- into the composition space.
And I think that's, you know, just this huge problem, because if this is going to go anywhere, if you're going to have the design productivity you get from composition in reasonable pieces, it's these kinds of challenges of having better composition abstraction tools than just binding the ports together.
>> James Hoe: Right. And I think this is where the introspection part is very important, right, because when I think about composition, right, it's never -- the problem is never from the things I thought about. And fortunately the things I have thought about tend to be the common case. So most of the time it works. Every once in a while something I didn't think about happens. And performance-wise it may not matter. Correctness-wise, if
I can detect it, it may not matter.
So I think -- so already -- so having -- that's why I said introspection becomes a very valuable tool to address that problem. If I can check things for you, right, the author says by either checking -- actually bounding what's -- what's -- what's reasonable, I -- you know, I can -- in the practical usage, right, I can address the composition problem.
>>: The higher level that you can capture the design intent and then let those parameters [inaudible] --
>> James Hoe: I think that's right.
>>: Take it out of my hands. So I don't really want to know what network topology to choose at all. Right? I want to say here is my workloads and here are the nodes injecting traffic into the system. Would you please search the design space for me [inaudible]. I may not even understand how that workload is manifested in terms of words or [inaudible] guarantees.
>> James Hoe: Right. So I think depending on how precise a request you can make, I can give you a -- kind of different levels of precise optimization.
>>: But those require the system is -- you can get the application running on the -- on the NoC generator conveniently.

>> James Hoe: Right. It's actually --
>>: It's a big if.
>> James Hoe: It is actually a property of the current generator, right? If you choose the same node and same handshake, you can choose whatever you want inside, it works. And so if you're using -- people have written down research without work where, right, they can go in and it becomes very easy to swap -- substitute different things. So I think -- so I think all of -- you just kind of -- it's go beyond, hey, here's an RTL. Let me give you everything else you need and --
>>: You reminded me of another one that's just a fundamental reduce problem, which is programming languages, software I can make a function call and it will work. Sometimes it's a foreign function interface to make the
JavaScript world call [inaudible].
In the hardware world, your NoC will have a certain concrete way of bundling the handshake into doing NoC. And unfortunately my IP that I got from someone else that wasn't written to your bus interface specification, I now have to write a glue thing to join these two lines together.
So I don't know -- I haven't seen any progress in the hardware world on common IP composition except for proprietary AC SI interface or whatever.
But really -- I don't know if in your experience when people use CONNECT, do they say this is great but I'm trying to hook it up to an on the peripheral so now I need an AC SI-to-NoC CONNECT adapter and so forth?
>> James Hoe: [inaudible] so we choose --
>>: [inaudible] there isn't enough --
>> James Hoe: So I think we choose kind of the lowest common denominator, right, so we try not to take positions on -- so it's like if you look, you know, so we -- the interface is -- it is very generic. You know, you send packets and [inaudible] comes. Okay. And then if you want to connect other things, we've done this, [inaudible] done this, you write wrappers around it, and that's, you know -- that become -- that can either be something you write by yourself or someone -- I can imagine someone write a generator for that.
>>: Right. Because that's a tax on composability.
>> James Hoe: Yeah. And then I think in this kind of thing to why I think the problem has to be both easier, a little bit -- at least easier in software, and I think certainly I think people probably pay more attention to it. Right? I think just the way we've been building -- the way we've been designing hard -- building hardware, we kind of just -- we just deal with it.

>>: We didn't used to have a function calling conventions, I write assembler, you write assembler, and we write stuff that moves my
[inaudible] --
>> James Hoe: That's a long time ago.
>>: So we gave up some performance.
>> James Hoe: That's right.
>>: To get that common C calling convention on this platform, and then we derived --
>>: [inaudible]
>>: Yeah, well, that's fine.
>>: You just argued against it.
>>: No, no, no, I'm not arguing against it at all. I'm saying we haven't done -- we haven't achieved it in the hardware design community. There is not a common glue between modules. If you have to go and do the port map yourself [inaudible] different clock convention or whatever.
>> James Hoe: It's a definite problem. You're right. But I think if you do it right, I think you can do very powerful things if you got that right.
>>: You seem to think it's fundamentally harder to do in hardware. I'm curious if you could say exactly why. What part of this problem in hardware do you think makes it fundamentally harder than the problem --
>> James Hoe: That the IP -- the abstractioning, IP abstractioning, right?
If I look at the IPs today, take the NoC, I just don't see how I can actually use it in the design without having to look inside by the time I'm done.
Okay. Whereas, you know, I work with -- I work with the Sparrow [phonetic] group, so the other IP [inaudible]. You know, there are different FTT -- you know, there's FTW, there's the [inaudible]. We have different interfaces.
But at the end of the day, they -- you give your pointer, we know what that means, and you make the function call. The abstraction is a lot -- the function call abstraction is a lot cleaner. A module, a Verilog module is not a function. Right. Because there's -- besides what you can see, there's too much implied understanding that's needed.
For example, the handshake is an easy one to think about. Take two modules, exactly the same ports. It doesn't mean I can swap them. Even if the ports [inaudible] mean the same thing. I can't swap them because the timing's off by a little bit, everything can be off. Okay.

And the other problem with hardware is, you know, everything's happening at the same time, I put two things together, they may enter at a place that you never expected. Okay. And I think that was -- especially with serial sequential software, it is simpler. The abstraction is much, much harder -- much strictly defined.
>>: So it sounds like what you said is lack of standards and poor abstractions.
>> James Hoe: Right. And you think deeper, why do -- why do hardware designers do all those crazy thing, is what you said earlier. And, you know, because we're unwilling to give up anything. The reason we have all the different timing, all the crazy interfaces is every time we're trying to squeeze out the last bit, the last frequency. And so all the variations comes out. Wherever we can, we grab it. Right. And software, I think it's -- we accept calling conventions. You know, it may not be the perfect fit, it may not be the most efficient thing, hey, I can call your function, call my function.
>>: Yeah, I mean, go-tos are a lot faster too.
>> James Hoe: That's right. I think the hardware, you know --
>>: [inaudible] having that flexibility. And so hardware is an invariable level of abstraction because the cost of having the higher level abstraction is important to me. And so having the flexibility of saying, oh, well, okay, you know, in fact, every NoC that you might have is going to have an end port monitor in front of it, so you keep the plug-ins, as many as you want, so
[inaudible] incredibly high as compared to [inaudible] actually be just
[inaudible].
>> James Hoe: Just right.
>>: [inaudible] I appreciate the goals [inaudible] the third [inaudible] what I have a problem with.
>> James Hoe: Is what? You have a problem with?
>>: What's in it for me? You've done all this work, and now I have to do it again and now start from scratch. You all these rules and these goals.
>> James Hoe: Right.
>>: You have a few examples in there, and I can appreciate that. But this framework thing, that's what I was expecting you give, s that there is this tool that does the nice [inaudible] for you.
>> James Hoe: Right.

>>: We built it or used it and we found a better way to use it or all this.
Particular metric and introspection is -- seems to be very general. You really should be putting that in there and your -- that sort of thing. So what are specific rules or specific tools that I can use?
>> James Hoe: I understand. So I think -- yeah. So [inaudible] two answers. Right, the first one is I think there are people working on tools like this. I mentioned the genesis tool from Stanford and the Bluespec framework from the company.
>>: [inaudible] is the tool that --
>> James Hoe: No, I'm saying these are moving the right direction. Okay. I think the point you're making is well taken, right. I think there is an inherent contradiction, right? So the reason my ability to give you this powerful generator, this smartness, the only reason I can do it is because I have narrowed the domain. Right. So all of the knowledge -- there's no -- there's not infinite knowledge to deal with and there's not infinite variation I need to go through.
So Pandora, I mean, really, you know, this is lot of cheap talk. This is everything. Right? I could have just told you this and you go figure out what you want to do. But -- right? But I think but for every -- but for each IP clot, IP family, this is what you should do. And I can't help it if that stuff's not generalizable. Because the only way this works is because it's not generalizable. Okay? But doesn't mean -- but it doesn't mean we shouldn't do it. Right? For CONNECT, having done this, I made the world a little bit better. But if you want to build a process generator, good luck.
Do this for me. You know, that's an inherent contradiction I can't help.
>>: So, I mean, this is a great vision. But it's so far away from where we are today.
>> James Hoe: What do you mean?
>>: In the sense that this is talking about sort of automatic [inaudible] with at least some sort of intelligent [inaudible] feedback. Today we have pretty much static IP. And [inaudible] --
>> James Hoe: No. That's not true.
>>: We have much of it is static.
>> James Hoe: Simpler stuff.
>>: It's simpler and the number of knobs is smaller. Maybe memory
[inaudible] things like that are [inaudible]. And any customization has always been more troubleshooting or what have you, is done mainly it's I talk to IP, some engineer from the IP vendor and say this thing's not working for me and then we work together and things work out. Is this an all-or-nothing

proposition, this philosophy that you're -- are there -- are there things that you can take away from this and try to bootstrap where these much more simple marketplaces for IP can sort of go towards to get closer towards this
[inaudible]?
>> James Hoe: So right now we're going after, you know -- imagine simple complicated IP, where this is where, you know, where it's most valuable.
Okay? And I think the grand -- the grander vision is this. I want all IPs to be dynamically generated so I can -- this composition ability happens.
Right.
And that's much further down the line, but, right, it's not so far away, right, because if you look at what people -- you know, when you -- you build
SOC, you're composing these IPs. It's a little bit like we use build model -- build boards with chips on it, now it's do on a die where we're taking things that exist that works, we're putting them together, right.
And I think another way to look at this -- I'll show you one slide, this kind of a backup slide. Right. How many people have seen this picture before?
Right. This is kind of like a very old ITRS roadmap [inaudible] speculating, right, this gap, the growing gap between what we can put on the die and what we're able to design by current methodology. Well, current in the old days.
Right?
And what you see is at some point the gap got big enough we don't -- you know, we switched somewhere from schematic to Verilog. At some point
Verilog's not enough. Okay, we use IP. More and more IP reuse.
What's happening since then is that it looks like we solved the problem. But what's happening is, right, the IP has caught up to the ability of what we can put on a die. But this IP itself is becoming a complexity. How to configure the IP correctly is becoming a very difficult problem of its own.
Right? And, you know, it's -- you can't just keep on building bigger, bigger chips with more IPs, more complicated IP. Right? And we need somehow get underneath this problem as well.
Does that make sense? I mean, just look at this, right? Like I said, whatever ease of use you perceived, if you think about it, is very superficial. It will still take, you know -- take you a long time to get this into your design [inaudible] can I help you with that.
>>: [inaudible] what is your [inaudible] to a FIFO generator?
>> James Hoe: What do you mean by --
>>: [inaudible]
>> James Hoe: Okay.

>>: This [inaudible] FIFO generator and do everything that you need to do, the debugging, the introspect, every single thing in there, so that I can understand very clearly what it is. It's no longer a complicated thing
[inaudible] whatever. And I'm willing to take [inaudible] but it's something that maybe helps you look inside, for example, [inaudible]. What does it do?
I don't know. I'm not going to touch that. That could be a good exercise
[inaudible] take a long time.
>> James Hoe: There's still -- you know, there's -- right, there is a lot more. You know, you know, we've picked four things to go after it. There are definitely a lot more things.
>>: But it's a canonical example of, say, taking the simplest possible element and doing every aspect -- demonstrating every aspect of this philosophy to the Nth degree. So, you know, this FIFO has every traffic monitoring sort of capability.
>> James Hoe: The thing I wanted to do -- I think what's more appealing -- yeah, I see the point. Right. I can --
>>: [inaudible] talking about a philosophy, right --
>> James Hoe: Well, no, it's a philosophy and, you know, it works.
>>: Yeah. Right.
>> James Hoe: And I think I mentioned earlier that this part of the philosophy is, well, the work -- the work the IP user does isn't generalizable but is reusable by a lot of people. Right. But actually I think, you know, that it can be a lot more interesting. Right? You know, that definitely I need a few more graduate students. Eric. I want a postdoc.
>> Eric Chung: So just quick, I think we're getting near the time. But do we have any more questions at this point? So if there are no more further questions, I think -- James, how much longer --
>>: I'm -- I'm here tomorrow morning, so I'm available. But thank you very much. Thank you.
>> Eric Chung: Okay. So thanks. Let's thank the speaker.
[applause]