Could Liquid IP Lead To Better Chips?

Semiconductor Engineering sat down to discuss the benefits that could come from making IP available as abstract blocks instead of RTL implementations with Mark Johnstone, technical director for Electronic Design Automation for NXP Semiconductor; Drew Wingard, CTO at Sonics; Bryan Bowyer, director of engineering for high-level design and verification at Mentor, a Siemens Business; Dave Pursley, senior principal product manager, Digital & Signoff Group for Cadence; , chairman at Adapt IP; and Dave Kelf, vice president of marketing for OneSpin Solutions. Part One can be found here. What follows are excerpts of that conversation.

SE: What is the business model for behavioral IP? Do you buy the behavioral code? Do you buy the services to customize it? How do you assign value?

Sanguinetti: Our initial premise was that there were not a whole lot of people who wanted to buy the high-level code and synthesize it themselves. So we would do the development in SystemC, use the (HLS) tool ourselves and deliver for code that you didn’t write yourself. Are you concerned that if you gave away the SystemC code that someone could take it and derive a million things from it?

Sanguinetti: Yes. We would be concerned about that, but if you are delivering Verilog RTL, then you are in the same situation. Fortunately, HLS generates Verilog that isn’t very readable. It is natural obfuscation. But that is good – it is a feature. You should not be looking at the RTL that comes out of HLS.

SE: That implies the value is in the usage of the tool and not in the input description.

Sanguinetti: That is not true.

Pursley: There is a lot of value in the usage of the tool. Just like there is a lot of value in hardening from RTL to gate. But there is a lot of value in the IP as well.

Sanguinetti: The main value that we get from the process is the level of abstraction. You get a 10 to 1 improvement in productivity in the lines of code that you write, and that drives lots of things. We produce IP blocks with a very small number of people and you couldn’t do that in RTL. The value is the same as the value that people have been getting from HLS and high-level design for 15 years. We have done a USB 3 device controller and it has been rewritten a number of times changing all sorts of architectural decisions and you can’t do that if you are developing RTL.

SE: With this new IP model, would we expect to see fewer companies using HLS, but doing a lot of work with it rather than end users who might use those licenses more sparsely?

Bowyer: That is a concern, but I don’t know if this is a long-term thing. Eventually, everyone will speak SystemC or whatever methodology and language that we provide. Everyone does want some control over that IP. The more you buy from another company the more control you give up. So there is a balance that every company has to find. How much of this hardening will I do in house and how much will I give to another company? Over time, more of the hardening will be done on encrypted C code and a set of constraints and letting the company synthesize it for their target technology.

Pursley: I don’t think it is fundamentally any different from buying RTL today. Somebody in the IP company is running a lot of logic synthesis and verification and using the tool there as compared to those – yes, that is less tool usage by the end customers.

SE: It is the buyer of the IP who is running the synthesis on RTL, but for SystemC models it may not be the buyer of the IP but the developer.

Kelf: But they are running it for all of the configurations. Each one requires more synthesis runs and more verification to check the result of the synthesis runs. Whoever is running the synthesis will be doing the same number of runs as if it were distributed.

Bowyer: There will also be a lot of runs at the level of assembly. Today, most people do assembly in RTL because most people are using RTL IP, but over time as people move up and assembly moves to SystemC, you would rerun or be doing more runs as you assemble the IP.

Wingard: I suspect that the IP vendors will probably get the same result with fewer runs than the IP customer because the IP customer has less experience and is more likely to be confused by context. If I have to send an order to the IP vendor to get something, I will spend a lot of time making sure I have thought about it. In-house I may try out a lot more things.

Kelf: I know this is good for verification. Every one of those trial-and-error runs means you have to verify it. When we talk about a move to abstraction, this is a huge move and makes verification more efficient and effective. You can break the verification problem into a high-level functional job and equivalency checking. Equivalence checking means checking consistency between the high-level model and RTL, which is hard.

SE: What kind of blocks will this be amenable to?

Sanguinetti: When I was still at Forte, the Adapt-IP guys approached me. It was a guy who was a domain expert in USB 2 and he wanted to know if HLS was mature enough to do USB 3? He wanted to do it and he thought he could do it by himself which turned out to be incorrect. My assumption or premise at that time was that yes – HLS was good for anything and that you couldn’t find a more control oriented design than a USB device controller. So, I helped him launch this company to do it. When Forte was acquired, I just went over and joined that effort. In the intervening time, we had done USB 2, USB 3 the baseband for 802.11ah and some other smaller stuff – the baseband is what you think of as a traditional HLS kind of applications. FFTs and things like that. But USB is not what you would think of as a sweet spot for HLS, but it has worked out just fine. We could not have done it at RTL. The quality of results is very comparable to what people have on the market.

Pursley: We just did our annual HLS user survey. If you go back 5 years – graphics, video and imaging was almost everything. That was 80+ percent of the usage. Today, that is still growing but as the overall piece of the pie it is down to about 25%. The second biggest segment now is controllers and processors. Wireless is still one of the fastest growing spaces. One of the neat things with wireless is that it touches one of the other advantages of configurable IP in that when you go after emerging standards that may not have been ratified, things may change. If you are designing in high-level IP, you can reduce the risk and turn the crank.

Bowyer: I am not sure that moving to HLS changes the formula for the buy versus build decision. You will buy stuff that is not your core competence. If you don’t know it, you will ask someone else to go and do it. Both sides can go faster, but I don’t think that the decision is any different than in VHDL or Verilog.

Wingard: I am fascinated by the controller example because the controller tends to be about state machines.

Sanguinetti: Life is too short to write state machines.

Wingard: Yes, but abstractions of state machines are not that hard.

Bowyer: But you build a whole separate model inside SystemC because it is better for simulation.

Wingard: We do it because our function is small – our performance is almost everything. We need to know that there isn’t a bubble. Our definition of functionally correct is that I can stream data from point A to point B with no hiccups, no waste states. That is very difficult using traditional scoreboarding techniques.

Bowyer: But what is the effort to build that versus Verilog RTL? You are in a unique situation where you are building cycle-accurate models and that effort is probably on the scale of what it would take to do an HLS model and you could refine that for synthesis.

Wingard: The effort I take to build to SystemC models is almost as much as it takes for the RTL. I don’t have any abstraction benefit.

Pursley: Right. If you are at the same level of abstraction, there is no inherent benefit.

Wingard: We do make some abstraction because we break our models into an untimed part and a timed part so we can run faster.

Bowyer: Now imagine you are doing verification on just the cycle-accurate model. You will simulate that much faster and that is the benefit. It is not that it was easier to write or could build it faster, it simulates 5X or 10X faster, and that is a huge benefit.

Wingard: That still does not tell me at the cycle level if I have no wait states. I still have to do that at the lower level, and that is the nature of my problem.

Kelf: I am intrigued, as well, by the controllers. The formal space is generally state-machine-oriented and doesn’t like datapaths much. I wondered when we went into it if it was a smart move, but we have found tons of control examples out there—adding controllers to datapaths and using formal for that.

Johnson: Also, control logic synthesis has come a long way in the past seven years. I did a project about seven years ago that was a custom accelerator, and it had a small amount of control logic in it. There was a lot of floating point, but in the end I couldn’t get the HLS tool to do the control logic. It was still a success because we just ended up taking the individual IP blocks, the FMA and the adder and the transcendental functions – mapped those to RTL and then did a little RTL for the state machine. These days, that would not be a problem. The only example that I can think of that we have stumbled over control logic recently was trying to do a full processor core and trying to get the pipelining right for the branch delay slot. A very specific piece of high-speed logic where you can’t just tell an HLS tool to pipeline loop. You can do it, but you lose some abstraction when you start doing the states yourself. The difference over seven years is dramatic.

SE: Is there anything long-term that is likely to stay at RTL?

Sanguinetti: That depends on the definition of long-term. When I was doing Verilog simulators in 1994, I said that no one would be writing in Verilog in 2000.

Johnson: Some IP has a very long shelf life. I don’t see people wanting to rewrite tried and true RTL that someone else designed 10 years ago. Maybe that design knowledge isn’t around anymore but we can tweak it enough to keep it working. The better question perhaps is, ‘Will people be writing new RTL in the future?’ There may be cases, but there will be less and less. People still write assembly language.

Wingard: I am pretty certain there are layers around hard macros that will probably stay with RTL. What runs around my embedded SRAM will probably stay at RTL because there is not enough depth there to make it worth going to a higher abstraction.

Sanguinetti: That is really the issue. What is the benefit of abstraction? If you are working at a low level—the design representation that makes sense at that level—then that will not change. The amount of work that you do at lower levels is steadily decreasing.

Bowyer: And it may not be Verilog. It may be SystemC, because that is what I know and I don’t want to learn Verilog just to do this little piece. So they may end up writing RTL in SystemC. We already see that trend. Once you have everyone on the same language it becomes simpler. Having two languages in the same team is overhead, regardless of abstraction or anything else. So there will be a natural tendency for everyone to try and come to one language.

Wingard: I guess I am out of the loop on the latest with HLS. How well do you handle the other edge of the clock? How well do you handle building asynchronous structures? We have to cross clock domain boundaries hundreds of times in chips these days.

Bowyer: We are good so long as you use registers. If you start to use latches then…

Wingard: So my clock tree has latches all over it.

Bowyer: Those kinds of things are not easily expressible in SystemC. I am not sure if the tools are there to quite handle that stuff, but if it is registers, it is fine. It is just a matter of time and it is a solved problem for latches – no new technology is needed. It is just a matter of someone coming and saying they are ready to do the whole chip and they need these extra little things.

Pursley: Early on someone said we are really talking about abstraction more than language. We are talking about language issues. Clock tree systhesis and how you balance… you are rarely doing that in RTL anyway. It is pushing down.

Wingard: Someone has defined a cell that will use those clock trees. So long as synthesis can call that cell, it is okay. I don’t care if it was RTL or gates.

Pursley: But at some point in the flow it has to happen.

Bowyer: Nobody will abstract memories. These are hard cells and we have an abstract view of them, but it is not as if you have abstracted the memory. A lot of stuff will be like that.

Pursley: And as long as it is tied into the implementation flow, it doesn’t matter. You will get there one way or another.

Wingard: My goal or requirement to feel comfortable with it is that you can verify it. Not just a flow that gets it implemented, but is correct when it was implemented which means you can verify it at the higher level.

Bowyer: That brings in another set of issues such as latency and sensitivity, design methodology and how do you build a design that is tolerant of tools that muck with your timing.