See Vitis™ Development Environment on xilinx.comSee Vitis™ AI Development Environment on xilinx.com |
Version: Vitis 2024.1
AI Engine and HLS Implementation Comparison
Versal™ adaptive SoCs combine programmable logic (PL), processing system (PS), and AI Engines with leading-edge memory and interfacing technologies to deliver powerful heterogeneous acceleration for any application. The hardware and software are targeted for programming and optimization by data scientists and software and hardware developers. A host of tools, software, libraries, IP, middleware, and frameworks enable Versal adaptive SoCs to support all industry-standard design flows.
This tutorial performs two implementations of a system-level design: one with an AI Engine and the other with HLS using the DSP Engines. In each implementation, the tutorial takes you through the hardware emulation and hardware flow in the context of a complete Versal adaptive SoC system design.
A Makefile is provided for each implementation. It can be used to create the design for cint16 and acfloat datatypes for various point sizes (32 x 64, 64 x 128, 128 x 256, 256 x 512, and 1024 x 2048), different numbers of fft_2d HLS kernel/AI Engine graph instances (1, 5, and 10), and lastly for different targets (hw_emu and hw).
The design documentation demonstrates hardware and software design details, including the methodology for each implementation, elaborating on the functional partitioning. The compilation, execution, measurement steps, and observations are given.
Objectives
After completing the tutorial, you should be able to:
- Develop a system-level 2D-FFT design by identifying and deploying an algorithm on AI Engines or PL and DSP Engines using AMD Vitis™ HLS.
- Build a complete system design by going through the following steps in the Vitis flow:
- Create the AI Engine Adaptive Data Flow API (ADF) graph.
- Compile the A72 host application and PL kernels.
- Use the Vitis compiler (V++) to link the AI Engine and HLS kernels with the platform.
- Package the design.
- Run the design through the hardware emulation and flow in a mixed SystemC/RTL cycle-accurate/QEMU-based simulator.
- Develop a consistent harness to have the data mover kernels maintain a similar interface with AI Engine or HLS/PL kernels (using AXI4-Stream).
- Understand graph control APIs for AI Engine implementation and HLS APIs for controlling HLS/PL kernels.
- Understand the methodological differences between a design created using AI Engines and one created using PL and DSP Engines via HLS.
- Understand metrics, including utilization, performance/throughput, and power across various instances of FFT arrays of different dimensions.
Design Overview
This design aims to implement a 2D-FFT algorithm performed on (for example) a 1024 x 2048 matrix using 1024- and 2048-point 1D-FFT kernels. The pseudo-code to implement the algorithm is shown in the following example:
x = rand(a,b); % Create matrix of dimensions m x n
x_2fft = fft2(x); % Reference generation, 2 dimensional FFT of matrix 'x'
FFT2D, using 1D – FFT.
x_row = fft(x); % Row wise 1D-FFT
x_row = x_row.’; % Transpose
x_col = fft(x_row); % Row wise 1D-FFT
x_col = x_col.’; % Transpose
x_2fft - x_col % Calculate the error difference
In calculating each 1D-FFT, one dimension is kept constant while the other is computed. The transpose function is applied after each 1D-FFT compute. The transpose function moves the entry along each element of the dimension to the corresponding element of the other dimension. A golden data set is generated as a reference, and the error difference is calculated.
A similar algorithm is deployed in the two implementations using either the AI Engines or HLS targeting the PL and DSP Engines. The design compiles through the Vitis compiler, creates a PetaLinux-based platform using a script, and generates the PDI and host application. Instead of the transpose part, however, a PL-based data generator and checker (referred to as a data mover) is used to give an impulse (value = 1 or 1.5, depending on the cint16 or cfloat datatype) input to the row-wise 1D-FFT and check its output against the expected FFT output for the same (the first row containing all 1s and remaining 0s).
The transposed pattern generated within the PL is streamed as input to the col-wise 1D-FFT. Its output is checked against the expected output (all 1s). The data mover kernel returns the total error count in both stages to the host application, which is used to declare a pass or fail of the test case.
To help you compare the methodology of the AI Engine and HLS-based implementations, the design-build process can be modified to analyze how each implementation scales with different numbers of instances (x1, x5, and x10) of various matrix array dimensions (rows x cols = 32 x 64, 64 x 128, 128 x 256, 256 x 512, and 1024 x 2048).
A similar set of harnesses is developed and maintained between the two implementations. This allows you to generate and check input/output vectors using the PL-based data mover kernels and moving data to and from the AI and HLS kernels. In both cases, Xilinx Runtime (XRT) running on A72 controls data flow in compute, and data mover kernels through graph control APIs. These graph control APIs control the AI Engine kernels and HLS APIs, which control the HLS/PL kernels.
Directory Structure
fft2d_AIEvsHLS
|__AIE......................contains AI Engine implementation
| |Makefile....................with recipes for each step of the design compilation
| |images......................contains images used for AI Engine Design documentation
| |description.json............required for internal regression
| |multi_params.json...........required for internal regression
| |sample_env_setup.sh.........required to setup Vitis environment variables and Libraries
| |build.......................created and contains subfolders from design build
| |design......................contains source and include files
| | |aie_src....................contains all the aie source files
| | |pl_src.....................contains all the data mover source files
| | |host_app_src...............contains host application source files
| | |system_configs.............contains all system configuration files
| | |profiling_configs..........contains xrt.ini file
| | |hw_emu_files...............contains hw_emu launch script
|__HLS......................contains HLS implementation targeting PL and DSP Engines
| |Makefile....................with recipes for each step of the design compilation
| |images......................contains images used for DSP Design documentation
| |description.json............required for internal regression
| |multi_params.json...........required for internal regression
| |sample_env_setup.sh.........required to setup Vitis environment variables and Libraries
| |build.......................created and contains subfolders from design build
| |design......................contains source and include files
| | |pl_src.....................contains all the fft_2d and data mover source files
| | |host_app_src...............contains host application source files
| | |system_configs.............contains all system configuration files
| | |profiling_configs..........contains xrt.ini file
| | |directives.................contains directives for various vitis compilation stages like hls.pre_tcl etc.
| | |hw_emu_files...............contains hw_emu launch script
Documentation: Explore AI Engine Architecture
Installing the Tools
To build and run the 2D-FFT tutorial (AI Engine and HLS implementations), perform the following steps:
-
Install the Vitis Software Platform.
-
Obtain licenses for AI Engine tools.
-
Download the [DSP Library] (https://github.com/Xilinx/Vitis_Libraries/tree/master/dsp)
Platform
Before beginning the tutorial, make sure you have read and followed the Vitis Software Platform Release Notes for setting up software.
This tutorial targets the VCK190 production board. If you have already purchased this board, download the necessary files by following installation steps and ensure you have the correct licenses installed. If you do not have a board and the required license, contact your AMD sales contact.
Setting Up the Environment
When the Vitis software platform elements are installed, update the shell environment script. Set the environment variables to your system-specific paths.
To set up XRT, if you have not done this already, run the following command:
* source \<XRT-Location\>/setup.sh
In the design directory of each implementation, edit env_setup.sh script with your file paths and source the environment script:
source env_setup.shThe script sets up the environment variables and sources scripts explained below:
- The
PLATFORM_REPO_PATHSenvironment variable is based on where you downloaded the platform. - The
XILINX_TOOLS_LOCATIONpath to the Xilinx tools is used to source thesettings64.shscript. - The
XLNX_VERSALpath to thexilinx-versal-common-v2024.1directory is used in the step below. - The platform is set up by running the
xilinx-versal-common-v2024.1/environment-setup-cortexa72-cortexa53-xilinx-linuxscript as provided in the platform download. This script sets up theSDKTARGETSYSROOTandCXXvariables. If the script is not present, you must run thexilinx-versal-common-v2024.1/sdk.shscript. DSPLIB_ROOTis the path to the downloaded Vitis DSP Libraries. This is only required for the AI Engine implementation.- In the script, you can optionally set up an
XRT_ROOTenvironment variable, pointing to XRT - RPMs, which can be packaged in the Vitis compiler packaging step. If not set up, this environment variable is automatically excluded from packaging. - The script also sets up the
PLATFORMvariable pointing to the required.xpfmfile of the target platform set by the variabletgt_plat.
Confirming Tool Installation
To confirm that you have installed the correct tools, run the following command:
which vitis
which aiecompilerTo confirm you have the VCK190 base platform, run the following command:
platforminfo --list | grep -m 1 -A 9 vck190The output of the above command should be as follows:
"baseName": "xilinx_vck190_base_202410_1",
"version": "1.0",
"type": "sdsoc",
"dataCenter": "false",
"embedded": "true",
"externalHost": "false",
"serverManaged": "false",
"platformState": "pre_synth",
"usesPR": "false",The Makefile and source files for the AI Engine and HLS implementations are in the AIE and DSP directories, respectively. For the documentation of the flow to build the design and details of the hardware and software design, follow each of the links as follows:
The following table compares a 1024 x 2048 point 10-instance FFT-2D design implemented using the AI Engines and HLS with DSP Engines respectively. It lists the throughput, resource utilization, power consumption, and performance in throughput/Watt for cint16 implementations.
| Design Target | Aggregate Throughput (in MSPS) |
Average Latency (in μs) | AIE Vector Cores | AIE Vector Load | Active Mem Banks / Mem R/W Rate |
Active AIE Tiles | FF (Regs) / CLB LUTs |
BRAMs | DSPs | Dynamic Power (in W) |
Performance per Watt (in MSPS/Watt) |
|---|---|---|---|---|---|---|---|---|---|---|---|
| AIE | 6229.350 | 3537.296 | 20 | 78.62% | 420 / 46.92% |
60 | 11360 / 3647 |
0 | 0 | 5.547 | 1123.012 |
| HLS | 6277.483 | 4211.296 | NA | NA | NA | NA | 88447 / 56429 |
250 | 180 | 6.819 | 920.587051 |
These observations give a clear indication of where the AI Engines in Versal can offer improvements:
- Reduced latency by ~19.054%.
- Moving to AI Engine implementation reduces the PL and DSP resources considerably; 180 DSPs, ~88K FFs, ~56K LUTs, and 250 BRAMs are reduced to 72 AI Engines, 11k FFs, and 3K LUTs.
It is important to understand that those 72 AI Engines are not all required for the 2D-FFT compute: 20 AI Engines/vector cores are required for computation, and 52 AI Engines are required for the memory to store the FFT twiddle factors and also to enable connectivity around the array. The average load on these additional 52 AI Engine tiles is only 79%. This means that if your application needs it, these AI Engines can be shared with other functions to run sequentially, or they can use user constraints to better map and route this function to a reduced number of AI Engine tiles (see this page for details on the AI Engine mapper/router).
Additionally, increasing the number of instances in the AI Engine design is easier than the HLS design, which runs into timing closure issues, especially for higher FFT point size designs.
Measurement:
- AI Engine design resource utilization is measured using Xilinx Power Estimator (XPE) and AMD Vivado™ (report utilization under implementation for FFs and CLB LUTs). For the HLS design, resource utilization is measured using Vivado.
- AI Engine power consumption is measured using XPE. HLS power consumption is measured using Vivado (report power under implementation).
- Throughput is measured using viewing runtime profiling generated trace texts in
vitis_analyzer.
For detailed instructions on taking measurements of the parameters, refer to the individual implementation section.
Contains sections on how to develop AI Engine graphs, how to use the AI Engine compiler, AI Engine simulation, and performance analysis.
Below are links to the XRT information used by this tutorial:
-
XRT Documentation: Explains general XRT API calls used in the PS Host Application.
-
XRT Github Repo: Contains the XRT source code.
-
XRT AIE API: Documents the AI Engine XRT API calls
Vitis Unified Software Development Platform Documentation (https://docs.amd.com/v/u/en-US/ug1416-vitis-documentation)
Below are links to Vitis related information referenced in this tutorial:
The timestamps represented in the hardware execution generated trace have known an issue due to which they are scaled compared to the actual. This issue will be fixed in the subsequent tool versions. All calculations/observations in this tutorial are based on the hw_emu runs.
GitHub issues will be used for tracking requests and bugs. For questions, go to forums.xilinx.com.
Copyright © 2020–2024 Advanced Micro Devices, Inc