Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > EDA/IP

Hybrid emulation: A practical solution

Posted: 21 Sep 2015 ?? ?Print Version ?Bookmark and Share

Keywords:SoC? ARM? FPGA? prototyping? embedded processing systems?

What of the rest of the SoC? There will probably be some new design, some differentiating hardware or new IP (my old associate will be happy to hear). We will need models for these "bespoke" blocks in order to create the fully-populated virtual platform. As mentioned in my introduction, the make-or-break for early adopters of virtual platforms was the availability of SystemC models for new blocks; however, these may often be available first as RTL.

There are a number of use modes in which hybrid emulation platforms can be beneficial; these are listed in the table.

Table: Seven key use modes for hybrid emulation.

We will consider each of these in turn, but the one key enabler for all of these hybrid emulation use modes is the link between the virtual and the physical parts of the system.

Thank you for the SCE-MI
Thankfully, there is already a transaction-level method for linking SystemC virtual platforms with emulatorsFPGA-based or otherwisethis being the Standard Co-Emulation Modelling Interface, or SCE-MI. Aldec employs SCE-MI compliant interfaces in order to link a variety of simulators and HES.

The same SCE-MI interfaces are adapted for use in linking HES to virtual platforms, as illustrated in figure 3. Here we can see that the FPGA hardware is implementing the RTL of a subset of the SoC, perhaps a new graphics function that needs to act upon the real accelerator hardware.

Figure 3: Simplified view of SCE-MI linking a virtual model and an FPGA emulator.

The function is intended to interface with the CPU subsystem via a bus network on the SoC, but in the hybrid emulation platform it does this via a SCE-MI interface. There may be a number of such interfaces in a real hybrid emulation platform (see the partitioning discussion below), but we have simplified this to a single interface in the diagram. Communications between blocks within the virtual platform are at the transaction level; those transactions relevant to the new function implemented in the emulator are also transactional, but must be converted into (and from) cycle-accurate signal transitions within the hardware.

In a virtual platform, SystemC is typically used to link transaction-level models together. SystemC is also used to create TLM wrappers for the purpose of integrating the virtual platform with external modules. In the case of SCE-MI, for example, Aldec provide adaptors that convert relevant SystemC TLM activity into SCE-MI messages, which then communicate with the physical transactors in HES. This is shown as the generic TLM2SCE-MI block in Figure 3 but, in fact, different adaptors are used for different interface standards. For example, Aldec's TLM2SCEMI-AXI Verification IP provides the connection between their HES FPGA-based emulator and a virtual platforms employing ARM's AMBA AXI bus.

Mode 2: The only way is virtual
We've seen how RTL can be used to replace missing transaction level models, and the second use mode in Table 1 is the opposite face of the same coin. With the use of SCE-MI, we can create a hybrid emulation platform in order to substitute a transaction-level model for not-yet-available RTL blocks. In some cases, we don't have access to the RTL for the CPU IP anyway, so we would need either to use something like Fast Models or to mount a hardware test chip into the emulator. However, the very latest CPU IP often has a virtual model available well before a customer-usable test chip.

Mode 3: Who's accelerating who?
It is use mode #3 that has recently been driving the rise in interest in hybrid emulation due to its promise of accelerating overall simulation performance. This might seem a little odd, given that an FPGA-based prototype is the fastest verification platform; where software is concerned, however, it is not simply a matter of clock frequency, but rather a matter of how quickly we can fetch and execute the CPU instructions and how fast we can move the appropriate data around the SoC with the necessary accuracy. If we can't meet performance targets with the whole SoC in an FPGA-based prototype or an emulator then, if we don't need cycle-accurate behaviour within the CPU, we can replace the CPU(s) with Fast Models running in a virtual platform linked via SCE-MI.

Virtual models of the CPU run Instruction Set Simulation (ISS) rather than model the CPU's gate-level behaviour, and hence perform much faster than running its RTL implemented in FPGA, or an emulator. ARM Fast Models also represent additional device-specific functionality, such as cache coherency, that a more generic ISS would ignore, but they still maintain the performance advantage. As an example, a CPU IP sub-system may typically run at 2GHz in 28nm silicon, so how fast will it run in various verification platforms? There are many dependencies, but the CPU's RTL might only reach 20MHz when partitioned into an FPGA-based prototype, or just 2MHz in a traditional "Big Box" emulatoran FPGA-based emulator would be somewhere between those two figures. That same processor's virtual platform might run at a rate equivalent to more than 1GHz, although this figure is slightly misleading given that the models are untimed, so it is better considered in terms of operations per second.

?First Page?Previous Page 1???2???3???4???5?Next Page?Last Page

Article Comments - Hybrid emulation: A practical soluti...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top