ICE debugging: The end of the battleship game

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.