Expecting the future to replicate the past always leads to surprises and when it comes to migration of abstraction for semiconductor design, the future remains unclear.
It was 20 years ago that Gary Smith coined the term Electronic System Level (ESL). He foresaw the next logical migration in abstraction up from the Register Transfer Level (RTL) to something that would be capable of describing and building complex electronic systems. He also saw that the future of EDA depended upon who would control that market. The migration from the gate level to RTL ushered in new dominant companies, none more so than Synopsys, which controlled the synthesis market. Could High Level Synthesis (HLS) be the key to the next generation of EDA?
As we all know, that did not happen—despite some very large investments from the big three and from several well-funded startups. What went wrong or right for the big three? Chips continue to get more complex and RTL is certainly struggling to provide the productivity gains desired by semiconductor companies. But the problem has changed.
“To move to the next level of abstraction, we need three things,” contends Dave Pursley, product manager for high-level synthesis products at Cadence. “First we need a modeling language and we have that with IEEE 1666 (SystemC). Then we need a path from those models down to gates. We have high-level synthesis solutions. The other thing we need is a verification methodology. This is not just tools, but a methodology. There is a lot of change happening here, and we are seeing companies have success not just with SystemC, not just with HLS, but with a wholesale methodology change.”
There is no disagreement there from Bryan Bowyer, director of engineering for Mentor Graphics. “Where we see HLS being successful is where companies have built their own methodology. They have taken a synthesis tool and taken it upon themselves to define a methodology that works for them. What is missing is standardization. We now need to look at these, take the best pieces of each of them, such as for coverage or formal verification, and assemble it into a complete package.”
At this point one might assume that we are close to a viable ESL methodology. “I don’t think we are very far at all in terms of defining an ESL flow,” says Adnan Hamid, chief executive officer of Breker Verification Systems. “ESL flows are not about the vendors and the tools that they have. They require a process change within the user companies. Most user companies today have problems getting their chips out on time and on budget, and struggle writing RTL, waiting for simulation to come up, and having to rewrite tests for every generation of their product.”
Hamid finds support from Simon Davidmann, chief executive officer for Imperas Inc.. “Everyone is trying to do more with RTL, more design, more verification, more complexity, and they needed a better solution. The industry came up with a C++ class language and then tried to look at what they could do with it. What is needed is to move away from the EDA vendors trying to define ways to sell the technologies they have, to asking the question, ‘How are we going to design systems which are incredibly complex, containing many processors, many hardware blocks and more software than you can imagine?’ How can we design things in a better way? How do we verify things in a better way?”
And this is where one of the major problems with ESL comes to light. ESL is many things to different people. “If I am defining a system, I am really not concerned with the hardware at all,” says Raik Brinkmann, president and CEO of OneSpin Solutions. “I am defining a system that does something useful and I am not concerned if it is implemented in hardware or software. Everything I do is a choice of optimization. The optimal solution for you may be defined by performance or the price point. We need something that can define the whole system and can then be broken down into smaller pieces. Then we can use the tools that we already have. Mapping into hardware is one thing that is done today, but people who were expecting something to map software into hardware using HLS were disappointed.”
One connection point between the hardware and software worlds is the virtual prototype. “There is big value in software development, and using virtual prototypes enables the software environment to be developed in parallel,” says Patrick Sheridan, product marketing for virtual prototypes at Synopsys. “There is also application in architecture design, the ability to analyze the performance of your future SoC before RTL is available. This is a somewhat standalone activity, but it has a lot of impact on the design process. The newest use case is the estimation of power. This is now possible with SystemC and UPF 3.0. This is a new category of design task that can be performed on the system models.”
Davidmann identifies the problem: “All of these areas just brush into each other. They are all needed, and ESL has moved them all up to a higher level of abstraction. But the challenge is that with RTL the industry was able to concentrate on synthesis. ESL is all of these things. It is probably 15 areas that you have to worry about. We still do not have a coherent understand of what we are doing. We can dream about solutions.”
ESL is a bunch of separated islands of capability today with very few connection points between them. On the surface it would appear that virtual prototypes and HLS should form part of a flow, but they don’t. “It is up to the industry to say if they wish to integrate HLS and virtual platforms,” says Bowyer. “We talk to the hardware design teams and they don’t really like virtual platforms. They don’t want to create them. They are hardware designers, and they just want to design their pieces. So it up to the companies and the industry to decide what links need to exist—and maybe they don’t need to exist.”
One emerging area is a new verification methodology based on graphs. This not only provides a new verification abstraction, but finds a way to tie it into the existing methodologies. “Accellera has the Portable Stimulus Working Group that is tied to the ESL problem,” says Hamid. “It is trying to define the verification intent once and then able to use this throughout the flow going down to implementation and then back up through integration.”
Bowyer also sees value in an incremental approach rather than a wholesale methodology change. “Each piece needs to be incremental so you can continue to use the things you are using today and layer some new stuff on top of it. Over time, as design abstraction increases, and as verification and modeling abstraction increase, I can work more productively and I don’t worry about implementation as much. It is better to look at how we take some adjacent solutions and lower the risk between those.”
The migration up in abstraction has been hampered, in part, by a lack of models, so users have often looked for way to abstract their existing designs. “Those models are two years later than when you actually want them,” Davidmann points out. “If you want to simulate the system in the early stages of the design process, you cannot wait until you have the hardware. The practical approach is to write a behavioral model early on, and then use that to help develop the software or the verification environment. You use that model as a reference for the RTL design.”
One part of the model always stays the same throughout the design and implementation flow. “The key is register compatibility,” says Sheridan. “If you are able to describe the register interface to the software, then you can abstract the components of the system. That also enables you to put together hybrid solutions using FPGAs. They all require that the interface to the software is fixed.”
Part of the problem for EDA is that each ESL tool has been developed to target a particular user within a semiconductor design company and their specific problem. Within those companies, there is often a division of responsibility. Application software, low level software and drivers, architecture, hardware design, verification—each has different demands and different pain points. There is little sign that the functional organization is changing within design teams, and thus there is little incentive for one group to provide a capability, at their expense, that benefits another group.
Anupam Bakshi, CEO of Agnisys argues that “a discussion about ESL is like having an elephant in the room with five visually impaired people trying to describe it. People are confused, and maybe the whole industry is confused about what ESL really is. Today, any method that raises the productivity of the user above what is available to them by direct coding in RTL is ESL. Whether one part of a disjointed flow is better than the other is debatable and perhaps depends on the design domain.”
Does the industry need ESL? Does it need a different solution? Perhaps the industry is struggling so hard to churn out new designs that optimize some aspect of the system, that it is not looking at how it can optimize the design process. Or perhaps design cost is no longer the chief concern.