How emulation’s virtual mode boosts productivity: Part One
Hardware emulation can be deployed in two modes.
- In-circuit-emulation (ICE): This consists of testing the design-under-test (DUT) with real traffic in a physical environment.
- Virtual mode: The DUT is here verified via a test environment modeled in software.
The first part of this article describes the advantages of the virtual mode over ICE. The second details a verification strategy, Veloce VirtuaLAB, built on top of the virtual mode. Three test cases will then show the benefits of Veloce VirtuaLAB.
Emulation in virtual mode
The virtual mode boosts emulation productivity in several ways. It simplifies the emulator’s deployment, eases design debug, increases debug accuracy, expands verification possibilities beyond testing a DUT with real-world traffic, and extends utilization to multiple concurrent users through remote access.
Simpler deployment
In ICE mode, the emulator’s deployment needs the insertion of speed adapters and cabling/connectors between the target system and the emulator to accommodate the fast clock rate of the target system and the comparatively slow clock rate of the emulator. The assembly creates a series of problems with installation, use, and system reliability.
The target system in virtual mode consists of software code running in a host workstation connected to the emulator via a PCIe card.
Initializing the DUT in virtual mode is much easier than for ICE. The lack of physical dependencies because of the speed adapter (such as hardware reset, cabling/connectors, noise, and RF interference) simplifies the process.
Easier design debug
Design debug in ICE mode is constrained by poor design visibility, which is limited to small subsets of internal signals over short time spans. When tracing a bug, constraints make the user perform multiple runs to guess the signals to monitor in given time windows.
It is difficult to reproduce debug conditions in ICE mode because the physical environment behaves in a random, non-deterministic way that leads to non-repetitive runs. It may happen that in two consecutive runs the bug appears and disappears, leading to inconclusive results.
Design debug in virtual mode is far easier because visibility extends to the entire design space without limits in time.
More to the point, the environment in virtual mode is deterministic. This allows full control of the DUT by the software testbed. By making multiple runs repetitive, it removes the uncertainty and confusion from bug tracing.
More accurate design debug
In ICE mode, the test environment and DUT operate in two different time domains connected by a speed adapter. This leads to errors and inaccuracies because what is being measured is physically separated from where it is being measured.
By contrast, the test environment and DUT in virtual mode run in a single time domain ensuring that what is being measured happens where it is measured.
More verification tasks
Early hardware emulation was focused on the ability to perform functional verification of larger CPU/Graphics designs with real traffic. At the time, ICE mode was the only deployment mode available.
Virtual mode revealed more verification opportunities. These include the ability to control the DUT, start/stop and repeat a run consistently, retrieve the activity of all internal signals and show them in waveforms. They became the foundation for new verification tasks.
The tasks include:
- Hardware debugging: Today’s emulators support the leading methodologies used by verification engineers, such Universal Verification Methodology (UVM), SystemVerilog Assertions (SVAs), and forms of functional coverage.
- Hardware/software integration: Hardware emulation ensures that embedded system software works as intended with the hardware. Users can trace a software bug in the hardware and, conversely, a hardware bug that affects the software.
- Low-power verification: By controlling power islands and related issues, such as retention, corruption, isolation, and level shifting (as defined in the unified power format (UPF)), a thorough verification of the power domain can be performed.
- Power estimation: Emulation can track switching activity at the functional level and generate a database for use with power estimation tools, including the creation of a ‘power histogram’.
- Performance characterization: Emulation, while not timing accurate, is cycle-accurate and can be used to characterize design performance by counting the number of cycles required to complete a specific function or task.
Multi-user and remote access
It is theoretically possible to have multiple users in ICE mode, but in practice the setup prevents resource sharing among users because physical connections limit or lock out emulation partitions. The limited number of I/O channels reduces communication bandwidth. So in reality multiple users is not a pragmatically viable idea.
Remote access is also possible in ICE mode, but again not practical. It requires on-site supervision to serve users and change the ICE target environment to meet their needs 24/7 from anywhere in the world.
In virtual mode, emulation resources are efficiently shared with no physical constraints so user configurations can be changed with software, In addition, I/O bandwidth in co-modeling is rather large, and multiple users can access the emulator remotely without a single supervisor in the loop.
Enterprise resourcing
The virtual mode relocates the emulator in a datacenter, eliminating downtime caused by cable dislodgement, pin breakage and delays until local staff can swap cables to provide access for various external hardware target systems. Virtual mode transforms the emulator into an enterprise resource, sharable with a reproducible environment and more reliable with higher uptime.
In conclusion, the virtual mode outperforms the ICE mode in many respects at the conceptual level, but requires the creation of the stimulus or testbench that the physical mode gets via real-world traffic.
Part Two look at how these advantages can be exploited in actual verification scenarios.