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 153: SDSoC Performance & Tracing

Xilinx Employee
Xilinx Employee
0 0 43.3K


By Adam Taylor


Over the last few weeks and indeed last year, we have looked at the Xilinx SDSoC Development Environment in detail. However one area we have not examined are SDSoC’s performance monitoring and the trace capabilities.


Performance monitoring allows us to examine the performance of the processors executing applications within our system. We also can see the performance of the AXI interconnect used as part of the Zynq SoC’s PL acceleration in considerable detail. This feature allows us to understand the interaction between the PS and the PL. Tracing capability, which requires more detail, will be the focus of another blog.


We enable the AXI performance monitor using SDSoC’s Project overview. On the right-hand side under options, there is a tick box labeled Insert AXI Performance Monitoring. Checking this box and then cleaning the build, prior to a complete re-build of the project with the active configuration set to SDDebug, tells SDSoC to insert AXI performance-monitoring blocks into the design.






For this example, I will use one of the demo applications and target the ZedBoard. I am going to run the matrix multiplication example and target a bare-metal solution. We can monitor the AXI performance using both standalone code and Linux.


Once the application is built, we need to connect the ZedBoard to our development PC using both the UART and the JTAG connectors.


To run the examples on our target board, we will be using an approach that differs from what we have done before—i.e. we are not going to copy the generated files on to a SD Card. Instead we are going to use SDSoC’s Debugger. We will also be using two new perspectives within SDSoC: the debugger perspective (which should be familiar to those of us who have used Xilinx SDK previously), and the performance analysis perspective.


The first thing we need to do with the files we’ve generated is to create a debug configuration for the elf file. Within SDSoC, under project explorer, open the folder for the project we have just compiled, expand the SDDebug folder, and select the elf file for the project.







Right click on this selection and select Debug As -> Debug Configurations. Create a new Xilinx SDSoC Application as configured in the image below.






Selecting the Debug Configuration




On the application tab, check the stop program at entry operation. This will prevent the program from running the minute it is downloaded and will allow us to control the program when executed.






SDSoC Debug Configuration







Ensuring the program waits at entry



With this complete, click on debug. The bit file will be loaded and the application downloaded and held at the entry point, awaiting our command. You may see a dialog asking you to switch to the debug view, click yes and you will see that the application has been loaded and is paused.





Program downloaded and awaiting execution



If we want to execute the program, we can click the resume button (or hit F8) as shown above. However if we do that, we will not obtain the performance data. If we want the performance data, we need to open the performance analysis perspective by clicking on the open perspective button.





We can also select Window->Perspective-> Open Perspective-> Other







Selecting the Performance Analysis Perspective



This will open the performance analysis perspective. However, before we can obtain the performance analysis, we need to define the underlying hardware. This is very simple to do under the performance system manager. Just select run.





The Performance Session Manager settings



This will open a dialog box that allows us to define the clock rate and the APM (AXI Performance Monitor) information. This information resides in the following directory:










Defining the APM slots in the design



Once this is completed, we can run the program and capture the information of interest within in the performance graphs. These performance graphs relate to either the PS or the APM performance. I captured the following when I ran the program:







Result of the APM Performance Analysis Graph







Result from the APM Performance Analysis Counters




Performance analysis allows us to examine the performance of our system in more depth, which helps us better understand the interaction between the Zynq SoC’s PS and PL.




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)