The packaging step is creating a zip version of the sd card image that can be used in any usual SD Card flash software like Balena Etcher.
When the application is run on hardware, using XRT on Linux, the trace is captured using the following xrt.ini file specification:
# Debug group for the aie, ps and pl
[Debug]
aie_profile = false
aie_trace = true
device_trace=fine
continuous_trace = true
host_trace=true
# PL Trace buffer
trace_buffer_size = 32M
trace_buffer_offload_interval_ms = 5
# Subsection for AIE profile settings only if aie_profile is set to true
[AIE_profile_settings]
# Interval in between reading counters (in us)
interval_us = 1000
tile_based_aie_metrics = all:heat_map
tile_based_aie_memory_metrics = all:conflicts
tile_based_interface_tile_metrics = all:output_throughputs
# Subsection for AIE Trace only if aie_trace is set to true
[AIE_trace_settings]
# PLIO
reuse_buffer = true
periodic_offload = true
buffer_offload_interval_us = 50
buffer_size = 100M
tile_based_aie_tile_metrics = all:functions
enable_system_timeline = true
[Runtime]
verbosity = 10
The option enable-system-timelineis true by default. More information can be found at xrt.ini file in UG1702.
Plug the sd card in your board, connect the right COM port and boot the board.
Login with username petalinux and set the password to whatever you want, let say p.
For the next steps you should be the superuser: sudo su and enter yout password.
Change root password: passwd root, let’s use r as the password.
As you will have to copy back the trace files you must allow connection with root through ethernet: vi /etc/ssh/sshd_config. Change the option of PermitRootLogin into yes.
Now, go to the application directory: cd /run/media/mmcblk0p1.
In order to allow multiple runs with different options you can use the script newdir which will copy the necessary files into directory ptest1, ptest2, and so on.
in ptest1, check the content of xrt.ini and embedded_exec.sh.
Run the application: ./embedded_exec.sh
All trace files should be generated in 2s. If you want to perform another test with other parameters, you can run ./newdir from /run/media/mmcblk0p1 and change the parameters as you wish in ptest2/xrt.ini. Type reboot to restart the board and re-run the application.
Once you have run the application with multiple sets of parameters, you can copy the various ptest directories back to your development machine using scp (use ifconfig to get the board inet address).
You can copy the whole ptest*directories to ProfileData on your development machine. The minimum set of files that you have to copy is: *.csv, *.txt, *.bin, *summary
Now you can run vitis_analyzeron your development machine with the summary file: vitis_analyzer xrt.run_summary. to view the System Timeline you have to allow it on the tool: In the top bar menu click on Vitis -> New Feature Preview, and check System Timeline.
Click on the analysis tab on the left of Vitis Analyzer, and click on Timeline Trace.
The overall view covers the complete simulation time:
At the begining we can see when the processing system is opening the device and starts the PL kernels:
Zooming in where the AI Engine graph starts, we can see the PL Kernels gen2s generating the data and the AI Engine kernels consuming these data. These trace are not perfectly aligned but still enough to understand the overall behaviour of the system.
The polling interval is crucial in event alignment. Reducing the polling interval can help to better align events in the timeline at the expense of some timestamp file size increase. In order to show the effect of different polling intervals, you can modify the buffer_offload_interval_us parameter in xrt.ini file. The default value is 50µs, In the following example I increased it to 100µs:
As you can see , the PL kernels are out of sync with the AI Engine array iterations.