Analysis of ADF Event API Profiling Flow vs. XRT-based Profiling Flow - Analysis of ADF Event API Profiling Flow vs. XRT-based Profiling Flow - 2025.1 English - UG1076

ADF Event API Profiling Flow

The ADF Event API flow requires modification of the host code as seen in the previous sections. You can instrument the host application at various points to collect specific metrics, compile the updated code, deploy the new executable to the board, and execute it on hardware. This approach allows you to enable or disable measurement collection dynamically using input parameters, providing flexibility to gather different metrics or run without measurement overhead as needed. When deployed, you simply execute the application with varying parameters to obtain the desired performance data.

XRT Profiling Flow

The XRT flow is managed through the xrt.ini configuration file, which specifies the metrics to be collected. Because xrt.ini is a plain text file, it can be edited easily with any text editor to enable or disable profiling and tracing features across different parts of the design. This method allows you to control profiling and tracing for the AI Engine array, PL kernels, and the host processor, with all results consolidated in the Vitis Analyzer interface.

Latency and Throughput Computation

The ADF Event API flow depends on the host clock and is subject to latency introduced by the operating system between reading performance counters and the actual read operation. This can lead to variability in results across runs, especially when cycle counts depend on host-side wait instructions, and the placement of API calls in the code significantly influences the measurements.

The XRT flow, on the other hand, focuses on the running and stalled states of the system, providing consistent system-level metrics, though it can include idle times in transfer periods and lacks the granular control of the ADF Event API.

Flexibility

The ADF Event API flow embeds all trace and profile parameters within the host code, allowing users to enable or disable tracing and profiling at runtime through parameters. It also supports customizable output formats and automated result storage, facilitating performance tracking and decision-making.

The XRT flow offers complete independence from the application code, managing profiling and tracing for the processing system (PS), programmable logic (PL), and AI Engine from a single configuration file. It supports all features available in the ADF Event API flow and additional capabilities, including compatibility with new XRT features like hardware context for multi-partition systems.

Limitations

Profiling using event::start_to_bytes_transferred

In the Event API flow, if more bytes pass through the port than specified, the counters reset and generate incorrect results. Also the number of bytes must be a multiple of 4 (32 bits).

Profiling using interface_tile_latency

In the hardware emulation flow, when the design uses the XRT profiling flow, the latency results are only accurate if data paths remain within the AI Engine array. If data traverses the PL or DDR, results can be inaccurate due to the lack of a cycle-accurate DDR model in the hardware emulation flow.

Recommended Use Cases

ADF Event API

Ideal for AI Engine kernel profiling and scenarios requiring custom output formats or immediate access to results after execution.

XRT Flow

Preferred for full-system (PS, PL, AI Engine) profiling and tracing, especially when centralized configuration and minimal code changes are desired.

Both flows have distinct advantages. Choose the flow based on your preferences (such as comfort with C++ and integrated tracing, or preference for decoupled code and debugging), and the specific profiling or tracing requirements of the project.