Hardware emulation

This article is about emulating hardware with other hardware. For emulation of hardware using software, see emulator.
Ikos NSIM-64 Hardware simulation accelerator.

In integrated circuit design, 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 emulation model is usually based on a hardware description language (e.g. Verilog) source code, which is compiled into the format used by emulation system. The goal is normally debugging and functional verification 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.

Sometimes hardware emulation can be confused with hardware devices such as expansion cards with hardware processors that assist functions of software emulation, such as older daughterboards with x86 chips to allow x86 OSes to run on motherboards of different processor families.

Introduction

The largest fraction of silicon integrated circuit respins and steppings are due at least in part to functional errors and bugs inadvertently introduced at RTL stage of the design process. 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 FPGA 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. With traditional vendor tools, FPGA prototypes have little debugging capability, probing signals inside the FPGAs in real time is very difficult, and recompiling FPGAs to move probes takes too long. This is changing with the emergence of more advanced FPGA prototype debug tools[1] that remove limitations on signal visibility. 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. FPGA 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 somewhat on FPGA prototyping’s implementation times, and provides a comprehensive, efficient debugging capability. Emulation does this at the expense of running speed and high cost ($1M+) compared to FPGA prototypes ($75K). 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 makes it possible 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:

With a prototype:

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:

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:

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

Emulation versus prototyping

A key traditional distinction between an emulator and an FPGA prototyping system has been that the emulator provides a rich debug environment, while a prototyping system has little or no debug capability and is primarily used after the design is debugged to create multiple copies for system analysis and software development.had a number of limitations, primarily due to the difficulty of accessing signals. New tools that enable full RTL signal visibility with a small FPGA LUT impact, allow deep capture depth and provide multi-chip and clock domain analysis are emerging to allow efficient debug, comparable to the emulator.[2]

Emulation using substitute hardware

Sometimes, legacy devices can contain things like vacuum tubes and electric motors. In some cases, these components can be replaced with solid-state equipment to retrofit onto it.

For instance, sometimes external CD players using a control bus on car stereos can be replaced with solid-state, mechless emulators that allow USB flash drives and SD cards to provide audio content, while channelling signals to masquerade as a "CD changer", simply by putting directories on solid-state memory cards.

Hybrid hardware/software emulation

Sometimes software can be emulated with hardware modules, so that the original processor chip for the emulated system can be used to assist runtime. A very early example of this is the Atari 5200's module cartridge for Atari 2600 games. Colecovision even used an Atari 2600 emulation cartridge too.

Apple II expansion cards were available for Macintosh computers after the Apple II line was discontinued. Amiga computers even used expansion cards for x86 chips so they could run DOS.

See also

References

  1. "Tektronix Shakes Up Prototyping, Embedded Instrumentation Boosts Boards to Emulator Status". Electronic Engineering Journal. 2012-10-30. Retrieved 2012-10-30.
  2. 1 2 "Tektronix hopes to shake up ASIC prototyping". EE Times. 2012-10-30. Retrieved 2012-10-30.
  3. "Break Through Your ASIC Prototyping Bottlenecks". 2012-10-23. Retrieved 2012-10-30.

Further reading

This article is issued from Wikipedia - version of the 6/7/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.