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!

Showing results for 
Search instead for 
Did you mean: 

Adam Taylor’s MicroZed Chronicles, Part 154: SDSoC Tracing

Xilinx Employee
Xilinx Employee
0 0 43K


By Adam Taylor


Using the Xilinx SDSoC Development Environment allows us to create a complex system with functions in both the Zynq SoC’s PS and the PL (the Processor System and the Programmable Logic). We need to see the interaction between the PS and PL to achieve the best system performance and optimization. This is where tracing comes in. Unlike AXI profiling, which enables us to ensure we are using the AXI links between the PS and PL optimally, tracing shows you the detailed interaction taking place between the software and hardware acceleration. To do this SDSoC instruments the design and includes several additional blocks to trace events within the PL design, enabling tracing for the global solution.


We can enable tracing using the SDSoC Project overview: select the Enable Event Tracing check box and set the active build to SDDebug. We are then able to build our application with the trace functionality built in, which ensures that there are no issues. I recommend that you clean the build first (Project-> Clean).





Using SDSoC Project Overview to configure a build with built-in trace



For this blog post, I am going to target the Avnet ZedBoard with standalone OS and use a matrix multiplication example.


Once SDSoC has generated the build files, we need to execute and run the trace design from within SDSoC itself. We need to connect both the JTAG and UART to our development PC to run things from within the SDSoC environment. If we are using a Linux operating system, then we also need to connect the Ethernet port, to the same network connected to the development PC.


Power up the target board and then, within SDSoC project Explorer, expand your working project. Beneath the SDDebug folder, right click on the resultant ELF file, then select debug and Trace application.






Executing the trace application



This will then program the bit file into the target board, execute the instrumented design, capture the trace results, and upload them to SDSoC. If we have a terminal window connected to the target board to capture the UART’s output, we will see the results of the program being executed:






UART results of the program




The trace application executes within SDSoC and uploads a trace log and a graphical view of this log. This log shows the starting and stoping of the software, data transfers, and hardware acceleration:





SDSoC Trace Log






Results of tracing an example application

(Orange = Software, Green = Accelerated function and Blue = Transfer)




Running the trace creates a new project containing the trace details, which can be seen within the project explorer.





New Project containing trace data



Tracing instruments the PL side of the design so I ran the same build with and without tracing enabled to compare the differences in resource allocation. The results appear below:






Resource Utilization with Tracing enabled (left) and Normal Build (right)



There is a small difference between the two builds but implementing trace within the design does not significantly increase the resources required.


I also made a short video for this blog post. Here it is:







Code is available on Github as always.


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




All of Adam Taylor’s MicroZed Chronicles are cataloged here.





Tags (3)