Hybrid emulation for development, validation and verification
This article introduces hybrid emulation, a combination of emulation and virtual prototypes, and its application to tasks such as architecture validation, early software development and software-driven verification.
Hybrid emulation combines virtual prototyping and hardware emulation. This makes virtual prototyping more effective in early software development, one of its main uses. It also enables two more ways of using the technique: for architectural validation (as opposed to architectural optimization performed with standalone virtual prototypes) ,and for software-driven verification.
Many companies are already using these three approaches to boost productivity, and address design challenges earlier and more quickly in response to increasing design complexity.
What goes into a hybrid emulation system?
The virtual prototype component
Virtual prototypes are high performance, SystemC models of an entire SoC, a particular block or a system model. They have primarily been used by project architects and for early software development.
Architects will use them, naturally enough, for architectural design optimization and to check that their designs meet certain goals, such as performance and/or power. Architects may also use virtual prototypes to assess the correctness of the bus architecture. And so on.
For software development, the value of a virtual prototype lies in providing access to a ‘somewhat working’ model of a design long before first silicon becomes available. It may lack 100% finesse, but it enables developers to start coding earlier.
The hardware emulation component
Emulation has typically used by the verification team to accelerate its tasks.
An emulator runs much faster than a software-based RTL simulator and has a simulation-like use model. All the debug features available in simulation are present in emulation. The user can add dump bars, assertions, monitors and more.
Emulation is often used to run long tests that would not be viable – either because of their size or scope – in simulation. Where a simulator might be able to show how an image-processing SoC would handle thumbnail images, an emulator could process full-size images, or even video streams. Emulation also enables a verification team to undertake a deep inspection of multi-packet network traffic. Emulators can also be used by software teams for early software-bringup, where long software sequences need to be tested against RTL.
Emulators make it possible to bring up a full SoC design before even an FPGA-based prototype is available. The design team can then begin hardware-software integration. The RTL probably is not stable at this stage, and this is why the full debug capability of the hardware emulator is so important.
Bringing emulation and virtual prototypes together
When you combine a virtual prototype with the tools already available and then add emulation as well, you get the best of both worlds. You have a fast emulator that can run a cycle-accurate implementation of the RTL and a very fast virtual prototype that speeds software development and architectural validation.
What are the best ways to use this combination of capabilities, how do they differ and how do you choose and tune features to build the most appropriate hybrid? Let’s review three common hybrid emulation techniques.
Architectural validation
For architectural optimization (working towards the most appropriate architecture), you want a fast model and therefore use a fast virtual prototype.
For architectural validation (checking that your optimized architecture works as expected), the most important thing is the accuracy of the model. This means you need to overlay the timing constraints and make the model cycle-accurate.
In previous work, you may have used an instruction set simulator (ISS) but these are not cycle-accurate. Mixing a cycle-accurate virtual prototype with an ISS does not help you move into validation. You need the processor RTL, and you need to be able to run it fast.
An emulator, used with cycle-accurate virtual prototypes, provides the necessary performance gain over simulation to take that step toward validation.
Early software development
When developing an SoC, a virtual prototype may be created to represent the newest parts of the design. Virtual prototypes may also be available for functions that are being re-used. But some components may only exist as RTL blocks (these are probably legacy blocks, or blocks that it is hard to realize in SystemC).
When you want to bring newer and legacy blocks together for pre-first silicon software development, simulation does not have the performance to run extensive amounts of code, particularly those RTL-only blocks. Emulation meets this shortfall.
Consider a GPU block, whose highly parallel logic does not map well to a SystemC serial model. Using hybrid emulation, you can combine a virtual prototype in software with the legacy GPU RTL block mapped into a hardware emulator.
Software-driven verification
Some hardware verification tests cannot be run in simulation. One set of these is called software-driven tests. These load embedded code into the processor subsystem, which then accesses and exercises this code to test the rest of the SoC RTL.
The best performance combination here is to run such tests with the processor expressed as a virtual prototype and the rest of the SoC – almost certainly the majority – mapped into hardware on an emulator.
Let’s go into more detail on each of these use cases.
Architectural validation in practice
A major challenge for validation is that you need more than traffic generators. You need an embedded core that can run realistic software workloads to get the most accurate performance analysis.
Take the example of a memory controller. These typically have multiple parameters that must be tested and confirmed along with different memory types that must also be tested.
A hybrid emulation strategy would include several components. It needs a fully-timed architectural model. It needs a cycle-accurate timing interface between that model and the rest of the CPU subsystem mapped to the hardware emulator. And it needs performance analysis. Together, this gives you the time to run multiple tests and then examine their results thoroughly.
Figure 1 shows a fully timed architectural model in the virtual prototype and the processor subsystem RTL mapped to the hardware emulator.
Figure 1 An architectural model running in a virtual prototype, linked to RTL running on a hardware emulator (Source: Synopsys)
This is a special case because both sides of this hybrid emulation model are fully timed. They are cycle-based. They are connected through a transaction-level modeling (TLM) fast-timed adaptor and an AXI master transactor that sits in the emulator. This combination allows us to have the 100% cycle-accurate interface between the two models necessary for architecture validation.
In this scenario, the comparatively high performance of the emulator is critical to being able to run a realistic software workload.
Early software development in practice
Early software development is an established use of standalone virtual prototypes. But what do you do if some blocks in the design are not available in SystemC or as TLMs?
Hybrid emulation here comprises a model of the legacy block built from RTL running in the fast emulator that is connected to the block or blocks available as virtual prototypes. This gives you both the full virtual prototype software debug capabilities and the emulator’s RTL debug capabilities.
This mode typically uses a loosely-timed interface to the emulator that allows the virtual prototype to run at the fastest possible rate. The block diagram in Figure 2 shows the VP with the majority of the SoC mapped to it.
Figure 2 The virtual prototype now includes most of the hardware, apart from the GPU, and can run embedded software (Source: Synopsys)
This solution resolves the virtual prototype modeling problem. Where you have a legacy block that has already been used in multiple designs, you may not have the time to port it to SystemC just for software development. With hybrid emulation, you can mix and match what is available in RTL with new blocks as virtual prototypes. Again, you can start software development long before your RTL is stable and available.
Software-driven verification in practice
In the software-driven verification mode, you need enough performance to run the embedded tests. Verification also always faces schedule pressures, so a higher performance model will help ease some of those too.
This hybrid emulation scenario uses a protocol-accurate interface. It does not therefore need to be cycle-accurate as is the scenario for architectural validation.
You have a high-performance processor model as a virtual prototype that can boot Linux in minutes. But, because you are in the verification phase, the full visibility RTL debug offered by the emulator is critical to resolve any hardware-software integration issues.
Figure 3 The virtual prototype here runs a portion of the SoC and the RTL running on the emulator represents the majority of the design. (Source: Synopsys)
The block diagram in Figure 3 is slightly different from that in Figure 2. The virtual prototype is running just a portion of the SoC and the RTL running on the emulator represents the majority of the design. In between we have a loosely timed TLM adaptor connected to AXI master and slave transactors that are part of the emulator.
The benefits of hybrid emulation
Hybrid emulation strategies can be deployed at various phases of the development cycle, with some variation depending on how they are used. But in each case, the technique can be summed up as ‘early’ and ‘fast’.
The key is achieving the right mix of models, capacity and partitioning. To do that, you need access to tightly integrated solutions at both the virtual prototype and the emulator levels, coupled with the most appropriate debug tools.
Hybrid emulation at Synopsys
Synopsys’ hybrid emulation solution matches each of the use models described above, with the ZeBu Server-3 providing hardware emulation alongside tried and tested tools. The emulator itself is scalable to 3 billion ASIC gates and runs on high performance Xilinx Virtex-7 FPGAs with 28nm Stacked Silicon Interconnect technology for the highest performance, highest reliability and lowest operating costs.
For architectural validation, the ZeBu Server-3 would be used with Platform Architect, incorporating Multicore Optimization Technology. Platform Architect can migrate virtual prototypes from loosely timed to approximately timed to fast timed (or cycle accurate).
For early software development, the second solution combines ZeBu Server-3 with Virtualizer and its Virtualizer Development Kits VDKs. This combination also supports fast software-driven verification.
Within these combinations, there are a number of features that address hybrid emulation.
Platform assembly across the virtual prototyping and emulation environments is facilitated by adaptors, transactors and connectors, as well as the off-the-shelf library blocks within the VDKs.
The ZeBu TLM2.0 adaptor library includes the building blocks that can connect the virtual prototypes to the transactors.
ZeBu transactors have been built to connect to a C or C++ testbench. The adaptor converts the C API into standard SystemC TLM2.0. It can thus connect to Virtualizer or Platform Architect, and to any standard SystemC models on the software side.
The adaptor for the fast-timing mode was developed for architectural validation. It provides the interface between the SystemC architecture model in Platform Architect and the RTL of the processor mapped to the emulator.
In the fast-timing mode, you trade off some performance for accuracy. But while the virtual prototypes may not run as fast as in standalone mode, the ZeBu Server-3 gives performance up to 5HMz, far ahead of running RTL at standard simulator.
This fast model supports AXI 3 and 4 master and slave interfaces and you can tune accuracy between fast- and loosely timed, depending on a project’s specific requirements.
Further information
Online seminar demonstrating all three use models
The Synopsys Press eBook on Prototyping includes a chapter with 10 customer case studies on the use of hybrid emulation – as well as a chapter on hybrid prototyping (which combines virtual prototypes with FPGA-based prototyping systems such as HAPS).
Author
Tom Borgstrom is a director of marketing at Synopsys where he is responsible for Synopsys’ ZeBu emulation solution. Before assuming his current role, he was director of strategic program management in Synopsys’ Verification Group. Prior to joining Synopsys, he held a variety of senior sales, marketing and applications roles at TransEDA, Exemplar Logic, and CrossCheck Technology, and worked as an ASIC design engineer at Matsushita. He received bachelor’s and master’s degrees in electrical engineering from The Ohio State University.
