Adding Debug Cores for Versal Devices - 2024.2 English - 2024.1 English

Vivado Design Suite User Guide: Dynamic Function eXchange (UG909)

Document ID
UG909
Release Date
2024-11-13
Version
2024.2 English

For Versal device DFX designs, you can instantiate or insert debug cores. In either case, an AXI Debug Hub IP must be added to the design in the target partition where debug is desired. The debug hub must exist in each reconfigurable module to accommodate any debug cores in that RM. Each RM in the parent configuration must include a debug hub to establish the debug infrastructure that will be used in any child configurations.

Instantiation

When using instantiation, manually add debug cores, and connect them to signals you want to probe. In the following block design, Debug Hub IP (green) was added and connects to the NoC. Multiple ILA (red) and VIO (purple) cores were added to monitor two counter IP. Green bug icons were added to the signals to be probed by the ILA cores. By explicitly adding the ILA cores and adding probe points, you can define all the debug details early in the design flow.

Figure 1. Instantiation Example

Insertion

When using insertion, signals are identified in the block design or RTL source, and insertion of the ILA debug core is done later in the flow. To add a debug tag to a signal on a block design canvas, right-click and select Debug, as shown in the following figure.

Figure 2. Insertion Example Before

After you select Debug, the green bug icon is added to the signal, as shown in the following figure.

Figure 3. Insertion Example After

In the Tcl Console, this action appears as adding the DEBUG property to that net:

set_property HDL_ATTRIBUTE.DEBUG true [get_bd_nets {c_counter_binary_0_Q}]

The equivalent process within RTL is done using the MARK_DEBUG attribute. When RTL code that uses this attribute is added to a block design as a module reference, and the Debug Hub IP has been added, the same insertion technique is used. Here is the attribute applied in Verilog:

(* mark_debug = "true" *) reg [31:0] count_out;

Note: In each of these cases, the Debug Hub IP (green) was explicitly added to the BD canvas and connected to the NoC.

Setting Up Inserted Debug Cores

After synthesis, you can identify details about the debug features. This step is necessary for the insertion flow but not the instantiation flow. The insertion flow allows you to defer selection of which signals to probe and the customization of the ILA core itself.

After synthesis completes, open the synthesized design. This post-synthesis view of the parent run can be used for managing the DFX floorplan, because it shows the full design hierarchy for the primary configuration. With this view open, do the following:

  1. In the Flow Navigator, select Set Up Debug.
    Figure 4. Set Up Debug Command
  2. In the Set Up Debug dialog box, click Next.
  3. In the Nets to Debug screen, adjust settings as needed, add more nets if desired, and click Next. This screen shows a list of signals that are tagged with the Debug (BD) or MARK_DEBUG (RTL) property.
    Figure 5. Set Up Debug Dialog Box Nets to Debug
  4. In the ILA Core Options screen, adjust the ILA debug core settings as needed, and click Next and then Finish to complete the debug setup.
    Figure 6. Set Up Debug Dialog Box ILA Core Options

After you click Finish, the tools insert the ILA core. The core is declared, properties of the core are defined, and the core is connected to the existing design logic. This information is stored in the post-synthesis checkpoint for this configuration. The generation of the ILA core itself (as well as the debug hub core) is actually done during the opt_design phase of implementation. In the Netlist view, these cores are still black boxes, as shown in the following figure.

Figure 7. Netlist View

In the Schematic view, these cores are represented by yellow levels of hierarchy, as shown in the following figure.

Figure 8. Schematic View

Save the design checkpoint before continuing.

This sequence of steps for the Set Up Debug command must be repeated for other configurations if reconfigurable modules not included in the parent configuration are to be debugged. For every other reconfigurable module that is expected to have ILA cores inserted, a configuration containing that RM must be opened to declare the ILA core details, if you are not using default settings. The Open Synthesized Design selection in the Flow Navigator only opens the post-synthesis parent run configuration. To add RMs in child configurations, you must perform this action from the Tcl Console. Open a child run configuration by calling open_run directly as follows:

open_run synth_1 -name synth_1 -pr_config <child_configuration>

After opening the child run configuration, the process is the same. Call Set Up Debug to define the details of the ILA core and its connections, and save the modified configuration checkpoint.

Compile the parent and child runs as you would for any DFX design. Debug cores are generated during the opt_design step. You can confirm successful insertion by opening the routed checkpoints and examining the design hierarchy. Reconfigurable modules do not need to have ILA core insertion performed even if other RMs for the same RP have inserted ILA. However, it is recommended that debug hubs are still added to these RMs to maintain a consistent NoC topology. Greybox configurations are supported as child configurations with the insertion flow.

Interacting with the debug cores for a DFX design, regardless of design flow, matches a standard debug solution. For more information on debug capabilities in Versal devices, see this link in the Vivado Design Suite User Guide: Programming and Debugging (UG908). For an example design showing both flow methodologies, see the Versal Device DFX Debug Tutorials available from the AMD GitHub repository.