Completing System Design Flows With Emulation

By Frank Schirrmeister
Earlier this week, I participated with Mike Gianfagna (Atrenta) and our own Jason Andrews in a webinar hosted by Gary Smith called, “ESL – Are You Ready?” One of the very interesting discussion topics was how hardware-assisted verification has become the missing element in complementing different execution engines to enable software development and verification in design flows for electronic system level (ESL) design. This sentiment was then also echoed in a write-up Richard Goering published on a presentation that AMD’s Alex Starr gave at DAC, called “Designer View: New Emulation Use Models Employ Virtual Targets”.

Starting with the webinar, the graphic associated with this post overlays the different types of virtual prototypes as presented by Gary over a generic hardware/software design flow. That flow starts with architecture development and continues through hardware and software development, both supported by IP re-use. The flow enables hardware/software integration at different levels of abstraction, from the transaction level to integration of software with hardware representations at the register-transfer level (RTL).

Completing System Design Flows with Emulation

Gary had first introduced the different types of silicon and software virtual prototypes at DAC 2011. The first “Software Virtual Prototype 1 (SWVP 1)” is the architect’s workbench used by the architectural team for design formation and exploration, usually modeled in C/C++ or M (Mathwork’s Language). At this stage, the microprocessors, foundation platforms, and some applications platforms are selected. From here, the silicon and software paths take a different route.

On the silicon side, the “Silicon Virtual Prototype 1 (SVP 1)” represents the design at an early start; hardware accelerators are added, transactional models are developed and in-house platforms are designed here. The “Silicon Virtual Prototype 1 (SVP 2)” becomes the golden reference for implementation. Here, existing RTL blocks are inserted, System C blocks are synthesized and the design is completed and verified. As Gary pointed out, the two different types, SVP 1 and SVP 2, could be developed by the same team.

On the software side, the “Software Virtual Prototype 2 (SWVP 2)” is where applications code is written on a higher level virtual prototype, with the “Software Virtual Prototype 3 (SWVP 3)” allowing development of firmware while applications code is run in parallel on the SVP, checking for latency and power. Finally, the “Software Virtual Prototype 4 (SWVP 4)” is used by product marketing and sales to check out the design with prospective customers for possible modifications.

In the graph Gary used during the webinar, we also found hardware prototypes for software development and product demonstrations. Those are based on the actual chip or dedicated compute engines. The hardware-based prototypes as we know them in electronic design automation (EDA)  – emulation and FPGA-based prototyping – have now moved into the center, completing the ESL flow. If software development requires accurate hardware and speed, then FPGA-based prototypes like the Cadence Rapid Prototyping Platform can be used. Given that they are not available until later in the development flow when RTL has become stable, key analyses like “Dynamic Low Power Analysis” as well as software bring-up can be done on an emulation platform like Cadence’s Palladium® XP Verification Computing Platform. The hardware-assisted engines are simply widening the array of choices in the speed vs. accuracy spectrum in the landscape of development vehicles and, as such, are completing the ESL design flows.

The aforementioned AMD perspective published by Richard Goering gives a real-life example of what Gary outlined in his flows. Hardware-assisted verification – in this case, emulation – is used in different incarnations from pure in-circuit emulation to in-circuit acceleration and also connected to virtualized models, both at the transaction level on a connected host and as Accelerated Verification IP as mapped into the emulator, in AMD’s case Palladium XP.

In the replay of the webinar you can listen first-hand to some of the thoughts of surprise guest speaker Alberto Sangiovanni Vincentelli. The discussion had been geared towards application-driven design and why the arrows in the illustration work better downwards rather than upwards (keeping earlier models in sync). Alberto charted some of the challenges ahead, including how to do requirements-based design based on high-level agreements like specifications. My question to him was whether UML and SysML are in the picture. Alberto answered with some specific thoughts on how those executable specifications are missing the actual aspects of how to implement them without ambiguity.

Bottom line, to me the takeaway from the webinar was that hardware-assisted verification has become a key element to complete the current ESL flows. However, the goal post of what ESL has to become has just has moved further away towards requirements-driven development. Well, that should keep us busy for a while …

—Frank Schirrmeister is group director for product marketing of the System Development Suite at Cadence.