Interacting with Debug Instrumentation

Once you have added the debug instrumentation to the design, the design has been successfully implemented, and the design meets all timing constraints, it is time to program the design into the device-under-test and debug it. This section describes several ways to interact with debug instrumentation in a simple example design. Figure 17.2 shows the simple example design that contains a MicroBlaze microprocessor, a block RAM memory buffer, a UART peripheral, and a GPIO peripheral.

The example design shown in Fig. 17.2 has been instrumented with the following debug IP cores:

• An ILA core to monitor the AXI interfaces of the block RAM controller

• A VIO to monitor the inputs and outputs of the GPIO peripheral

• A JTAG-to- AXI Master to read/write the contents of the block RAM

The example design containing this debug instrumentation is shown in Fig. 17.3 . The arrows indicate the new IP inserted due to the debug instrumentation.

Connecting to Hardware and Programming the Device

Before interacting with the debug cores in the design in hardware, you need to connect to the device-under-test via a JTAG cable and program the design into the device-under-test. In a typical lab environment, the JTAG cable for the target system is attached to the host machine that is running Vivado. In this case, clicking the Auto Connect toolbar button of the Hardware window in the Hardware Manager will connect to the locally attached JTAG cable, as shown in Fig. 17.4

Example design before adding debug instrumentation.png

Using Auto Connect to connect to a JTAG cable.png

Once the connection to the JTAG cable is established, Vivado scans the target system to detect the devices in the JTAG chain . After Vivado detects the xc7k325t_0 FPGA device, the next step is to program the device with the bitstream fifi le and debug probes fifi le that correspond to the design in the current project, as shown in Fig. 17.5 . The last step before debugging the design involves Vivado automatically detecting the debug cores in the device-under-test, as shown in Fig. 17.6

Taking a Basic Measurement Using the ILA Core

The ILA core is very useful for triggering and capturing events as they occur in real time in the design-under-test. In the example design shown in Fig. 17.3 , an ILA core is used to monitor transactions on the AXI interface of the block RAM controller peripheral.

Programming the device-under-test.png

ILA basic.png

A common measurement to take when monitoring an AXI interface is the start of read transaction which is signififi ed by the read address acceptance event ( ARVALID = 1 and ARREADY = 1 ). The basic trigger setup of the ILA core can be used to take this measurement, as shown in Fig. 17.7 .

After arming the ILA core to trigger on the start of an AXI read transaction, the ILA core waits for the trigger condition to occur. Once the trigger condition occurs, the captured data is uploaded and displayed in the waveform viewer, as shown in Fig. 17.8

Waveform showing captured data after fi rst AXI read transaction.png

ILA setup for.png

The ILA core uses on-chip block RAM to store captured data samples. In its default setup, the ILA core captures a data sample every clock cycle following the trigger event. In many cases, it is desirable to only capture data samples that satisfy a particular capture condition. For instance, it might be desirable to only capture data samples when either the AXI address and/or data is valid. However, in the waveform shown in Fig. 17.8 , many clock cycles worth of invalid address and/or data were captured following the burst of read transactions. By fifi lling up the ILA’s capture buffer with invalid data, subsequent bursts of valid data would be missed.

The following Boolean equation can be used as a capture setup condition (see Fig. 17.9 ) to only store only valid address and/or data

Using the same basic trigger setup as shown in Fig. 17.7 , the waveform in Fig. 17.10 shows how many more read transactions can be stored when only valid address and/or data cycles are captured.

ILA waveform showing only valid AXI address and or data cycles.png

Taking an Advanced Measurement Using the ILA Core

Sometimes it is necessary to take a more advanced measurement with an ILA core than the basic trigger settings used in the previous section, as shown in Fig. 17.7 . For instance, it is sometimes desirable to trigger when a particular AXI interface is idle for a certain number of clock cycles following a read transaction. This can be useful in detecting data transfer stalls or other throughput/ latency issues.

You can use the ILA core’s advanced trigger state machine feature to trigger on such an event, as shown in Fig. 17.11 . You can optionally enable the ILA advanced trigger state machine feature at compile time and then use at run-time by selecting the ADVANCED trigger mode in the ILA trigger setup dashboard window. The waveform in Fig. 17.12 depicts the trigger occurring 1024 clock cycles after the last assertion of the RLAST signal.

Using JTAG-to-AXI Master to Access AXI-Based Registers

The IP Integrator Block Design AXI Address Editor shown in Fig. 17.13 has two AXI masters that are capable of initiating AXI transactions: a MicroBlaze microprocessor ( microblaze_0 ) and a JTAG-to-AXI Master ( jtag_axi_0 ). The JTAG-to-AXI Master debug IP core provides a means to access any register or memory that is in the AXI address map of the design. The JTAG-to-AXI Master debug IP core can be very useful for inspecting AXI-based memory contents or checking AXI-based status registers.

Triggering 1024 clock cycles after last AXI read transaction.png

Interacting with the JTAG-to-AXI Master IP involves two steps:

1. Create a transaction using the create_hw_axi_txn command.

2. Run the transaction created in step 1 using the run_hw_axi command.

Below is an example for creating and running a read and a write transaction, both of which are 32-word bursts starting at address 0xC000_0000 (the axi_bram_ctrl_0 block RAM controller peripheral):

• Create and run a 32-word burst read transaction from address C000000 and confifi rm the data is all 0 ’s:

create_hw_axi_txn rd [get_hw_axis hw_axi_1] -type read -address C0000000 -len 32 run_hw_axi [get_hw_axi_txns rd]

Waveform showing trigger after 1024 idle cycles.png

Example design AXI address map.png

INFO: [Labtoolstcl 44-481] READ DATA is: 0000…

• Create and run a 32-word burst write transaction to address C0000000 that repeats the four-word pattern of 11111111, 22222222, 33333333, 44444444

create_hw_axi_txn wr [get_hw_axis hw_axi_1] -type write -address C0000000

-len 32 –data {44444444_33333333_22222222_11111111}

run_hw_axi [get_hw_axi_txns wr]

INFO: [Labtoolstcl 44-481] WRITE DATA is: 4444…

• Rerun the read transaction:

run_hw_axi [get_hw_axi_txns rd]

INFO: [Labtoolstcl 44-481] READ DATA is: 4444…

• Confi rm the data at address C0000000 is the same pattern that was previously

written:

report_hw_axi_txn [get_hw_axi_txns rd]

c0000000 11111111 22222222

c0000008 33333333 44444444

…

c0000078 33333333 44444444

This sequence of AXI read and write transactions confi rms the block RAM

controller peripheral is working as expected.

Using Virtual Input/Output to Debug Design in Hardware

The Virtual Input/Output ( VIO ) debug IP core is useful for representing status indicators and high-level controls such as LEDs and pushbuttons. You can use the VIO core in situations where the hardware is not physically accessible or there are not suffifi cient interactive controls on the hardware platform.

The example design in Fig. 17.3 shows how a VIO core can be used to monitor the inputs to and outputs from an AXI GPIO (General Purpose I/O) peripheral. The VIO dashboard in the Vivado tool can be used to show the value of the GPIO outputs (which are inputs to the VIO), as shown in Fig. 17.14

The JTAG-to-AXI Master IP can also be used to write a nonzero value to the GPIO outputs:

• Create a transaction to write 0x0000000F to the GPIO output register at address 0x40000008 : create_hw_axi_txn gpio_f [get_hw_axis hw_axi_1] -type write -address 40000008 -data {0000000F}

• Run the transaction: run_hw_axi [get_hw_axi_txn gpio_f]

Note that the value of the VIO inputs (GPIO outputs) changed from all zeroes to all ones, as shown in Fig. 17.15 ).

VIO dashboard showing inputs are all zeroes.png

VIO dashboard showing inputs are all ones.png

TABLE OF CONTENTS

Connecting to Hardware and Programming the Device

Using Virtual Input/Output to Debug Design in Hardware