News & Analysis

Viewpoint: Standard FPGA-based emulation will prevail

Lauro Rizzatti

2/24/2009 3:50 PM EST

While emulation is fast becoming the most popular verification tool because design sizes and complexity are defeating software simulation, there's a wide disparity in the kinds of commercially available emulators.

The differences between emulators based on standard field programmable gate arrays (FPGAs) and those based on custom chips, whether based on custom processors or custom FPGAs, are vast. Moving forward, the standard FPGA-based emulator will ultimately prevail. If nothing else, for economical reasons.

Re-tooling and non-recurring engineering (NRE) charges are exceedingly expensive below 65nm and an emulation market of $200 million is not big enough for a large EDA vendor to justify $30 million to develop the custom chip.

On the other hand, there is a clear and sensible roadmap through the use of standard FPGAs at 45- and 32nm and beyond.

In 2008, the largest FPGAs could implement a two-million ASIC gate design. In 2009, that number will jump to four-million ASIC gates and to eight million gates in 2011. The performance and capacity of standard FPGAs will continue to double every two years while pricing will drop by factor of two, as well.

In 2012, it will be possible to produce a 100-million ASIC gate emulator with 16 FPGAs for less than $50,000. This machine will run at approximately 10 MHz. Conversely, at 65nm, the manufacturing cost of a 100-million ASIC gate custom emulator will be in the neighborhood of $500,000 and will run at 500 KHz, making it non-competitive from the outset.

The market is changing rapidly as design teams implement co-verification strategies. More and more, emulators are being used for testing the integration of hardware and software, with fewer and fewer design teams using the in-circuit-emulation (ICE) mode.

Within a few years, 80 percent of design teams will use transaction-based verification. In this deployment mode, the user can control and stop the clock, dump the waveforms directly on the PC.

Or, the user can work with a hardware description language (HDL) simulator in conjunction with a save and restore capability to generate waveforms. The support for direct programming interface (DPI)-based transactors and SystemVerilog assertion language (SVA) will also change the way the hardware designs are debugged.

The costly built-in logic analyzer function of current custom emulators will become useless for most applications.

Moving forward, the remaining motivation for developing a custom emulator will be to minimize the compilation time on small- or medium-sized designs for simulation acceleration applications. On large designs, the compilation time of an FPGA-based emulator is similar to custom emulators.

The supposed superiority in ease of use offered by custom emulators is elusive since equivalent capabilities can be implemented in standard FPGA-based emulators through creative software architectures.

Lauro Rizzatti (lauro@eve-team.com) is General Manager at EVE-USA.





tb1

2/25/2009 2:58 PM EST

"it will be possible to produce a 100-million ASIC gate emulator with 16 FPGAs for less than $50,000. This machine will run at approximately 10 MHz."

People sometimes forget what an emulator is for. It is not just to emulate the design. If you just want to run your chip then just build it. It will run faster than -any- emulator, and it is much easier to setup.

People want emulators to test and debug their designs--faster than is possible with simulators. It is not just how fast you can run the emulation, but how fast you can compile it, how quickly you can debug any problems, and then how fast you can re-compile it again after you find the fix.

If it takes days to compile, then hours or days of running for a bug to show itself, you can't afford the time to add probes, recompile and run again. Many non-FPGA based emulators compile multiple millions of gates in hours, and when running can record the state of every single node in a system around a trigger point. So when the bug occurs, you can don't have to add probes and re-run; you can trace the nets back to the problem and immediately see the waveforms.

If you think of it as a design debugger instead of an emulator there's a better chance you'll look for the right features that will get you to your finished working chip faster.

Sign in to Reply



Please sign in to post comment

Navigate to related information

EE Buzz DesignCon

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)

Feedback Form