© Copyright 2015 Xilinx

Embedded Debugging Techniques

In this simple tutorial, we shall be exploring the various debugging techniques; such as behavioural

simulation and hardware debugging techniques such as the ILA and cross probing debugging

between the SDK and the Vivado. We shall also discuss how to use the AXI BFM to debug.

The intent of this tutorial is to allow for customer issues to be reproduced more quickly by Xilinx

WTS. This prevents wasted time on potential critical issues and decreases the SR time to close.

Firstly, lets build the example design that shall be used throughout this tutorial by following the

steps below:

Step 1: Generate the Hardware design.

Here, I have created a simple custom IP called “myip”, and added this to my Block Design (BD):

The TRACE bus is enabled on the Microblaze. This will be used to track the Instructions.

Note: For more information on the custom IP generation, see the Vivado Quick Take here.

Once the BD is created. Right Click and Generate Output Products, and the HDL wrapper.

Export to SDK (File -> Export Hardware, then File -> Launch SDK)

This will launch the SDK.

© Copyright 2015 Xilinx

Step 2: Generate Simple Application in SDK to test the custom IP

In the Hardware Platform exported from SDK, the driver will be added:

If we explore this, we shall see that in the myip.h there is a function called:

#define MYIP_mWriteReg(BaseAddress, RegOffset, Data) \ Xil_Out32((BaseAddress) + (RegOffset), (u32)(Data))

The registers offsets are also defined:

#define MYIP_S00_AXI_SLV_REG0_OFFSET 0 #define MYIP_S00_AXI_SLV_REG1_OFFSET 4 #define MYIP_S00_AXI_SLV_REG2_OFFSET 8 #define MYIP_S00_AXI_SLV_REG3_OFFSET 12

We can use this to create our simple application. So, in the SDK, select File -> New -> Application

Project. Name this test_myip and select the Create New Board Support Package:

Select Next to Continue.

© Copyright 2015 Xilinx

Select Empty Application and Finish to Continue:

This will create an empty application, and a BSP:

Now, we can add our own source code to the empty application. To do this, drop down the

test_myip and right click on the src folder and select New -> Source File:

© Copyright 2015 Xilinx

Create a new Source file called test.c:

This will create an empty source file called test.c in your application.

Next, copy the copy the code here into the test.c:

#include "myip.h" #include "xparameters.h" int main () {

MYIP_mWriteReg(XPAR_MYIP_0_S00_AXI_BASEADDR, MYIP_S00_AXI_SLV_REG0_OFFSET, 0x12345678);

return 0; }

To build, select Project -> Build All

Exit SDK and return to Vivado

© Copyright 2015 Xilinx

Debug Option: Behavioural Simulation

In Vivado, add the ELF created in SDK (this will be in the project_1.sdk/test_myip/Debug folder) as a

simulation source and Design Source:

Next, Associate the ELF (Tools -> Associate ELF):

There is a TCL utility that users can use to generate the testbench for a BD.

To use this utility, go to Tools -> Xilinx Tcl Store, and select Refresh.

Once, the refresh is done. Install Design Utilities 1.17 (or later)

Open your Block Design (BD), and run the Tcl command below to generate the testbench:

tclapp::xilinx::designutils::write_ip_integrator_testbench -addToProject

© Copyright 2015 Xilinx

To Simulate, select Run Simulation -> Run Behavioral Simulation.

Lets investigate the following:

1. Is the Application executing correctly?

2. Can I see the expected data on the myip interface?

The best way to evaluate if the processor is executing is to disassemble the ELF. To do this use the

mb-objdump utility. To do this, open a SDK bash from SDK:

And use the command below

In the Simulation, add the TRACE PC, Instruction, Valid Instruction, and the AXI interface signals for

myip:

Note: Here, I have crossed checked against what we see in simulation and the dissembled ELF. I have

concentrated on the main (). Here, you can see that the code is executing correctly and the data is

written correctly on the wdata on the interface.

Close the Behavioural Simulation

© Copyright 2015 Xilinx

Debug Option: SDK/Vivado Cross Simulation using automatic ILA insertion.

So, now let’s replicate this in a HW debug. To do this, return to the BD and highlight the net between

the AXI Interconnect and the myip:

Run Synthesis. Once this is complete, open the Synthesised Design setup the Debug

Open the Debug layout:

In the Debug Window, you will see a list of the unassigned Debug nets. These nets correspond to the

various signals that make up the interface connection that you marked for debug above.

© Copyright 2015 Xilinx

Use the Set up Debug wizard to add the ILA debug core to the design:

Note: Some of the nets clock domain will be undefined:

To address this, right click on the undefined and select Select Clock Domain and choose

design_1_i/clk_wiz_1/U0/clk_out1. Do this for all the undefined clock domains.

Select Next to continue. Keep all defaults (Users can increase the data depth if they wish, but not

needed here)

Save. This will create an XDC file that will add the ILA, the config options for this and add the nets

that we selected.

Next, Generate Bitstream

Once this is done, re-export to SDK (this time include the bitstream)

© Copyright 2015 Xilinx

Under Program and Debug, Hardware Manager -> Open Target -> New Hardware Target

Next, right click on the device and select Program Device:

© Copyright 2015 Xilinx

This BIT and LTX should be auto-populated:

Select Program

Here, we want to trigger on a write (as this is what we are doing in our app). To we want to triiger on

a valid write to address 0. To set this up, add the AWADDR and AWVALID to the trigger setup:

So, we want to catch valid accesses to address 0. So, set the compare values as follows:

Once we are happy with the set-up, select the Run Trigger:

© Copyright 2015 Xilinx

This will sit and wait until it detects the trigger condition.

Next, return to SDK and debug the application

To debug, right click on the application and select Debug As -> Debug Configurations.

Double Click on Xilinx C/C++ application (System Debugger), and select Debug to continue:

Now, check the Vivado Hardware manager to see if the trigger was met (it should be). Re-run Trigger

again. Then single step in the SDK to step over the MYIP_mWriteReg function and review the

Vivado. Now we should see the data on the WDATA:

Test custom IP using AXI BFM.

© Copyright 2015 Xilinx

Debug Option: AXI BFM Simulation

Another quick, and powerfull way to test the custom IP is to use the AXI BFM. When users create an

IP via the Packager, there is an option to include a BFM project in the last window:

This can be used as a reference as this will create a testbench. Firstly, lets create a simple BD, with

an AXI4-Lite BFM Master connected to our Custom IP:

© Copyright 2015 Xilinx

Note: Configure the AXI BFM protocol as Master, with an AXI4-Lite interface:

To add the Clock Port, right click on the IPI canvas and select Create Port and set up as shown below:

To add the Reset Port, right click on the IPI canvas and select Create Port and set up as shown below:

© Copyright 2015 Xilinx

Connect all ports, and generate the address map:

Next, generate the Output Products, and generate the HDL wrapper.

There are two files attached to this tutorial, add these as simulation sources.

Here, there is a myip_v1_0_tb.v and a myip_v1_0_include.vh files. Open the myip_v1_0_include.vh

file and make sure that the values are set correctly:

For example, here since my BD is called design_1, the BD_INST_NAME will be design_1_i, and the

BD_WRAPPER will be design_1_wrapper. Also, make sure that the address matches what was set in

the Address Editor above:

© Copyright 2015 Xilinx

Open the myip_v1_0_tb.v. Here, we are setting up a WRITE_BURST_CONCURRENT, and a

READ_BURST transaction using the BFM API. For more information on these, see the link here. In

particular (table 3 – 15):

© Copyright 2015 Xilinx

Next, run the simulation, and in the XSIM, add the signals below and run for 1.5 us.

Here, we can see the burst write (0x101ffff, 0xabcd0001, 0xdead001, 0xbeef001) on the

S00_AXI_test_data_lite signal. This is received on the S00_AXI_rd_data_lite signal. We can also see

this on the myip itself on the AXI interface, and at the bottom we can see the actual register at offset

0x0:

In Summary, users should pick a debug option that best suits their problem. For example, if the issue

is in relation to an AXI interface on a custom IP, then the AXI BFM, or if the issue is related to a

system issue then would be the best way to debug is to use the behavioural simulation first, then

explore the hardware debug later. If the issue is more related to a hardware issue, then the cross

debug flow can be used.