In contrast, Synplicity's customer support occasionally encounters an FPGA design team that has done absolutely no chip-level verification. How can such a difference exist? It's not because FPGA designers don't care if their chips work, and it's not because ASIC designers are obsessive. It's because each design team has adapted to the level of risk associated with their chosen design technology.

The cost of an ASIC respin carries a large business risk as well as a large personal risk to the members of the design team. While ASIC designers risk their careers on a respin, FPGA designers risk their weekends.

The reduced risk makes it possible to treat FPGA design more like software development, where integration is done using the real system in a controlled environment, rather than using a model of the system. If we say that verification happens before the designer commits to hardware, while debug happens afterward, then the ASIC verification crisis becomes the FPGA debug crisis.

In a debug-centric verification flow, the designer verifies modules using simulation with test vectors that generally exercise the functionality of the module. The goal is to thoroughly verify the module's common modes of operation, while verifying corner cases less thoroughly.

When the time comes to integrate multiple modules into a subsystem that can work with real-world data, then the team shifts to in-system debug. The real-world data puts the design through its paces, and the team monitors the key internal signals to diagnose any problems that show up.

Debug-centric verification reduces the need for rigorous development of test vectors that exercise the design in all its modes. Instead, the focus shifts to setting up a controlled environment that will thoroughly exercise the system. This same environment will be used to test the final system.

Until recently, the advantage of fast execution that hardware brings has been offset by the need for long turnaround times needed to make changes to the debug setup. The need for a full synthesis, place and route run has been nearly eliminated by recent developments in incremental debug setup that allow great flexibility in choosing which signals to monitor and in setting up trigger conditions.

For example, the incremental route capability in newer FPGA debug products enable the verification engineer to change the observable signal set, define new breakpoints, and get back into a productive debug session in seconds or minutes. The penalty for having to re-instrument the design to view different signals has been largely eliminated, and the verification engineer can enjoy orders of magnitude (50kHz vs. 50MHz) advantages in verification runtime.

Finally, if we want to treat FPGA debug more like software, then source-level debug is essential. While relying on the visible output of software programs (such as print statements) continues to be a mainstay of software debug, looking at assembly code is limited to rare situations like compiler bugs.

Likewise in hardware, if a designer works in RTL Verilog or VHDL, then the debugger should work at the same level. Any attempt to debug at the synthesized gate level is destined to be inefficient and error-prone; both the setup of signals to monitor and trigger conditions, as well as the analysis of waveforms, requires manual translation steps between the design and the RTL source.

ASIC designers can benefit from many of the advantages of debug-centric verification through the use of FPGA-based hardware prototypes that operate in a controlled environment with real-world data. We have seen ASIC prototype strategies that range from testing critical modules in hardware to building the complete ASIC functionality in a board full of FPGAs. Either way, design teams that have prototyped ASICs report that they have found bugs that they could not conceive of finding through software modeling of the system.

In summary, a source-level hardware debugger makes it as easy to find bugs in the hardware as it has been in the simulation world, but with the coverage of real-world data and the speed of real hardware. Mixing the use of simulation with hardware debug in a debug-centric verification flow can give both ASIC and FPGA design teams better confidence in their designs, with less up-front work in creation of test benches for chip-level verification.

Bob Erickson is vice president of engineering at Synplicity Inc.