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 (ESL). He foresaw the next logical migration in abstraction up from the (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 (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 , chief executive officer of Breker. “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 , chief executive officer for . “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 , 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 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.
, 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.
Related Stories
ESL Power Models
What ESL Is Really About
Is HW Or SW Running The Show?
What Happened to ESL
 |
 |
 |
 |
 |
 |
 |
 |
 |  |
SystemC is more hindrance than help to ESL, its abstractions are bad, it isn’t MT-safe, and it’s something your average C++ programmer will avoid like the plague. As with RTL it is based in a synchronous FSM paradigm (cycle based simulation), that is too low a representation to be efficient for simulation or design.
Really you want an asynchronous FSM methodology that is more of a event-driven/reactive programming style that doesn’t have the overhead of the clocks and works as a fine-grained parallel processing description for both hardware and software.
One can write synchronous state machines in SystemC, or not; it is really your choice.
For bus interface code, you can and need to write code where you tightly control the timing and protocol.
We write such bus interface code once, and save it as a C++ template class (called, say axi4.h), and then use it unmodified in all of our other ip components. A language that doesn’t let you have complete control of such interface code when you need it would be useless for chip design.
For the other 90% of your code, you can and should write it completely un-timed, and then tell your synthesis tool your target for optimizing for area, or timing, and let it schedule the code to hit your target, using your technology node.
I do not know how to write SystemC code that has race conditions, or is unsafe in a multi-thread environment. Communication via ports is as safe as in VHDL.
Really, the biggest advantage of SystemC for us is we write the design once, verify it using standard SystemVerilog UVM test benches and commercial VIPs, where our DUT is in SystemC.
In these simulations the bus interface is cycle accurate, so we can use commercial test benches. The algorithmic code runs (unrealistically) in one cycle, generating all of the correct results.
Once we’ve squeezed out the bugs and gotten excellent functional coverage, we then synthesize the SystemC to RTL, and using the design exploration knobs of the synthesis tool, we can select for an implementation of the algorithmic code that meets our delivery requirements, using the target technology library. We then validate using same test bench used for the SystemC DUT, that the netlist DUT is indeed meeting our timing and area goals and getting correct results. Timing will be different here as now the algorithmic code that ran in one cycle in the verification runs, now may be pipe-lined, or multi cycle, (all done by the sythesis tool’s optimization engines).
I *think* what we are doing is called the ESL Flow, but if not, I guess we really don’t care – call it what you will; this flow is working for us, and we are delivering complex IPs that are compact and correct, and in the same amount of time, an engineer can design and verify blocks that are 10 times as complex as it would take to her to code and verify a design in an RTL language.
We present a paper in the IP Track of the Design Automation Conference, in June of 2016, in Austin, where we describe our approach, and share results for the design of an 802.11 ah MAC and PHY IP.
We have deployed ESL methodology to develop virtual platform for performance analysis of memory sub-system under different workloads. Though the performance numbers were idealistic, it did help the architect to explore architecture alternatives to meet these numbers. With aggressive innovation in memory technology , I think using ESL to carry out performance and power analysis will become more relevant in coming days, people are already doing so. Apart from early software development and HLS , we would like to hear more on this.