By Adam Taylor

Over the last two instalments of this blog series, we have explored Micrium’s μC/Probe and using it’s virtual dashboard and oscilloscope capabilities to debug code on the Zynq SoC’s PS. (See Post 1 and Post 2.) Then, I started thinking about how we might use μC/Probe to debug hardware in the Zynq SoC’s PL. The most obvious choice is to insert an integrated logic analyzer (ILA) IP core into the hardware design to observe AXI, AXI Stream, or native logic signals as we have done several times in the MicroZed Chronicles series. Similarly, if we wish to change a signal’s value at run time, we can use the virtual input output IP core to toggle the state of a signal or bus. Reading or modifying the contents of an AXI device within the PL will be a little more complicated, but it can be done by using the JTAG-to-AXI Bridge to connect into the AXI network and then reading or writing to any peripheral on the bus using Vivado’s hardware manager and a TCL script.

To debug designs that contain embedded processing, we could of course write a simple software application for the processor that reads and writes registers in the PL. However this is not always possible, especially if there are separate hardware- and software-development teams. FPGA development teams are sometimes unused to developing embedded software so it can be quicker and easier to use the JTAG-to-AXI bridge for testing out basic hardware functionality before passing the design over to the software development team.

There is also another very important use case for the JTAG-to-AXI bridge if the design does not contain an embedded processing core. (For example, it’s not a Zynq SoC that you’re debugging and you haven’t instantiated a MicroBlaze processor in your FPGA.) AXI is often used to configure and connect IP blocks available via the Vivado IP library. Even if you don’t have an embedded processor available, the JTAG-to-AXI bridge enables fast hardware-in-the-loop testing to ensure that the block performs as intended.

Inserting the JTAG-to-AXI Bridge

Regardless of the presence or absence of an embedded processing element, we can use the JTAG to AXI Bridge for:

Hardware-in-the-loop validation of IP blocks with the JTAG-to-AXI bridge acting as a traffic generator.

During initial board commissioning, we can create TCL scripts to test hardware interfaces, which frees us from depending on software development for hardware debugging.

For more formal validation, we can use the JTAG-to-AXI bridge to extract information from memories, making that information available for later analysis.

Including the JTAG-to-AXI core in the design is simple and requires only connections to the AXI network, clock, and reset. When it comes to IP configuration, all we need to do is define the preferred variety of AXI: AXI4 or AXI Lite. In the JTAG-to-AXI bridge configuration dialog, we can also define the read and write queue lengths. These define the number of TCL commands that the bridge can queue. I have defined the maximum queue length of 16 commands in this example because this will simplify the script I need to write.

Customizing the JTAG-to-AXI Bridge

For the example in this blog post, I have implemented a Zynq-based design with the PS connected via an AXI interconnect to an AXI QSPI module, which I’ve configured as a standard SPI master. To enable the JTAG-to-AXI bridge to also be able to access the AXI QSPI module, I added a second slave port to the AXI interconnect, and then connected the JTAG-to-AXI bridge.

Once this is complete we can use the address editor within Vivado, which will clearly show the peripherals that can be addressed by the Zynq SoC’s PS and which peripherals the JTAG-to-AXI bridge can address. In this case, both the PS and JTAG-to-AXI bridge can address the QSPI device on the AXI bus:

Addressable AXI Memory Peripherals for both the PS and JTAG to AXI Bridge

When we use the JTAG-to-AXI bridge, we must also pay attention to our clocking and reset architecture. If we plan to configure the PS before we use the bridge, the PS-provided fabric clocks and resets are suitable. However, if we intend to use the bridge before we configure the PS side of the Zynq SoC, we will need to source a clock from within the PL and ensure that the PS does not provide the AXI network reset. Failure to do this will result in the Vivado hardware manager not being able to detect the JTAG-to-AXI bridge until the PS has been configured.

Vivado will report the error as:

ERROR: [Xicom 50-38] xicom: AXI TRANSACTION TIMED OUT.

We use the hardware manager in Vivado to communicate with the AXI network over JTAG by issuing commands through the TCL window. The commands are defined within PG174: JTAG to AXI Master v1.2 LogiCORE IP Product Guide.

There are two basic commands: create_hw_axi_txn and run_hw_axi. We use the first command to create a number of AXI transactions, both read and write. We use the second command to execute the transactions, performing the reads and writes as necessary:

TCL Script used to configure and write out using SPI

To demonstrate the power of the JTAG-to-AXI bridge, I created a simple script that configures the QSPI as a master and transmits several words. The scripting commands allow us to assign a name to each transaction that we define. We can then call these named transactions multiple times as needed within the script. This is a very nice feature. In the image of the script above, these names are identified by the names wr_txn_liteX. These named transactions are then called in a different order when executed in the hardware. For example, I did this to first fill up the QSPI TX FIFO before I enabled Master transmissions.

I ran this example on a Digilent Arty Z7 connected to a Digilent Digital Discovery logic analyzer and pattern generator to monitor the SPI transactions. Here’s what I saw in the Digital Discovery’s Waveforms user interface:

Captured SPI waveform generated by the JTAG-to-AXI Bridge

This example demonstrates the ease with which we can implement the JTAG-to-AXI bridge and with which we can create scripts to interact with the AXI networks within the PL of the design. Hopefully these hints will allow you to debug and verify your design with greater ease.

You can find the example source code on GitHub.

Adam Taylor’s Web site is http://adiuvoengineering.com/.

If you want E book or hardback versions of previous MicroZed chronicle blogs, you can get them below.

First Year E Book here

First Year Hardback here.

Second Year E Book here

Second Year Hardback here