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 Taylors MicroZed Chronicles, Part 202: AXI Performance Monitoring for the Zynq SoC and Zynq MPSoC

Xilinx Employee
Xilinx Employee
0 0 40.7K


By Adam Taylor



Having looked previously at the profiling we can perform on the Zynq SoC’s and Zynq UltraScale+ MPSoC’s PS (processing system) cores, the next step is to examine the performance of the AXI links between the Zynq SoC’s PS and the PL (programmable logic) . We can use a similar approach for both Zynq SoC and Zynq MPSoC devices, so this blog covers both devices.


We’ll use the AXI Performance Monitor (APM) IP block to monitor the performance between the Zynq PS and the PL. These blocks are instantiated within the programmable logic design and monitor selected AXI links. When we insert these APM blocks into the PL, we must ensure they have at least eight counters and are set for the advanced mode.





Configuring the APM for insertion into the PL



In the example used below for the Zynq SoC, I have added a BRAM memory connected to the PS using the PS Master AXI interface and an AXI BRAM controller. I have connected the APM monitor port (called a slot) on the AXI interface between the between the AXI Interconnect and the AXI BRAM controller. This enables us to monitor the read and write throughput and latencies when our software application accesses the memory.





Zynq APM Design Example



For the Zynq UlraScale+ MPSoC design, I followed a similar approach. However, I connected a second BRAM and AXI BRAM controller to the PS. This enabled me to monitor the low-power AXI interface and the full-power AXI master interfaces between the PS and PL.





Zynq MPSoC Design Example



I also added in a second APM to monitor the second AXI BRAM interface. However, when it comes to the Zynq MPSoC, these are not the only APM blocks present within the design. Several additional APMs exist within the PS subsystem itself and we can also monitor these within XSDK just as we do the ones within the PL.


These additional APMS are located in the following channels:

  • On-Chip Memory to the On-Chip Memory Switch
  • Cache Coherent Interconnect to the Core Switch
  • Low Power Domain Switch to the Full Power Domain Switch (CCI)
  • All Ports on the DDR SDRAM Controller






PS Subsystem Showing the APM locations in the Zynq MPSoC




This ability also provides a wider range of information on our Zynq MPSoC system and can be used for more advanced safety and security applications.


Just as we did with the PS Core, performance monitoring provides both a graphical and a summary table of the latency and data transfers. Running the performance analysis on the AXI interfaces resembles what we did previously. However, before we run it we need to configure the APM blocks.


We do this by right-clicking on the “performance analysis on local” to enable the APM (PS Master) and click on the edit button. This will open a second dialog that allows us to configure the PSU APMs and the inserted PL APMs.







Configuring the APMs within the design (Example Shown Zynq MPSoC)




Once the APM is configured we can run the code on the Zynq SoC or Zynq UltraScale+ MPSoC and obtain the results.


Running the code on the Zynq MPSoC APU to transfer data to and from the BRAMs using first the LPD AXI interface and then the FPD interface provides the results as shown in the tables below.





APM Results accessing BRAM via the LPD AXI Interface






APM Results accessing BRAM via the FPD AXI Interface



You can also see in this example that PSU APM slots are being reported. (Slot 0 = DDRC, Slot 1 = CCI, Slot 2 = OCM and Slot 5 = LPD). AXI Performance Monitor slot 0 is the LPD AXI interface to PL and Slot 1 is the FPD AXI interface to PL.



We know understand a little bit more about how we can profile our system, so we can optimize our design if necessary to give us the best results. What we need to look at over future blogs is how we can optimize the overall design.




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