What is system virtual prototyping?
The popular view of system virtual prototyping is that it involves the use of highly abstracted (i.e. system level) system hardware models on which software development can begin well before a physical prototype is available.
However, this view continues to see software and hardware development as separate design endeavors. This type of virtual prototype not only enables earlier software development but also creates feedback that can indicate where hardware needs to be adapted before RTL is generated, or where choices between hardware and software-based implementations exist for certain aspects of the design. We have therefore adopted the broader term ‘system virtual prototyping’.
Examples include identifying the need for in-silicon accelerators and the analysis of where hardware or software techniques may be deployed in combination to meet an overall power budget most efficiently and effectively.
An increasingly important aspect of the hardware-software interface within system virtual prototyping is the need to partition code across multiple cores in the design’s main processor to secure the best performance. Many of these decisions can now be taken at the system level.
Even beyond the boundaries of our definition, virtual prototyping should be seen more in the context of enabling the co-design, co-simulation and co-verification of hardware and software. The overriding goal is to catch design issues at a stage where there are still comparatively easy to fix and thus drive ‘first time right’ strategies within narrow time-to-market goals.
Virtual prototyping is also one of a series of prototyping and verification techniques alongside simulation, emulation and FPGA prototyping that can today all be used on a project rather than on an either/or basis, largely because of complexity. One of the serious challenges now facing design and verification engineers is getting the right mix of these different techniques to deliver the best results in the shortest time.
What are the benefits of virtual prototyping?
In the white paper Hardware-Aware Virtual Prototyping, Shabtay Matalon and Yossi Veller of Mentor Graphics, list the following as the “Main benefits of virtual prototyping”.
EARLY VALIDATION OF SOFTWARE AGAINST HARDWARE
Virtual prototypes can be conducted at a much earlier design stage, even before any RTL is designed, increasing productivity and shrinking design schedules.
INFORMED HARDWARE ARCHITECTURE AND RTL DESIGN
Early validation of software on a virtual prototype allows software teams to readily change the hardware design topology and influence the RTL design specification.
REDUCED HW/SW VERIFICATION EFFORT
The code representing the hardware is much smaller and simpler. Thus, virtual prototypes simulate orders of magnitude faster than RTL code, capturing bugs manifested in complex scenarios that are hard to simulate at the RTL and making debug easier.
PRE-SILICON PLATFORM MODELS FOR END USERS
Virtual prototypes allow the early handoff of a chip as a pre-silicon reference platform, allowing concurrent system and application software design before the chip design is complete.
POST-SILICON REFERENCE PLATFORMS
Virtual prototypes provide a post-silicon reference platform for simulating scenarios that are difficult to replicate and control on the final device. They also give visibility into internal performance, power, and design signals that is simply not available on the physical chip.
Virtual prototyping remains a developing technique, so while this list is close-to-comprehensive today, it will continue to grow.
For example, since the Matalon-Veller article was written, Synopsys has launched a Hybrid Prototyping Solution. Briefly put, this allows designers to create prototypes composed of virtual models of ‘new’ design blocks and more stable re-used blocks running in a FPGA prototyping environment. The idea is to combine the speed of virtual prototyping with the greater accuracy offered at the FPGA level.
What are the main virtual prototyping platforms?
Although virtual prototyping is still considered to be maturing, many of the original ‘obstacles and objections’ to its use have been overcome. This includes the main format.
The industry has coalesced on the use of transaction level models (TLMs) to create the prototypes’ building blocks, starting with models of the main target processors. These are available for all the main processor architectures (x86, ARM, Power PC, MIPS), and for individual processor families that use these.
TLMs are today typically realized in the SystemC TLM 2.0 standard, adopted by all leading vendors so that the resulting models can be used with all the main SystemC simulators.
After an initial face-off between silicon and tool vendors as to which should create the models, most are now the result of close alliances between the two, with model creation beginning in advance of the launch of most new processors to enable early adoption. For more information on transaction level modeling, see our separate guide.
A further important, open source technology is the Qemu emulator and virtualizer that allows developers to run different CPU architectures on their current platform (e.g., Linux, Windows).
How are virtual prototypes built?
Their construction is essentially modular. As most differentiation for system design is now assumed to take place in software, the hardware team will expect to take most of the core models for the final prototype off-the-shelf in the form of pre-built TLMs from leading tool vendors.
Not only does this save massive amounts of development time – particularly for processors – but the user also has some guarantee that the TLMs are either battle-hardened because they have already been used successfully and/or the result of close cooperation between the tool vendor and the processor’s originator.
The models will typically be gathered and assigned using a tool’s graphical interface with the automated intelligence within the tool helping to stitch them together into the final prototype.
Similar tools then help create bespoke models for differentiated hardware IP that the user adds to the system, where necessary.
Finally, the resulting prototype model is passed on to the software team so that they can begin to develop code for the system and initiate a feedback loop to the hardware design team as it progresses its portion of the design towards RTL.