Synopsys Cloud
Cloud native EDA tools & pre-optimized hardware platforms
Request a Free Trial →
Table of Contents
Shift left, right? It’s a question. Why do I need to shift left? What are the benefits of shift left and how do I achieve it? Everyone seems to be doing it.
What does it actually mean?
Shift left has been popularized as terminology that refers to all aspects of efficiency and effectiveness improvements, in many walks of life. In the recent article, “Shift-left, right?” by Joe Convey and Bryan Dickman, the question is framed in the context of ASIC development lifecycles. Every modern ASIC project incorporates both a software development part and a hardware development part, and you really don’t want to have to serialize these two significant activities.
In the first case it means accelerating software development (the more traditional use case). We shift software development left such that it can start much sooner and you don’t need to wait for functional hardware models to develop and validate the software. Moreover, a loosely timed virtual prototyping platform out-performs RTL simulation by several orders of magnitude, enabling a much more natural and real-time experience of running significant volumes of software and interacting with it using the usual software debug environments.
Note that even when the hardware RTL model is available, it’s likely that your software developers will favor the virtual platform because of its naturally higher performance. In this case we are talking about functional accuracy only. In most situations, the software does not care about cycle-by-cycle accuracy, and thanks to this, loosely timed or untimed models can run very fast (50-200 MIPS). Much of this is well established engineering practice. See the Synopsys publication “Better Software. Faster!” for an overview that is still completely relevant today.
So, that’s software development shift left, which is now well established and understood for many teams. But it can also mean acceleration of hardware development. Virtual prototypes in the form of TLM models can also be used to accelerate RTL hardware verification. It is, in fact, a two-pronged attack; a win-win maybe, or “Better Hardware, Faster!”
Where to Start Prototyping?
Take a look at your system architecture. How many of the IP blocks are off the shelf, or third-party IP components, and how many are customized blocks that the design team will design and build? What are those standard blocks? Maybe a CPU, Synopsys DesignWare® IP components, AI accelerators, standard bus interconnects, and memory system components? You’ve already figured out your system architecture and built and validated its performance and power characteristics using Synopsys Platform Architect® Ultra (see “Take the guesswork out of designing your new product architecture”).
You’re now in the “develop the software” and “develop the hardware” phases of the project. For example, you’re probably not in the business of designing the CPU and will instead use a third-party CPU from Arm, Synopsys, or a RISC-V provider, so no need to run all your system validation payloads using the full CPU RTL model. After all, you don’t need to re-validate the CPU RTL model. Swap it out for the much faster TLM version and go hybrid. Your system validation payloads are likely to be heavily biased towards large test programs executing on the CPU. Run those fast on the TLM model and only leave the parts you are developing and validating as RTL so you can debug with full visibility.
Accelerated Acceleration
With the availability of real interfaces, it is possible to connect virtual prototypes with emulation and FPGA prototyping solutions in a hybrid configuration, with key innovations such as the recently launched ZeBu® EP1 emulation system and HAPS®-100 FPGA prototyping technologies from Synopsys playing an important part alongside virtual prototyping. A fast virtual model of a CPU significantly accelerates the execution of software on the system versus running the software with a fully emulated RTL model of the CPU. Running fast models of standard CPU and GPU components in virtual prototyping, while running other IP on emulation, provides excellent visibility for hardware debug as the entire system runs. This makes for more efficient debug and better hardware, earlier than would have been possible without deploying the virtual prototyping environment.
As Joe and Bryan point out, virtual prototype models written in SystemC/TLM are combined with RTL components to build hybrid emulation, or hybrid FPGA-based prototyping, environments. The virtual components are simulated on the host workstation while the RTL components are mapped to the hardware acceleration platform. Modern emulation and FPGA prototype systems are designed to connect to virtual prototype models through libraries of ‘transactors.’ These transactors allow the efficient mapping of virtual I/O transactions onto the pin-level activity of the RTL model. They are abstraction-level converters.
These benefits for hardware acceleration yield a further shift-left effect for the software-driven system validation phase of hardware development.
The new Virtualizer Studio IDE integrates advanced modelling tools to accelerate VDK creation and deployment.
What’s the (Check)point?
Checkpoint-restore has an important role to play in enhancing performance and productivity as areas of interest for debug, for example, can be saved and reviewed at a later stage. Synopsys Virtualizer® Studio can store the entire state of a simulation at the point of interest, then use that checkpoint to get back to that precise area of concern. This allows the user to skip past long initialization phases while debugging hardware or software. This really provides a productivity aid in the double-blind scenario where it is unclear whether there is an issue with software or hardware at a particular point of interest, requiring multiple iterations of code change, debug, and re-run of the simulation. Further, skipping the boot sequence and directly executing the relevant test program greatly improves the regression throughput.
Virtual and real-world IO are critical to software-hardware co-simulation. A prototype created with Virtualizer® Development Kits (VDKs) can connect to a physical Ethernet network, allowing the creation of a hybrid prototyping environment. In this hybrid environment, virtual prototype models can be used to shift left the development of RTL testbench environments thanks to co-simulation. For example, the prototype can be used as a “virtual DUT” so that testbenches and test cases can be developed, and verification bugs can be reduced in advance of RTL. Further, system-level test cases can be developed in advance of RTL to speed up system integration testing.
In this hybrid environment, debug is made highly productive with the integration of popular debug tools into Virtualizer Studio. The VDK debugger provides unique hardware-software code debug, which allows the monitoring of hardware activity in the VDK as well as software.
Summary
While the most obvious and widely acknowledged advantage of using virtual prototyping is the shift-left effect on software development, there are many other benefits that apply to hardware development with an overall multiplying effect on the final product delivery shift-left outcome. With resources like the ZeBu EP1 emulator and HAPS-100 FPGA prototyping in a hybrid environment, significant opportunities exist to get to better hardware, faster.
Shift left, right! It’s not a question after all. It’s an imperative!