Design Article
Tell us What You Think
We want to know what you thought about this Design. Let us know by adding a comment.
Bugs Be Gone!
Angela Sutton, Synopsys
11/29/2012 2:28 PM EST
Editor's Note: This article appeared in the autumn 2012 edition of Xcell Journal magazine, and is reproduced here with the kind permission of Mike Santarini, Publisher and Senior Manager, Xcell Journal and Editorial Services, Worldwide Communications, Xilinx.
When your FPGA design fails to synthesize or fails to operate as expected on the board, the cause may not be obvious and the source of the failure may be hard to pinpoint among potentially thousands of RTL and constraint source files, many of which may have been authored by another designer. Given how lengthy FPGA design iterations and runtimes have become, designers need to find and root out what may be a large group of errors early in the design process and seek methods to focus the validation of the design on the board.
It is essential to apply smarter techniques to isolate specific errors under specific conditions, relate parts of the circuit that are behaving badly back to the source and apply the incremental fixes. You can save time by performing rudimentary design setup checks on clocks, constraints and module-level interfaces with a view to making your design specification good, before you waste hours in synthesis and place-and-route (P&R).
Synopsys’ Synplify Premier and Synplify Pro FPGA design tools and Identify RTL Debugger are among the products available to designers to handle these tasks. Such tools include features that enable designers to quickly isolate bugs and effectively reduce the length of runtimes and the number of iterations needed to bring up their boards.
Pinpointing a problem on the board
When functional errors become apparent on the board, it may be quite challenging to narrow down the cause of the problem. To debug the design, it is necessary to create additional circuitry and preserve certain nodes so that you can probe, tap and analyze data produced by the design under operation. Let’s examine how to find errors using board-level debug software.
By following a four-step approach with an RTL debugger, you can pinpoint and then sample signals and conditions of interest. You can then relate your observations back to the original RTL to narrow down the cause of the problem, which may reside in the RTL specification or constraints setup.
Step 1: Specify probes. Specify within the RTL exactly what signals and conditions you want to monitor. Here you state watchpoints (signals or nodes to be observed) and breakpoints (RTL control flow statements such as IF, THEN and CASE statements) whose operation is of interest to you.
Step 2: Build the design with probes. Synthesize the FPGA design with additional monitoring circuitry: an intelligent in-circuit emulator (IICE), which captures and exports debug data according to the specification of what you wanted to monitor.
Step 3: Analyze and debug. After you have synthesized the design, run the design and observe the data using the RTL debugger. As you run your tests on the board, the watchpoints and breakpoints together will trigger data sampling, allowing you to observe and debug the circuit’s behavior at very specific nodes under very specific conditions of interest. You can write the observed sampled data to a VCD file and relate it back to the RTL.
Step 4: Apply an incremental fix. Once you have found a bug, you can fix it incrementally in the RTL or constraints, using hierarchical and incremental flows.
Visual inspection of timing and functional errors
FPGA design and debug tools have the added benefit of allowing the display of RTL and netlist-level schematics. For example, a schematic viewer tool with interactive debug capabilities displays RTL and netlist schematic representations of the design to allow you to visualize and relate reports of timing and VCD data (from your design operating on the board) back to the RTL source. The viewer includes an RTL View, available after the synthesis RTL compile phase, in which a design is schematically represented by technology-independent components such as adders, registers, large muxes and state machines. From this RTL schematic you cross-probe back to your original RTL, to adjust it if the design does not appear to be specified as intended, and to the constraints editor, where you can update and more easily specify constraints (Figure 1).
Figure 1. You can debug RTL and constraints in the RTL View in a schematic viewing tool. Here you can relate constraints to the design spec and then drag and drop them directly into the constraints editor, where you can adjust or update them. (Click Here to see a larger version of this image).
To trace the source of any incorrect operation back to the RTL itself, you can use the RTL debugger to superimpose observed operation data live on top of the RTL schematic view.
Schematic viewers include a netlist-level Technology View showing the actual design implementation after synthesis. In the HDL Analyst schematic viewer, this view is based on Xilinx device primitives such as lookup tables, registers and DSP slices. You can cross-probe paths in this schematic back to your original RTL, as well as your eventual timing reports post-synthesis and post-P&R to assess and improve overall performance.
Next: Debugging big designs
When your FPGA design fails to synthesize or fails to operate as expected on the board, the cause may not be obvious and the source of the failure may be hard to pinpoint among potentially thousands of RTL and constraint source files, many of which may have been authored by another designer. Given how lengthy FPGA design iterations and runtimes have become, designers need to find and root out what may be a large group of errors early in the design process and seek methods to focus the validation of the design on the board.
It is essential to apply smarter techniques to isolate specific errors under specific conditions, relate parts of the circuit that are behaving badly back to the source and apply the incremental fixes. You can save time by performing rudimentary design setup checks on clocks, constraints and module-level interfaces with a view to making your design specification good, before you waste hours in synthesis and place-and-route (P&R).
Synopsys’ Synplify Premier and Synplify Pro FPGA design tools and Identify RTL Debugger are among the products available to designers to handle these tasks. Such tools include features that enable designers to quickly isolate bugs and effectively reduce the length of runtimes and the number of iterations needed to bring up their boards.
Pinpointing a problem on the board
When functional errors become apparent on the board, it may be quite challenging to narrow down the cause of the problem. To debug the design, it is necessary to create additional circuitry and preserve certain nodes so that you can probe, tap and analyze data produced by the design under operation. Let’s examine how to find errors using board-level debug software.
By following a four-step approach with an RTL debugger, you can pinpoint and then sample signals and conditions of interest. You can then relate your observations back to the original RTL to narrow down the cause of the problem, which may reside in the RTL specification or constraints setup.
Step 1: Specify probes. Specify within the RTL exactly what signals and conditions you want to monitor. Here you state watchpoints (signals or nodes to be observed) and breakpoints (RTL control flow statements such as IF, THEN and CASE statements) whose operation is of interest to you.
Step 2: Build the design with probes. Synthesize the FPGA design with additional monitoring circuitry: an intelligent in-circuit emulator (IICE), which captures and exports debug data according to the specification of what you wanted to monitor.
Step 3: Analyze and debug. After you have synthesized the design, run the design and observe the data using the RTL debugger. As you run your tests on the board, the watchpoints and breakpoints together will trigger data sampling, allowing you to observe and debug the circuit’s behavior at very specific nodes under very specific conditions of interest. You can write the observed sampled data to a VCD file and relate it back to the RTL.
Step 4: Apply an incremental fix. Once you have found a bug, you can fix it incrementally in the RTL or constraints, using hierarchical and incremental flows.
Visual inspection of timing and functional errors
FPGA design and debug tools have the added benefit of allowing the display of RTL and netlist-level schematics. For example, a schematic viewer tool with interactive debug capabilities displays RTL and netlist schematic representations of the design to allow you to visualize and relate reports of timing and VCD data (from your design operating on the board) back to the RTL source. The viewer includes an RTL View, available after the synthesis RTL compile phase, in which a design is schematically represented by technology-independent components such as adders, registers, large muxes and state machines. From this RTL schematic you cross-probe back to your original RTL, to adjust it if the design does not appear to be specified as intended, and to the constraints editor, where you can update and more easily specify constraints (Figure 1).
Figure 1. You can debug RTL and constraints in the RTL View in a schematic viewing tool. Here you can relate constraints to the design spec and then drag and drop them directly into the constraints editor, where you can adjust or update them. (Click Here to see a larger version of this image).
To trace the source of any incorrect operation back to the RTL itself, you can use the RTL debugger to superimpose observed operation data live on top of the RTL schematic view.
Schematic viewers include a netlist-level Technology View showing the actual design implementation after synthesis. In the HDL Analyst schematic viewer, this view is based on Xilinx device primitives such as lookup tables, registers and DSP slices. You can cross-probe paths in this schematic back to your original RTL, as well as your eventual timing reports post-synthesis and post-P&R to assess and improve overall performance.
Next: Debugging big designs
|
|
|
|
|
Navigate to related information