FONT SIZE : AAA
Deciding what type and amount of debug instrumentation to add to the design depends on two key factors:
• Type of issue being debugged
• Resources available for debug instrumentation
The types of design functionality issues can range from simple status and/or control issues to complex logic and/or system-level issues. The amount of resources available in the device (especially block RAM resources) can be the limiting factor in choosing the appropriate debug instrumentation IP. Table 17.2 shows how the Xilinx debug instrumentation options address various debug scenarios.
It is important to consider two guidelines when choosing signals to debug:
• Select signals that will provide the necessary information to fifi nd and fifi x the bug without exceeding device resources
• Select signals that do not degrade the performance and/or functionality of the design
a Amount of block RAM varies with IP port width and data depth parameters. See Table 17.1 for details
b JTAG-to- AXI Master uses two to six block RAM tiles, depending on IP parameters
c The number of block RAM depends on the number of transceiver QUADs available in the target device
When choosing what signals to debug, it is usually best to select signals that are driven by synchronous elements such as flfl ip-flfl ops, block RAMs, etc. The act of probing synchronous elements will not typically change the circuit unless the register would otherwise be combined into a primitive element (such as a block RAM output register or I/O block register). If you want to debug the outputs of combinational logic, it is important to consider how the act of probing the circuit will change its implementation by preventing the tools from optimizing it.
Along with deciding what signals to debug, it can be equally important to decide how to add debug instrumentation to a design. There are two methods for adding debug instrumentation
• Source-level instantiation of debug cores
• Netlist-level insertion of debug cores
In the source-level instantiation method for adding debug instrumentation to a design, you directly instantiate the debug IP in the design source (e.g., HDL source code or IP Integrator block design). The debug IP is generated separately and can either be synthesized separately (i.e., out of context ) or with the design-under-test (i.e., in context). You can add any of the debug cores described in Table 17.2 using the source-level instantiation method.
In the netlist-level insertion method, you add the debug instrumentation to the post-synthesis design netlist. You choose what signals to debug and how to debug them and then the Vivado software tools automatically insert the debug IP into the design-under-test netlist. You can add only the ILA debug core to the design using the netlist-level insertion method.
Some of the benefifi ts for each method of adding debug instrumentation to a design are described in Table 17.3
Manufacturer:Xilinx
Product Categories: FPGAs (Field Programmable Gate Array)
Lifecycle:Active Active
RoHS: No RoHS
Manufacturer:Xilinx
Product Categories: Diodes TVS
Lifecycle:Active Active
RoHS: No RoHS
Manufacturer:Xilinx
Product Categories: FPGAs
Lifecycle:Active Active
RoHS: No RoHS
Manufacturer:Xilinx
Product Categories: FPGAs (Field Programmable Gate Array)
Lifecycle:Active Active
RoHS:
Manufacturer:Xilinx
Product Categories: Embedded - FPGAs (Field Programmable Gate Array)
Lifecycle:Obsolete -
RoHS: No RoHS
Support
