Documentos de Académico
Documentos de Profesional
Documentos de Cultura
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:
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)
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))
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:
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:
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;
}
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:
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
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:
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.
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
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.
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.
Once this is done, re-export to SDK (this time include the bitstream)
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:
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:
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:
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:
Next, generate the Output Products, and generate the HDL wrapper.
There are two files attached to this tutorial, add these as simulation sources.
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:
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.