Most of us have been there: our initial performance requirement has been increased to accommodate a new external memory interface or incorporate pre-processing now required because of an ASIC flaw. The innate flexibility of FPGAs makes them the perfect solution to address these last-minute changes and additions. But adding new capabilities is often much easier than debugging them when things no longer work.

Fortunately, Xilinx® provides a solution. ChipScope Pro™ tools enable you to place logic analysis, bus analysis, and even virtual input and output cores directly into your FPGA design and perform real-time debug and verification.

Although ChipScope Pro cores are optimized for size and performance and can run as fast as 200 MHz in Virtex-II Pro™ FPGAs, this is often not enough. Plus, adding these cores to a design may prevent it from meeting specified timing. For designs operating between 85 MHz and 150 MHz and using less than 80% of the available FPGA resources, ChipScope Pro tools can provide the easy visibility and access needed to debug and verify your designs.

For designs exceeding 150 MHz and/or using more than 80% of FPGA resources, techniques exist that allow you to use ChipScope Pro tools without impacting FPGA design performance.

In this article, we’ll describe three techniques to get the most performance out of ChipScope Pro cores, gain access and visibility to debug your design, and still meet FPGA design performance.

ChipScope Pro Debug Methodology
The easiest way to ensure that ChipScope Pro tools will not impact your design performance is to plan in advance. ChipScope Pro cores are no different that any other IP in your design – they also use logic and block RAM. By adopting a ChipScope Pro debug methodology in advance, determining what signals you would like to access for debug, and how many samples you will need to observe, you will have the best chance of meeting design performance.

The following checklist will help you meet your debug performance goals:

• Decide which signals you want to observe. This is similar to deciding which signals you are going to route out to a test header on your board. The difference is that you place virtual test headers directly within your design. And for those designs requiring more than one core, ChipScope Pro tools allow you to include as many as 15 ILA cores in a single design.
• Define how many trigger ports you need based on how you might want to trigger on different groups of signals. Consider attaching similar signals (such as individual address signals) into the same trigger port while attaching unrelated signals (such as control and data signals) to separate trigger ports. Not only will the separate trigger ports make it easier for you to create trigger conditions, but by using multiple smaller trigger ports, you might find that it is easier for the implementation tools to pack, place, and route your design.
• Decide which signals are to be used as triggers and which signals are to be captured as data. You can conserve device resources by being careful to capture only the signals you need to debug your design. Although ChipScope Pro tools provide many of the familiar trigger capabilities found in expensive benchtop logic analyzers (such as multiple trigger ports and complex trigger sequencing), you should always be aware that many of these features consume additional device resources.
• Determine the number of samples you need to observe. To do this, determine the time over which you anticipate needing to view data and divide this by the system clock rate. As many as 16,384 samples of data storage are available using on-chip block RAM. If you need more storage, you can use multiple debug cores or you can use the ChipScope Pro-enabled Agilent™ FPGA dynamic probing solution, which allows you to store internally probed signal data directly on an external Agilent logic analyzer.
• Decide how you are going to get data off-chip. Start with a JTAG port and Agilent trace port. You can use the JTAG port for configuration, hardware debug, and software debug. The Agilent trace port provides the flexibility to interface to the Agilent 16900 series logic analyzer with FPGA dynamic probing technology. You will probably already have JTAG set up on your board for FPGA configuration. The Agilent trace port uses between four and 128 user I/O pins that tie directly to a Mictor™ or Agilent soft-touch probe pad connector. Instructions for laying out these connectors are included in the Agilent data sheet, available at www.xilinx.com/chipscopepro/.
• Use the core generator to define the ILA cores to the specifications you have defined in the previous steps. The ChipScope Pro core generator will produce embeddable EDIF netlists and HDL component instance templates that you can incorporate into your HDL design. If your design has already been synthesized, you can use the ChipScope Pro core inserter to add ChipScope Pro cores to a design by selecting which nets and signals you want to view.

Techniques to Achieve Performance
What if you have not planned for debug? Let’s say your design is running at close to 200 MHz and something is not functioning correctly. When you add a ChipScope Pro ILA core to view signals in the faulty logic, the design fails to meet your timing requirements. Here are some techniques that can help:

• Reduce the size and complexity of your trigger ports and corresponding match units. Start with a basic trigger type, with a width as narrow as possible. For example, an 8-bit basic match unit will consume a fraction of the logic of a 36-bit range-type match unit.
• Use “trigger same as data.” By selecting trigger same as data, you reduce the number of loads on the instrumented design nets from two to one.
• Avoid critical paths. Understand the critical paths within your design and avoid instrumenting them if at all possible.
• Watch what you instrument. Avoid instrumenting combinatorial logic, which may cause the new logic implementation to split into multiple slices. Whenever possible, try to instrument the outputs of flip-flops instead.
• Apply area constraints to ChipScope Pro cores. Bound the inner logic of a ChipScope Pro core and allow the outer flip-flops to float. A tighter fit may result in higher performance of the ILA core while allowing the outer flip-flops to be placed close to the instrumented design nets.
• Properly constrain your design. Run “trce -a” to report unconstrained nets within your design. Apply timing constraints where needed and use a constrained system clock net to drive any ChipScope Pro cores.
• Disable RPMs. Sometimes allowing the ChipScope Pro core logic to float – particularly the flops that make up the cores – enables you to better fit ChipScope Pro cores within any available logic.

The steps to guide filing are:

1. Synthesize your design.vhd into design.ngc using your chosen synthesis tool (substitute design.edf for design.ngc, if you are not using the xst synthesis tool).
2. Translate your design.ngc into design.ngd using ngdbuild.
3. Map your design.ngd into design_map.ncd using the map tool.
4. Place and route your design._map.ncd to design_par.ncd using the par tool.

   Now add ChipScope Pro cores to this design by following these steps:

5. Copy the design.ngc to design_debug.ngc.
6. Insert ChipScope Pro cores into design_debug.ngc using the ChipScope Pro core inserter tool.
7. Translate design_debug.ngc into design_debug.ngd using ngdbuild.
8. Map design_debug.ngd into design_debug_map.ncd using a -gm (guide mode) option, specifying your original design_map.ncd as the guide file. You will have the option of specifying exact, incremental, or leveraged guide modes. Start with exact; it may take a little longer to compile, but will probably deliver the best results. If that doesn’t work, or if you would like a better result, try the leveraged option. This option allows logic in your design to be moved if it will benefit placement of the new ChipScope Pro cores.
9. Place and route design_debug_map.ncd into design_debug_par.ncd using a -gf (guide file) option and specifying your original design_par.ncd as the guide file. Use the same -gm guide mode option (exact, incremental, or leveraged) that you used in step 8.
10. Convert design_debug_par.ncd into a bitstream called design_debug_par.bit and use the ChipScope Pro analyzer to configure and debug your FPGA design.

If after performing these steps your instrumented design is still not meeting timing, you may want to go back to step 2 in your original design and try to allocate an area region for ChipScope Pro cores. Then repeat the remaining steps.

Conclusion
In this article, we’ve shown you techniques for debugging high-speed FPGA designs using ChipScope Pro tools. No design is the same and sometimes more advanced techniques are required. If you have techniques that have worked for you and you’d like to share them, or if you need help in implementing any of the techniques described, please send an e-mail to chipscope_pro@xilinx.com.

Printable PDF version of this article with graphics.  (8/1/04) 190 KB