The Battleship Game reminds me of trying to debug a system-on-chip (SoC) design using the in-circuit-emulation (ICE) mode. What, you may ask, does the Battleship Game have to do with chip debugging? More than you can imagine. In fact, finding a bug in ICE mode is like blindly trying to hit the battleship of your adversary, just far more difficult. For one thing, the battleship does not move and you may zero-in on it after several misses. However, the bug can show its effects at different times every time you re-run your test, undermining your efforts at narrowing down its location.

A little perspective may help to understand the issue. Let's step back for a moment and take a look at hardware emulation. Aptix, IKOS Systems, PIE Design Systems, Quickturn and Meta Systems pioneered the field of hardware emulation. The concept was simple: check the design-under-test (DUT) with the actual, physical target system where the yet-to-be-built chip will ultimately be plugged in.

Brilliant! No more writing test vectors or testbenches. Let the real world do the job for you thoroughly and fast. Supposedly, the real world is better at finding nasty bugs lurking in obscure design areas than any software testbench, isn't it?

As it turned out, not all that glitters is gold. For all its dazzling promises, debugging a chip design in ICE mode is slow, cumbersome and frustrating for two reasons: The connection to the target system is troublesome and debugging is a nightmare.

First, you have to connect the emulator to the target system. If you entered a lab in the 1980s or 1990s where one of the early-generation emulators was installed and connected to a target system, you may have seen an atrocious web of spaghetti cables that drastically dropped the mean time between failures (MTBF).

Today's emulator has a cleaner setup supported by a better architecture. Still, you need to design a bridge — that is, fundamentally, a first-in-first-out (FIFO) register — to connect each interface of the target system to the DUT mapped inside the emulator. This will accommodate the fast clock speed of the testbed to the relatively slow clock speed of the emulator.

The bridge typically trades functionality and accuracy for performance. A high-speed protocol such as PCIe or Ethernet would be drowngraded to cope with the intrinsic capacity limitation of the FIFO in the bridge. Furthermore, the cycle-accurate behavior of the bridge will differ from the actual protocol for the exact same reason. If an input/output protocol of the design is not defined yet — namely, it is a new protocol — you cannot develop a bridge for the interface. Moreover, the setting is limited to only one test case per protocol and it does not allow for testing of corner cases or any sort of "what-if" analysis. Also worth mentioning is that an ICE mode setting cannot be accessed remotely without on-site help to plug/unplug the target system.

All of this would make you crave for a hardware description language (HDL) simulator, which explains why hardware emulation has gotten mixed reviews. Perhaps the most underestimated drawback is a lack of deterministic behavior — remember the battleship game — that compromises and prolongs the finding of a bug in ICE mode when the target system clocks the design.

Tracing a bug in the DUT with early hardware emulators would require engineers to attach a commercial or a built-in logic analyzer to the inputs/outputs of the field programmable gate arrays (FPGAs) mapping the DUT. Visibility was implemented via probes chosen at design compile time and limited in number.

This changed when Meta Systems enhanced the built-in logic analyzer to trigger and trace on any DUT register. Despite this improvement, the method had and still has several restrictions. It has limited tracing capabilities in time or a limited number of clock cycles. Only the last hundred thousand cycles can be traced. Triggers can only be attached to registers. As a result, the user ends up making multiple runs to find the debugging window of interest and dump the right waveforms.

The emulation world changed dramatically with the advent of the transaction-based co-emulation technology. By removing the connection to the target system and replacing it with the connection to a virtual test environment based on transactors and high-level testbenches, an entire set of problems disappears.

Transactors can be purchased off the shelf or developed through SystemVerilog behavioral synthesis such as EVE's ZEMI3. High-level testbenches can be created via SystemVerilog in a fraction of the time required by traditional Verilog with fewer errors. Most important, the design stimulus is now deterministic that it can lead to a faster verification closure.

Transactors provide a smooth transition from HDL simulation to emulation. Clocks can be stopped and stepped through, "what-if" scenarios are now possible and corner-cases can be modeled. Nowadays, engineers design chips by writing register transfer level (RTL) code and do not need to be exposed to lab equipment for testing their designs.

By combining SystemVerilog assertions with transactors, you can monitor your design without speed degradation with unlimited debugging capabilities. This gives you a window into your design as wide as you wish, unconstrained by memory space or time limitations for quickly zeroing into a bug.

All this proves that today's emulation has won the "The Battleship Game."

About the author:
Lauro Rizzatti is general manager of EVE-USA. He has more than thirty years of experience in EDA and ATE, where he held responsibilities in top management, product marketing, technical marketing and engineering.