Hardware emulation

Hardware emulation

Hardware emulation is the process of imitating the behavior of one or more pieces of hardware (typically a system under design) with another piece of hardware, typically a special purpose emulation system. The goal is normally debugging of the system being designed. Often an emulator is fast enough to be plugged into a working target system in place of a yet-to-be-built chip, so the whole system can be debugged with live data. This is a specific case of in-circuit emulation.

Introduction

The largest fraction of silicon integrated circuit respins are due, at least in part, to functional errors. Thus, comprehensive functional verification is key to reducing development costs and delivering a product on time. Functional verification of a design is most often performed using logic simulation and/or prototyping. There are advantages and disadvantages to each and often both are used. Logic simulation is easy, accurate, flexible, and low cost. However, simulation is often not fast enough for large designs and almost always too slow to run application software against the hardware design. FPGA-based prototypes are fast and inexpensive. But the time required to implement a large design into several FPGAs can be very long and is error-prone. Changes to fix design flaws also take a long time to implement and may require board wiring changes. Since FPGA prototypes have little debugging capability, probing signals inside the FPGAs in real time is very difficult, if not impossible, and recompiling FPGAs to move probes takes too long. The usual compromise is to use simulation early in the verification process when bugs and fixes are frequent, and prototyping at the end of the development cycle when the design is basically complete and speed is needed to get sufficient testing to uncover any remaining system-level bugs. Prototyping is also popular for testing software.

Simulation acceleration can address the performance shortcomings of simulation to an extent. Here the design is mapped into a hardware accelerator to run much faster and the testbench (and any behavioral design code) continues to run on the simulator on the workstation. A high-bandwidth, low latency channel connects the workstation to the accelerator to exchange signal data between testbench and design. By Amdahl's law, the slowest device in the chain will determine the speed achievable. Normally, this is the testbench in the simulator. With a very efficient testbench (written in C or transaction-based), the channel may become the bottleneck. In some cases, a transaction-level testbench is able to feed as much data to the design being emulated as "live" stimulus.

In-circuit emulation improves greatly on FPGA prototyping’s long time to implement and change designs, and provides a comprehensive, efficient debugging capability. While it takes weeks or months to implement an FPGA prototype, it takes only days to implement emulation. And design changes take but a few hours or less. Emulation does this at the expense of running speed and cost compared to FPGA prototypes. Looking at emulation from the other direction, it improves on acceleration’s performance by substituting "live" stimulus for the simulated testbench. This stimulus can come from a target system (the product being developed), or from test equipment. At 10,000 to 100,000 times the speed of simulation, emulation is often the only technique that can deliver the speed necessary to test application software while still providing a comprehensive hardware debug environment.

Debugging simulations vs. emulations/prototyping

It is worth noting that simulation and prototyping involve two different styles of execution. Simulation executes the RTL code serially while a prototype executes fully in parallel. This leads to differences in debugging. In simulation:
*The user can set a breakpoint and stop simulation to inspect the design state, interact with the design, and resume simulation.
*The user can stop execution “mid-cycle” as it were with only part of the code executed.
*The user can see any signal in the design and the contents of any memory location at any time.
*The user can even back up time (if they saved checkpoint(s)) and re-run.

With a prototype:
*The user employs a logic analyzer for visibility, and so can see only a limited number of signals which they determined ahead of time (by clipping on probes).
*The target does not stop when the logic analyzer triggers, so each time the user changes the probes or trigger condition, they have to reset the environment and start again from the beginning.

Acceleration and emulation are more like prototyping and silicon in terms of RTL execution and debugging since the entire design executes simultaneously as it will in the silicon. Since the same hardware is often used to provide both simulation acceleration and in-circuit emulation, these systems provide a blend of these two very different debugging styles.

High end hardware emulators provide a debugging environment with many features that can be found in logic simulators, and in some cases even surpass their debugging capabilities:

*The user can set a breakpoint and stop emulation to inspect the design state, interact with the design, and resume emulation. The emulator always stops on cycle boundaries.
*The user has visibility to any signal or memory contents in the design without the need to set up probes before the run. While visibility is provided also for past time, the amount of time that it can show in the past might be limited in some cases to the depth of the emulator's trace memory.
*The user can even back up time (if they saved checkpoint(s)) and re-run.

Emulation and 2-state logic

Another difference between simulation and acceleration and emulation is a consequence of accelerators using hardware for implementation – they have only two logic states – acting the way the silicon will when fabricated. This implies:
*They are not useful for analyzing X-state initialization.
*They cannot analyze strength resolution, or at least this must be done statically at compile time.
*Emulators do not model precise circuit timing, and hence they will probably not find any race conditions or setup and hold time violations.

These tasks are properly carried out during logic simulation or with a static timing analysis tool.

Emulation versus prototyping

A key distinction between an emulator and an FPGA prototyping system is that the emulator provides a rich debug environment while a prototyping system has little to no debug capability and is primarily used after the design is debugged to create multiple copies for system analysis and software development.

References

*"Electronic Design Automation For Integrated Circuits Handbook", by Lavagno, Martin, and Scheffer, ISBN 0-8493-3096-3 A survey of the field, from which the above summary was derived, with permission.


Wikimedia Foundation. 2010.

Нужно сделать НИР?

Look at other dictionaries:

  • Hardware Emulation Layer — Hardware Emulation Layer,   HEL …   Universal-Lexikon

  • Emulation — The word emulation refers to an ambition and effort to equal, excel or surpass another; to compete or rival with some degree of success, especially through imitation. It can also refer to the simulation of equipment or phenomena by artificial… …   Wikipedia

  • Hardware-assisted virtualization — In computing, hardware assisted virtualization is a platform virtualization approach that enables efficient full virtualization using help from hardware capabilities, primarily from the host processors. Full virtualization is used to simulate a… …   Wikipedia

  • Emulation for Logic Validation — also referred to as Virtual Commissioning. This process involves replicating the behavior of one or more pieces of hardware with a software environment (typically for a system under design). The goal of the emulation engineer is to create an… …   Wikipedia

  • Hardware-in-the-loop simulation — Hardware in the loop (HIL) simulation is a technique that is used in the development and test of complex real time embedded systems. HIL simulation provides an effective platform by adding the complexity of the plant under control to the test… …   Wikipedia

  • Emulation on the Amiga — The Amiga computer can be used to emulate several other computer platforms, including legacy platforms such as the Commodore 64, and its contemporary rivals such as the IBM PC and the Apple Macintosh.MS DOS on Amiga via Sidecar or BridgeboardMS… …   Wikipedia

  • High-level emulation — (HLE) is an approach for construction of emulators, specifically of video game console systems. In HLE, instead of trying to accurately recreate the hardware, to create a platform on which the native code can be run, the effort focuses on… …   Wikipedia

  • Server (Hardware) — Als Host (engl. Wirt, Gastgeber) wird ein in einem Rechnernetz eingebundenes Betriebssystem bezeichnet, das Server oder Clients beherbergt. Neben komplexen Betriebssystemen von Computern können auch spezialisierte Betriebssysteme von… …   Deutsch Wikipedia

  • Amiga emulation — refers to the activity of emulating (mimicking the hardware of) a Commodore Amiga computer system using another computer platform. Most commonly, a user will emulate the Amiga using modern platforms such as Wintel or Macintosh. This allows Amiga… …   Wikipedia

  • Nintendo DS emulation — is the act of emulating the Nintendo DS on non native hardware. Contents 1 History 2 Emulators 2.1 DeSmuME 2.2 Ensata …   Wikipedia

Share the article and excerpts

Direct link
Do a right-click on the link above
and select “Copy Link”