FPGA designers today face unprecedented challenges debugging their designs. FPGAs with four million equivalent gates are commonplace and their sizes are increasing quickly.
Creating designs this large is difficult enough, but debugging them is an even greater challenge. The opportunities for bugs to arise grow exponentially with size, since there are so many more combinations that could go wrong. At the same time, we are seeing an increased use of FPGAs in end-user products of many kinds.
Debug time is often the gating factor in determining when such products reach the market and determining not just how much profitability is realized, but in some cases whether there is a profit.
In the past, designers debugged their FPGAs by plugging them onto a board and then analyzing them with probes and logic analyzers. FPGA vendors currently offer tools that make it somewhat easier to probe internal design signals inside the FPGA, much like a logic analyzer, but there are limitations and usage issues that make this very difficult for use with very large FPGAs.
Not only do these traditional approaches take considerable manual time and effort, but they suffer from limitations such as pin availability and usable memory dictated by the available FPGA memory.
More problematic however, is the challenge associated with synthesis, where familiar RTL names are transformed into gates with unfamiliar names that the designers must decipher in order to track down bugs.
With rapidly advancing FPGA complexity, growing time-to-market pressures and more engineering resource constraints, verification engineers can simply no longer tolerate the limitations of these outdated techniques. FPGA verification engineers must adopt debugging methodologies that support today's multi-million gate FPGAs.
They require more ASIC-like debugging tools and methodologies. In addition FPGA designers must take a proactive approach that heads off rising FPGA complexity, instead of simply reacting to it. These pressing requirements have given rise to a new generation of FPGA debugging tools and methodologies, which are already having a significant impact on the FPGA design process.
FPGA Debugging in RTL
To elevate productivity, FPGA debuggers need to stop working at the gate level. Just as C programmers use C for debugging their code instead of the assembly language code it produces, FPGA designers should use RTL for debugging their FPGA designs and not the gate-level description generated by synthesis.
Verilog, System Verilog and VHDL are the standard, preferred environments for designing FPGAs because of all the high-level features and functions these languages provide for simplifying the design task. The same features and functions greatly simplify FPGA debugging as well and should therefore be used for the debug process.
But RTL simulators by themselves are far too slow for debugging large FPGAs, especially ones that require real-world stimulus for things like video and imaging applications. Already filling this gap are specialized tools, which complement RTL simulators as needed.
One such tool is the Identify RTL Debugger, which is part of the Synplify Premier FPGA synthesis product portfolio from Synopsys (for the purpose of this article the specific technical characteristics of a leading-edge, integrated FPGA synthesis product portfolio will be illustrated by the Synplify Premier portfolio).
Debug using an operating FPGA is orders of magnitude faster than software simulators. The Identify tool allows debugging teams to annotate the signals and conditions they want to monitor directly into their RTL code and then run synthesis and place-and-route to implement the FPGA device.
Once the FPGA has been programmed, the tool then allows users to view actual signal values directly in the RTL code and debug the live FPGA in-system running at full operating speed. Using a method such as this, design teams are far more productive and the end product employing the FPGA reaches the market much sooner.
