Could Liquid IP Lead To Better Chips? (Part 3)

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. Part 1 can be found here. Part 2 is here.

SE: How easy is it to integrate abstract IP when it comes from different vendors? Is SystemC the best language for this?

Wingard: SystemC is a flexible beast that can be used in a lot of different ways, and different IP suppliers may have chosen different ways of optimizing things.

Bowyer: Synthesis tools have trended to be close to the same language. There is a synthesis subset in Accellera, and we both comply with it and there is natural good style. We see each other’s designs. Customers want to make sure they work between the two tools.

Wingard: But if someone produces high-level IP and I want to produce high-level IP and maybe we both use the same toolset – but our blocks may have never worked together before.

Sanguinetti: The key to that is the interface.

Johnstone: Right. It is not really any different than getting two RTL blocks.

SE: Do the interfaces get synthesized differently when you have control over everything?

Bowyer: As a synthesis company we come at it from a different side. We are a lot stricter about the interface than the other parts. You have to fully define the protocol, the signals, the rules — everything is baked into the interface. That is probably one of the most important and well constrained common aspects of the tools. As IP, the base IP is the protocol. You will know it talks AXI streaming or AXI lite or whatever.

Wingard: Do we have a repository of well-defined interfaces that as an IP vendor I can use?

Pursley: We would probably describe our IP differently, but still comply with the same standard. IP that communicates over AXI 4 and it is communicating with other AXI 4 IP, then they all comply to the standard.

Wingard: What is the HLS view of that?

Pursley: That would normally come from the vendors. We provide it. We are less concerned with the abstract representation and more concerned with the protocol. The description you are getting for HLS is a pretty low-level description and has a pin and cycle accurate description of that protocol. How you abstract that for a system-level fast simulation, that is a different discussion and is not standard. But we don’t synthesize that, we synthesize the pin-level, cycle-accurate protocol, and can guarantee that is the same.

Wingard: So the system guy does assembly using these things and we know the synthesized things will work together. Can we simulate it fast?

Bowyer: The SoC TLM world has to make a decision on the standard there.

Wingard: Which we don’t have.

Bowyer: Which we don’t have, but it is independent of HLS. It doesn’t matter to us. We are happy to provide a TLM view.

Johnstone: But a piece that is missing is the cycle-accurate part. I have my models, not cycle-accurate to begin with, precisely because I don’t want that. I want to do the architectural exploration. But when I have chosen a set and I have done a certain set of configurations and pushed the button and generated RTL, I would like to be able to receive a SystemC model that has the timing annotated back into it so that I can do the high-performance verification.

Pursley: One thing we don’t want to do, is to give the perception that everything has to be boiled with the ocean and that everything has to move to SystemC. The actual SoC assembly is done at RTL. It is not a question of whether it could be done in SystemC. It probably could. Do you want to? I am not sure why. But it is the IP blocks, and in that RTL structure we have different methodologies. Basically you are able to take that IP block within the context of the overall system, simulate it in cycle-accurate Verilog or simulate it untimed at a high level, and the methodology and tools figure out how to do that for you. In the end, it really is RTL that it gets assembled. We are not trying to change that.

Sanguinetti: There is really no abstraction to be gained when you are assembling blocks of stuff. You write it in Verilog or SystemC and it looks the same. There is no abstraction there so it doesn’t matter which language you use.

Wingard: But I care a lot about performance simulation and I would like to be able to do that with the more abstract objects.

Sanguinetti: I have a history of being concerned about RTL simulation.

Johnstone: Another area that still needs to be addressed is the gap between doing a very high-performance model for software virtual prototypes and having something that is synthesizable. The style is different. I am going to have arrays as random access memories all over the place in my fast simulation model but as soon as I do that for HLS I start to get into problems with how I really map to my memory. Am I inferring a million flip-flops instead of a FIFO? Those changes have to be understood and thought about so it is not trivial to make the change. But I don’t think that means it doesn’t work or shouldn’t be applied. There is more growth that can happen, and there needs to be an understanding that when you write one level of model, this is how to write it so it is relatively easily to transform it to the next.

Kelf: This is interesting because it concerns me. If we don’t see everything moving up and see stuff remaining at RTL, then it is just connecting things. But it is creating a barrier to everything moving up, and if you get into the holy grail of synthesizable model also being used in virtual prototyping, then that would be phenomenal. But it sounds as if we are no longer pushing toward that.

Bowyer: As a tool vendor we are saying that looks easy to us if you want to come up with a standard. Every company we go to has a different methodology for TLM modeling, and they are all custom. For a synthesis tool, I need a model that works the same every time, everywhere. It is not a technical challenge. To swap out the pin level description for an abstract one is a trivial challenge. But what does the TLM look like?

SE: ISO 26262 is still looking at the gate level, and this would appear to be stretching things out even more.

Kelf: You always will have to do some things at the final level of implementation. That includes timing analysis and things like that. Fault injection for ISO 26262 has to be done at the gate level because it is required for the final chip, so it is like running other automated processes. Where is the functionality being designed? Is that the piece that is being lifted up and simulated and verified before you go down that path? So there is always a connection between the functional part and the automated processes at the end that you will need to do to make the chip run. Some of the ISO stuff is part of that.

Pursley: Maybe there are some things that we just have to accept that we will leave behind. Would we ever move BiST up to the transaction level? It doesn’t mean that it is wrong, just that we need the methodology to handle it’s addition. Same for fault injection. That may not be an industry standard and different industries may have different concerns. You will not be doing fault injection for a cell phone, or at least I don’t think you would.

Wingard: If I do my fault grade analysis and do not like the answer, what do I do if I have used HLS? How do I correlate it back to what I should change?

Kelf: This is an issue and has always been there. You have to have a connection backup, and the more abstract you get the harder it becomes. With ISO 26262, a lot of work does go on at the architectural level, such as the architecting of the fault-handling circuitry, and you do have to run fault injection at that level. You wring it all out at the architectural level, but to meet the standard you have to run it again at the gate level and show that it works there. There are things that you have to get right at the functional level, and you do run those there.

Pursley: It is important that the tools understand they can reach both forward and back. HLS tools can do congestion aware synthesis. So they can do the synthesis, look for issues based on early floor planning, and then address those and point back to the things in SystemC and ask if you really need to be doing those. That may be the way to address some of these issues. You may have to change the algorithm if you really are funneling everything through a choke-point. For this to be a commercially successful technology, you have to be able to have some way that when real-world problems come up and may be too congested in this IP block that someone else made, there has to be a way to tie it back.

Johnstone: You mentioned another area that is a little problematic, which is power. One of the nice things I can do with HLS is explore a lot of designs and get a power estimate for each one. But what I can’t do is have someone tell me that this line of code, where I can work on the algorithm, is contributing to the power issue. The tools are close but not quite there yet. That is what I hope to see evolve over time as we continue to push more of the design process up the hierarchy.

SE: Are you ready to start adopting HLS IP or is it still something for the future?

Johnstone: We are absolutely ready, and a good part of my job is to convince others of that. I do think it is ready for prime time. The concerns are more social than technical at this point, but it is also important to understand where the tools are missing pieces. You can’t do the whole chip flat at the top level. So where is the frontier that gets pushed down each year? You need to be able to understand that so that you can pick the right IP blocks and be successful rather than frustrated.

Related Stories
Could Liquid IP Lead To Better Chips?
Part 2: What is the business model associated with liquid IP and what can we expect to migrate and which blocks will remain at RTL?
Could Liquid IP Lead To Better Chips?
Part 1: High-level synthesis has been shown to produce better results, so when will IP start being shipped as abstract blocks?