What is ESL Design in practice? An answer from Global Unichip

It’s hard to think of a slipperier term than ESL Design. To some people in means messing about in C before you commit to a schedule. To others, it means modeling most of the user-visible behavior of the design before you begin implementation. To still others, ESL Design means having a good estimate of the physical attributes of the design before you start RTL. And to still others, the term suggests describing a behavior in SystemC, pushing a button, and watching synthesizable RTL come dancing out onto the screen.

In a conversation with Global Unichip researcher Alan Su this afternoon, the question came up again. Su has both a theoretical answer and a very concrete answer.

The theoretical part comes from Bailey, Martin, and Piziali’s "ESL Design and Verification" (here, for instance.) The authors define the term as "The use of appropriate abstractions in order to increase comprehension of a system, and to enhance the probability of successfully implementing its functionality in a cost effective manner, while meeting necessary constraints." In other words, ESL Design is about understanding the system design. It’s not, per se, an implementation tool.

Global Unichip, it turns out, has been making this concept concrete with an internally-developed system they call Janus. (I will set aside puns about two-facedness and gateways for the time being.) In essence, Janus is a system to allow designers to explore a SystemC/TLM 2.0-based model of a system before implementation time and extract critical data while the model is still abstract enough to have high simulation speeds.

But Janus goes beyond just SystemC simulation. Su points out the very pertinent objection that much of the content in a new SoC doesn’t come in the form of SystemC models. It comes from reuse of existing IP, much of which only exists as RTL. It is feasible, of course, to send a team into the cellar to write SystemC transaction-level models of all the IP you plan to use in the design, but that might be a questionable use of resources unless you have a real corporate commitment to reuse. "As far as I know, only two companies, ST and Sony, have every done this," Su told me.

So the next best thing is to find a cosimulation environment in which you can combine the SystemC models of the new blocks with the RTL models of the legacy blocks. Janus provides this for Global Unichip in a rather clever way: through an FPGA emulation board, a SCE-MI-derived interface, and a system-level virtual prototyping system. The SystemC virtual prototype simulates at high speed because it uses a transaction-level abstraction, and the legacy RTL emulates at high speed because it is in an FPGA.

Su’s team did find a fly in the ointment, however. He explained that if you try to make the TLM 2.0 model cycle-accurate, that means giving cycle-by-cycle control of the FPGA clock to the SCE-MI interface, which eventually means slowing the entire system down to the speed of cycle-level simulation. That gives up most of the advantages of abstraction, and probably over-specifies the system too early in the flow. So Global modified Janus to preclude cycle-accurate emulation, and they recrafted the interface a bit, resulting in only a typical 10 percent overhead for the link between the virtual and emulation worlds.

"At this level, you are investigating things like memory access patterns, CPU utilization, logic contingencies, and events," Su said. "You don’t need cycle accuracy for that."

There is another related objection to this approach. Some of the vital IP for the new chip may be in physical-IP form rather than RTL. For this Su is working on another answer. He doesn’t want to discuss the project in detail yet, but he did say that the concept is to design a physical chip that looks like a library of physical IP. One presumes this chip would have debug hardware as well as IP, and would go on the emulation side of Janus under control of the simulation/emulation link.

In any case, Janus represents an interesting approach to ESL investigation. By recognizing the importance of existing, reused IP, it makes a step forward that I suspect many design teams have had to make on their own by lashing FPGA boards into simulators–at considerable expense and bother—on a project-by-project basis. Sometimes it pays to just take the time to build a robust tool instead of one more one-off fix.