Increasing visibility in FPGA prototypes and emulators

 
With the rise in design complexity and corresponding verification, many ASIC design teams are using FPGAs for prototyping and emulation. These hardware-based verification methods overcome performance shortcomings associated with software-based simulation, thereby allowing a greater number of test scenarios to be verified. However, with these advantages come several major issues that must be addressed when moving from software-based to hardware-assisted verification. Among these issues is the challenge to understand the internal behavior of the design prototype when the system does not perform as expected. FPGA prototyping and emulation can only be adopted if they provide sufficient visibility for efficient debugging. Furthermore, the visibility must be achieved with little overhead otherwise the benefit of performance gains will be erased by lengthened run times.

Inherent in silicon is the extremely limited signal access and visibility into the device. As a result, finding and analyzing the problems in FPGAs is dreadfully tedious and time consuming. Many approaches for improving FPGA debug focus on increasing visibility, such as multiplexing internal signals to output pins. However, these methods utilize significant resources to gain even the smallest insight into the silicon. Alternate methods – such as internal logic analyzers (ILAs) – are structured, but are more suitable for understanding the values of a few architectural registers rather than combinational logic values. These and other related methods often require a "trial and error" approach since the engineer may not initially know what part of the design needs to be examined. Each iteration is time-consuming because of the time it takes to insert observation points and recompile the design into the FPGA. And once the relevant signal values are accessed, the next step is analysis. Because extracting the data and analyzing it are so tightly integrated, the arduous task of debugging the FPGA has become a major bottleneck in adopting prototyping and emulation techniques for verification.

To read the full article, click here