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. What follows are excerpts of that conversation.

SE: Why has not become more widely used in the IP business?

Sanguinetti: For my part of the industry it has.

Pursley: We have been seeing that a lot of large companies now have HLS IP repositories that they are continually using. One example is a company that did 60 derivative designs in one year.

Kelf: We have seen quite a bit. The reason is the configurability of IP. It is much easier to do a high-level abstraction and use HLS to make it more configurable and fit into more situations. This makes it more flexible.

Wingard: In our case, we have stuff that we consider to be massively configurable, so an average customer design for our IP has a configuration file that is 10,000 lines long and sometimes up to 20,000. The level of abstraction of many of those configuration choices is low enough that we haven’t figured out how to productively apply things like HLS. We are trying to aim for certain optimization corners where we are very directly controlling the size of hardware structures. Some of these things are perhaps too detailed to easily use through HLS.

Sanguinetti: That is just a matter of abstraction, isn’t it?

Wingard: You could ask the question, ‘Do I need all of those parameters? Could HLS figure it out for the customer?’ Sometimes the customers care a lot about specific choices and what they would gain by going to the extra level of indirection.

Sanguinetti: What you are saying is that you don’t see an abstraction of that information, so you don’t have any advantage of trying to move it to a higher level.

Wingard: We haven’t found one yet. We would like to because what we do now is incredibly expensive and we have had to invent our own language.

Bowyer: It is a high-level language, just not SystemC or something like that. What we hear from IP companies is that they have to sell to the lowest common denominator. If everyone will accept RTL and some would not accept high-level IP, then you get stuck there. But we are seeing quite a lot of IP that has moved to a higher level – it is just not everything. It is probably not the high-volume, general-purpose IP. It is more specialized. One example is Google. They have developed high-level IP to help drive DP9 in C++, SystemC and they are sharing this with their partners. This is a good way to go for that kind of IP. But there is stuff where it makes sense only if everything else is in SystemC. But to go to SystemC just to move languages doesn’t make sense.

Pursley: There has to be an inherent value add.

Johnstone: We have a lot of legacy IP and we developed it over a number of years. There are constant spins, but it is all done at RTL. We can’t make the financial justification to rewrite everything in SystemC, and also for schedule reasons. So a lot of work that could be spent on this is being spent tweaking the RTL, and they don’t have the time to get to the next level of abstraction. A lot of other IP we buy and we get it as is. We have had notable successes on individual IP blocks, and we would characterize those as coming generally from younger engineers who are more willing to adopt a new methodology. We have some very senior people who know how to do it. But they are risk-averse, and so they keep doing what they know how to do. It is a slow process and while proven itself, there are obstacles to adoption beyond just the HLS technology.

Pursley: So that is more of a matter of digging so fast with my hands that I don’t have time to pick up a shovel?

Johnstone: Absolutely, and people who are very senior and know how to do it don’t want to move to something new. Back when I was a software engineering intern, I was the first C programmer in the company and everyone else did assembly language. They all told me they could write better assembly than my compiler could produce. At the time they could, but those jobs don’t exist anymore. My first semiconductor foray was to use synthesis and they all said it would be too big and too power-hungry. Those jobs don’t exist anymore. We are at the same inflection point, but maybe taking a little longer because the abstraction jump is hard. Newer companies and newer engineers are more willing to take risk and will be the ones who succeed.

Bowyer: When we look at the new applications such as machine learning and machine vision – where there isn’t existing RTL IP to refine…

Johnstone: Yes – that is a perfect example. We just don’t have the legacy and we have to do something new and do it quickly. That makes a good target.

Kelf: With the gate-to-RTL abstraction leap, the timing was the same, migration from flip flops to the registers in RTL – it was all pretty clear and it wasn’t that hard to move gate-level guys. It was hard at the time, but they could still imagine the registers and where they were. To go from there to SystemC, where all of the registers have gone, all the timing has gone, and it is just algorithms and C code with some hardware abstraction—that is a much bigger leap. And it is a struggle for the tool makers. It is a struggle for verification. And it is a struggle for the engineers. I sometimes wonder if we need an intermediate step.

Wingard: We write a lot of SystemC because we use that for our verification models. The way we make sure that our RTL behaves the way we say it will is to build a cycle accurate SystemC reference model. So we value the fact that they are independent representations because they are fundamentally the checker for each other. So that is another challenge for us going to a higher level – how are we going to check it? The verification aspects are not obvious.

Kelf: We are producing tools, on the formal verification side, where we have SystemC formal verification tools. There are two aspects to that. One is the property/assertion-based verification, but the other is building apps that handle the fact that C++ isn’t actually a hardware modeling language. For example, you don’t have four states, you have two. You have initialization issues, you have race issues.

Wingard: And ugly elaboration.

Kelf: So you need checks for all of this. You need regular verification tools and then tools to look at those kinds of issues and solve them as well.

Wingard: Paramaterization. When we think about IP design and if all the configuration is built in and the customization and parametrization is there in RTL, then the customer configures it for their environment. In order to migrate this to an HLS environment, do we have to decouple the notion of what is configurable and extract that as a different entity than the functional intent?

Bowyer: At least some of it. Some of it is fundamental to the design – like bit width. You can parameterize it in Verilog already. That is part of the design. But there are a lot of things that you can take out related to performance, related to clock speed, target technology. Most of the IP at the high-level can go to an FPGA, can go to any ASIC, but we talk about that today as hardening. It is a similar thing. You can get your soft IP in RTL or liquid IP at the high level, and there is a hardening process. But it is separate from the design and maybe a little unclear where that line is. It is usually clear what is fundamental to the behavior and what is about hardening.

Johnson: That speaks to the learning curve. People need to understand which parts should be abstracted out as they write the model. With a Verilog mindset it is all one and the same, so you don’t think of them differently.

Bowyer: And we don’t stop you. You can write RTL in SystemC if you want.

Wingard: To manage the complexity we already have, we have to do the abstraction. The actual hardware generators we call have many more parameters than we ever show the users, and so what we gather from the users are abstracted parameters that make more sense in a system context. We provide a distributed tool environment that helps them set those parameters. There are massive numbers of inter-parameter dependencies and implications between them. To help them make the choices we have to provide an environment that helps them to make the tradeoffs. Performance and power analysis, plus other functionality environments, help them make the choices. They are not obvious. That encapsulation means that when it becomes time to think about verification, we have had to create technologies to do constrained random generation of configurations. We could do random and finish up exploring the wrong space, so you want to explore interesting spaces or legitimate spaces. I would like to be able to leverage something like HLS to contain that explosion. Languages like C++ have a lot of nice models for data structures that can help to contain that problem. To date, we have done that work in Python, but it would be nice to use a language that can be used in simulation as well.

Bowyer: There definitely is that kind of fragmentation. It is not like there is one high-level language that everyone moved to. SystemC is great, but for some things we do see people using Python. They get to C eventually and synthesize down, but there needs to be work in this space to say, ‘Here is the language and here is the way to use that language for parameterization, here is how you use it for partitioning, and these will help with the learning curve.’

Pursley: Methodology best practices.

Bowyer: Right. The language is there but we haven’t been able to bring it all together for everything.

Related Stories
Whatever Happened To High-Level Synthesis?
Experts at the table, part 2: Playing in an IP integration world, defining verification flows and compatibility with a virtual prototype.
Machine Learning Meets IC Design
There are multiple layers in which machine learning can help with the creation of semiconductors, but getting there is not as simple as for other application areas.
Using Machine Learning In EDA
This approach can make designs better and less expensive, but it will require a huge amount of work and more sharing of data.