To obtain trace data during hardware run, there must be routes dedicated to
driving trace data from the AI Engine array to the PL or to the DDR. For this reason, during
the graph compilation phase, you need to specify the trace data during hardware run and
the interface to be used. See the code below for
details.
v++ --c --mode aie --verbose --pl-freq=100 --workdir=./myWork \
--event-trace-port=gmio --event-trace=runtime \
--num-trace-streams=8 --xlopt=0 --include="./" \
--include="./src" --include="./src/kernels" --include="./data" \
./src/graph.cpp- For
--event-trace=runtime: the only possibility here is runtime, indicating that signal selection will be decided at runtime. - For
--event-trace-port=plio/gmio: selects GMIO and the NoC pathway instead of PLIO/PL pathway. PLIO uses PL logic, which can be difficult and may induce timing closure difficulties. - For
--num-trace-streams=8: up to 16 streams can be used within the AIE Engine array to drive the trace events to the GMIO/PLIO.
For the profiling flow, you can perform event trace either using XSDB or XRT
flow. There are three types of traces that you can capture, each capturing a different
set of events as specified in the following table.
| Event Type |
functions
|
partial_stalls
|
all_stalls
|
|---|---|---|---|
| Functions Calls/Returns | Captured | Captured | Captured |
| Stream Stalls | NA | Captured | Captured |
| Cascade Stalls | NA | Captured | Captured |
| Lock Stalls | NA | Captured | Captured |
| Memory Stalls | NA | NA | Captured |
- Functions Calls/Returns
- Event generated when kernel functions are being invoked and returned.
- Stream Stalls
- Event generated when core gets stalled. This can be due to either NO data at Input or backpressure on the stream output from the core.
- Cascade Stalls
- Event generated when core gets stalled. This can be due to either NO data at cascade stream Input or due to backpressure on the cascade stream output from the core.
- Lock Stalls
- Event generated when the core gets stalled due to the lock already being acquired.
- Memory Stalls
- Event generated when core gets stalled due to a memory conflict.
XSDB Flow
When running the application, the trace data is stored in DDR memory
by the debugging and profiling IP. To capture and evaluate this data, you must
connect to the hardware device using
xsdb. This
command is typically used to program the device and debug bare-metal applications.
Connect your system to the hardware platform or device over JTAG, launch the xsdb command in a command shell, and run the following
sequence of
commands:xsdb% connect
xsdb% ta
xsdb% ta 1
xsdb% source $::env(XILINX_VITIS)/scripts/vitis/util/aie_trace.tcl​
xsdb% aietrace start -graphs mygraph -work-dir ./Work -link-summary $PROJECT/xsa.link_summary -base-address 0x900000000 -depth 0x800000 -tile-based-aie-tile-metrics "all:functions; {4,1}:{6,2}:all_stalls"
# Execute the PS host application (.elf) on Linux
## After the application completes processing.
xsdb% aietrace stopwhere, the source
$::env(XILINX_VITIS)/scripts/vitis/util/aie_trace.tcl command sources
the Tcl trace command to set up the xsdb environment.
After the hardware events have been captured on the SDCard, you offload them
on your computer and you launch the Vitis Unified
IDE to import and analyze
data:
vitis -a aie_trace_profile.run_summaryXRT Flow
Within the XRT flow, the selection of trace events is performed in
the
xrt.ini file in the SDCard. An example of such
an xrt.ini file is shown
hereafter:# Main switch to turn on aie trace
[Debug]
aie_trace = true
# Continuous trace knobs
[AIE_trace_settings]
reuse_buffer = true
periodic_offload = true
# Time to wait between trace reads
buffer_offload_interval_us = 100
# Total amount of device memory shared between trace streams
buffer_size = 16M
# granularity
graph_based_aie_tile_metrics = all:all:functionsFor more details, see the chapters on Event Tracing in Hardware and XRT Flow in the AI Engine Tools and Flows User Guide (UG1076).