UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Adam Taylor’s MicroZed Chronicles, Part 226: Debugging FPGA hardware with the JTAG-to-AXI Bridge

by Xilinx Employee ‎11-27-2017 11:22 AM - edited ‎11-27-2017 11:27 AM (7,227 Views)

 

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.

 

 

Image1.jpg

 

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.

 

 

 

Image2.jpg

 

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:

 

 

Image3.jpg

 

 

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:

 

 

 

Image4.jpg

 

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:

 

 

 

Image6.jpg 

 

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.

 

 

  

MicroZed Chronicles hardcopy.jpg 

 

 

 

Second Year E Book here

 

Second Year Hardback here

 

 

MicroZed Chronicles Second Year.jpg 

 

 

Comments
by Scholar ronnywebers
on ‎11-27-2017 11:48 PM

Thanks Adam, really interesting tutorial, didn't use this IP so far. 

 

I can see why you used the external sysclk.

 

Q1) Suppose I would like to leave the JTAG to AXI master in this design during the entire development cycle (and even in the field, use it with remote debug)

 

That might put a speed penalty on the communication between Zynq and the AXI Quad SPI (let's say sysclk = 100MHz, and my FCLK0 would be 200MHz). Would it be possible somehow to 'combine both clocks'? For example have the AXI interconnect clocked by FCLK0, and then do some clock domain crossing between the JTAG to AXI master and the AXI interconnect? 

 

Q2) side question : do you know of a tutorial on remote debugging? I assume this JTAG to AXI master can be combined with the VIO and ILA, to do some serious remote debug?

 

 

by Observer taylo_ap
on ‎11-28-2017 01:40 PM

Hi Ronnie

 

Thanks for the very interesting questions

 

1) Leaving the JTAG in the design should not cause an issue however, please ensure it does not introduce a security weakness or attack vector into your application JTAG ports should protected and treated with care and I am not aware what your end application is. With respect to clocking the PL input sys clock (via a clock wizard if necessary) can be set to the same frequency as the PS Fabric clocks however, if you really wanted to switch between them it would be possible to use the BUFGCNTRL as a mux I think. you can check out the 7 series clocking guide for more details

 

2) There are a couple of links, below I will also try at some point to create a blog on remote debugging.

https://www.xilinx.com/video/hardware/debugging-remotely-using-vivado.html

https://www.xilinx.com/support/documentation/sw_manuals/xilinx14_6/SDK_Doc/tasks/sdk_t_tcf_remote_debug.htm

 

Thanks 

 

Adam 

Labels
About the Author
  • Be sure to join the Xilinx LinkedIn group to get an update for every new Xcell Daily post! ******************** Steve Leibson is the Director of Strategic Marketing and Business Planning at Xilinx. He started as a system design engineer at HP in the early days of desktop computing, then switched to EDA at Cadnetix, and subsequently became a technical editor for EDN Magazine. He's served as Editor in Chief of EDN Magazine, Embedded Developers Journal, and Microprocessor Report. He has extensive experience in computing, microprocessors, microcontrollers, embedded systems design, design IP, EDA, and programmable logic.