Version: Vitis 2023.2
Introduction
The AMD Versal™ adaptive SoC is a fully software programmable, heterogeneous compute platform that combines the processor system (PS) (Scalar Engines that include the Arm® processors), programmable logic (PL) (Adaptable Engines that include the programmable logic blocks and memory), and the Intelligent Engines comprising of both the AI and DSP Engines.
This tutorial is one of the several to perform two implementations of a system-level design using AI Engines and HLS with DSP Engines in the Versal device plus PL including LUTs, flip-flops (FFs), and block RAMs. In each implementation, the tutorial takes you through hardware emulation and hardware flow in the context of a complete Versal ACAP system design. A Makefile is provided with each tutorial for additional customisation.
An important goal and criteria of this tutorial is the use of C++ based kernels for AI Engine and HLS library kernels for DSP Engine and data movers. The use of AMD Vitis™ application acceleration development flow and library kernels is illustrated throughout the tutorial to demonstrate the ease of kernel integration and scalability in a system design. In the Vitis application acceleration development flow, the Vitis HLS tool automates much of the code modifications required to implement and optimize the C/C++ code in PL, including the ease of data mover kernel coding. The inference of required pragmas to produce the right interface for user’s function arguments and to pipeline loops and functions is the foundation of the Vitis HLS in the application acceleration flow. Vitis HLS also supports customization of your code to implement different interface standards or specific optimizations to achieve design objectives, enable scaling, and leverage automation.Note: Alternative design methods to Vitis HLS may increase PL based performance. For example, using LogiCORE™ FIR Compiler IP and RTL based data movers could increase raw performance but will increase dynamic power and design time.
A frequently asked question is whether using AI Engines, HLS or RTL targeting DSPs produces the better implementation. The answer depends on the design objectives, complexity, and characteristics of every individual design. A section in this tutorial is provided which discusses the trade-offs and provides guidance in helping to determine the best choice for your design.In addition another section discusses AI Engine specific design considerations because AI Engines are a relatively new technology compared to the mature FPGA fabric or PL with DSPs.
Objectives
Objectives
After completing the tutorial, you should be able to:
Develop a system level design (FIR filter in this case) by identifying the algorithm and deploying the same algorithm on AI Engine and DSP Engines using Vitis HLS.
Build a complete system design by going through the various steps in the Vitis unified software platform flow, including creating the AI Engine adaptive data flow (ADF) API graph, compiling the A72 host application, and compiling PL kernels, using the Vitis compiler (
v++
) to link the AI Engine and HLS kernels with the platform, and packaging the design. You will also be able to run the design through the hardware emulation and hardware flow in a mixed System C/RTL cycle-accurate/QEMU-based simulatorDevelop a consistent harness to have the data mover kernels maintain a similar interface with AI Engine/HLS kernels (with AXI4-stream) and DDR memory (memory-mapped AXI4)
Develop an understanding of graph control APIs to enable run-time updates using the run-time parameter (RTP) interface for the AI Engine implementation and HLS APIs for controlling HLS/PL kernels
Develop an understanding of the various factors that influence the performance, resources, latency, and power of AI Engine and HLS using DSP implementations, so that an informed choice can be made between the two implementations.
Overview
Overview
This tutorial implements a FIR filter chain, one implementation targeted at AI Engines and another targeted at DSP Engines using Vitis HLS.
FIR filters provide a large design space to explore. For the purposes of this tutorial, the following parameters are held fixed/constant:
Data Type: cint16
Coefficient type: int16
Symmetric FIR
Fixed (that is, non-reloadable) coefficients
The number of filter taps in the filters and the number of cascaded filters in the chain can be specified as parameters in the build process. Each filter in the chain consists of an identical number of taps with identical coefficients. While this is not necessarily a realistic design situation, it provides a simple means for generating, scaling and managing the filter chain. One further simplification is the use of a triangular window for the filter coefficients, allowing the taps to be generated simply through linear interpolation. (See https://www.recordingblogs.com/wiki/triangular-window or https://en.wikipedia.org/wiki/Window_function#Triangular_window)
The same filter chain is deployed in the two implementations using AI and DSP Engines. The design compiles through v++
, and creates a Petalinux-based platform using a script as well as generate the PDI and host application.
The Makefile based build process can be directed to build different length chains with a specified number of taps. A similar set of harnesses are developed and maintained between the two implementations to store input/output vectors in DDR memory and use the data mover kernels to move data to and from AI Engine and HLS FIR kernels. In both cases, XRT running A-72 controls data flow in compute and data mover kernels (graph control APIs control AI Engine kernels and HLS APIs control HLS/PL kernels).
Directory Structure
Directory Structure
filter_AIEvsHLS
+-- AIE.................................contains AI Engine implementation
| +-- design .........................contains source and include files
| | +-- aie_src ....................AI Engine source code
| | +-- exec_files .................contains hw_emu launch script
| | +-- host_app_src ...............A72 application source code
| | +-- pl_src .....................PL (HLS) source code
| | +-- profiling_configs ..........contains xrt.ini file
| | +-- python_scripts .............contains script to generate co-efficients
| | +-- system_configs..............contains all system configuration files
| | +-- vivado_metrics_scripts......contains script for reporting utilisation and power from vivado
| +-- images .........................contains images of the design
| +-- Makefile .......................with recipes for each step of the design compilation
| +-- description.json................required for internal regression
| +-- multi_params.json...............required for internal regression
| +-- sample_env_setup.sh ............contains all environment variables
+-- HLS.................................contains HLS FIR implementation, targeting DSP Engines
| +-- design..........................contains source and include files
| | +-- directives.................contains directives for various vitis compilation stages like hls.pre_tcl etc
| | +-- exec_files .................contains hw_emu launch script
| | +-- host_app_src ...............A72 application source code
| | +-- pl_src .....................PL (HLS) source code
| | +-- profiling_configs ..........contains xrt.ini file
| | +-- python_scripts .............contains script to generate co-efficients
| | +-- system_configs..............contains all system configuration files
| | +-- vivado_metrics_scripts......contains script for reporting utilisation and power from vivado
| +-- images .........................contains images of the design
| +-- Makefile .......................with recipes for each step of the design compilation
| +-- description.json................required for internal regression
| +-- multi_params.json...............required for internal regression
| +-- sample_env_setup.sh ............contains all environment variables
Before You Begin
Documentation: Explore AI Engine Architecture
Documentation: Explore AI Engine Architecture
*Tools Documentation:
Tools: Installing the Tools
Tools: Installing the Tools
To build and run the FIR filter tutorial (AI Engine and DSP implementations), install the following tools.
Install the Vitis Software Platform 2023.2
Obtain licenses for AI Engine tools
Follow the instructions in Installing Xilinx Runtime and Platforms (XRT)
Download and set up the VCK190 Vitis Platform for 2023.2
Download the DSP Library
Environment: Setting Up the Shell Environment
Environment: Setting Up the Shell Environment
When the elements of the Vitis software platform are installed, update the shell environment script. Set the environment variables to your system specific paths.
Edit sample_env_setup.sh
script with your file paths:
export PLATFORM_REPO_PATHS= <YOUR-2023.2-PLATFORM-DIRECTORY>
export XILINX_VITIS = <YOUR-2023.2-VITIS-DIRECTORY>/2023.2
export COMMON_IMAGE_VERSAL=<YOUR-XILINX-VERSAL-COMMON-V2023.2-DIRECTORY>
export DSPLIBS_VITIS=<YOUR-PATH-TO-2023.2-DSP-LIBRARY>
source $COMMON_IMAGE_VERSAL/environment-setup-cortexa72-cortexa53-xilinx-linux
source $XILINX_VITIS/settings64.sh
Then source the environment script:
source sample_env_setup.sh
Validation: Confirming Tool Installation
Validation: Confirming Tool Installation
which vitis
which aiecompiler
Confirm that the VCK190 production base platform is available.
platforminfo --list | grep -m 1 -A 9 vck190_base
Output of the previous command should be as follows:
"baseName": "xilinx_vck190_base_202320_1",
"version": "1.0",
"type": "sdsoc",
"dataCenter": "false",
"embedded": "true",
"externalHost": "false",
"serverManaged": "false",
"platformState": "pre_synth",
"usesPR": "false",
Design Implementations
The Makefile and source files for the AI Engine and HLS implementations are in the respective AIE and HLS directories. For the documentation of the flow to build the design and details of the hardware and software design, click on each of the following links:
AI Engines design implementation
HLS with DSP Engines design implementation
Choosing between AI Engine and HLS Implementations
The choice of which engine (AI or DSP) to use for implementing a specific function in your design or application is not always a simple one. This decision should be taken based on specific requirements of your application with respect to performance requirements and resources. There are some high-level guidelines which can help with architecting your design to a Xilinx Versal device with AI Engines. For example, small functions with modest amounts of computation will most likely be more efficient targeting the PL and DSP Engines. However, as the computational FIR_AIE_64_TAPS_xpe_power.PNGneeds start to increase, moving those functions to the AI Engine will provide better efficiency.
It is important not to take that decision in isolation at the function level, but to look at the problem in relation to the complete dataflow path. For instance, an inefficient function implemented in the AI Engine may offer better total efficiency when preceded and followed in the dataflow by large amounts of efficient compute functions. It is likely that it will offer overall better throughput and latency than moving the data to the PL for that specific function and back into the AI Engine array.
For this discussion, computational efficiency is defined as the throughput (samples per second) divided by power (W), and can only be used to compare designs that are identical from a functional standpoint. Given two identical designs with identical throughputs, this tutorial considers the one using less power as a better solution.
Typically, one of the first steps of a design is deciding on an architecture and implementation to meet throughput and latency targets. This architecture/implementation choice generally determines the resources used and power consumed, which may also be required to meet specific targets.
Meeting Throughput Requirements
Meeting Throughput Requirements
For DSP based design, the designer begins with an estimate of the system clock rate that the PL is capable of, and divides that by the desired filter throughput to determine how many clock cycles can be used to process a sample. By feeding this number into the FIR Compiler, the FIR is constructed with the minimum resources required to implement the design; the higher the clock cycles per sample, the fewer resources used.
For AI Engine based designs, a FIR kernel running on the AI Engine is executing its code at the AI Engine clock rate (which 1 GHz for the platform used). The maximum throughput of various filter configuration has been benchmarked and can be found on the Vitis DSP Library Benchmark/QoR page.
For the filter sizes selected in this tutorial and window_size of 2048 , the following AI Engine throughputs are obtained:
Taps | No of aie_per_firs | Throughput |
---|---|---|
15 | 2 | 1199.9 MSPS(*) |
64 | 2 | 511.574 MSPS |
129 | 4 | 488.685 MSPS |
240 | 4 | 312.07 MSPS |
Note: This result is I/O bound.
The previous table shows the achieved throughput using one AI Engine per FIR. It is possible within the AI Engine array architecture to cascade partial products between neighboring AI Engine tiles and this can help improve overall throughput for a function at the expense of additional resources being used. This is no different to traditional FPGA design in the PL. See Assigning Multiple AI Engines per Filter.
Resource Utilization
Resource Utilization
The AI Engine reduces the overall requirement on the PL and DSPs in a design with a lot of vectorizable compute. For example, the following shows the required resources for the same 64-Tap FIR filter implemented in both AI Engine and PL with DSPs:
Impl | Filters | Taps | Param | Throughput | LUTS | Flops | DSP | AIE |
---|---|---|---|---|---|---|---|---|
AIE | 1 | 64 | win=2048 | 511.573 MSPS | 189 | 568 | 0 | 2 |
HLS | 1 | 64 | ck_per_sam=1 | 497.22 MSPS | 1891 | 5932 | 64 | 0 |
AIE | 10 | 64 | win=2048 | 504.174 MSPS | 189 | 568 | 0 | 20 |
HLS | 10 | 64 | ck_per_sam=1 | 477.145 MSPS | 17350 | 46148 | 640 | 0 |
AIE | 1 | 240 | win=2048 | 134.48 MSPS | 190 | 568 | 0 | 4 |
HLS | 1 | 240 | ck_per_sam=4 | 124.8439 MSPS | 3676 | 22377 | 120 | 0 |
AIE | 10 | 240 | win=2048 | 134.25 MSPS | 190 | 568 | 0 | 10 |
HLS | 10 | 240 | ck_per_sam=4 | 123.48 MSPS | 16733 | 62413 | 600 | 0 |
It is clear that the AI Engine implementation offers significant savings of PL resources, especially as the design size increases.
Note: For the 240 tap FIR filter, the DSP version is processing one sample every four clock cycles. This reduces the throughput, but also proportionately reduces the logic and power. If ck_per_sam
are set to one, the result provides four times the resources, but also utilizes four times the resources and power, leading to an infeasible design from a resources point of view. In any design, targeting any architecture or technology, trade-offs exist and requires understanding to get the most efficient solution for your requirements.
Power Utilization
Power Utilization
In general, smaller designs are more power efficient in the PL than in AI Engines, but the advantage switches over to AI Engines as the design becomes larger. This can be seen in the following dynamic power graph for 240-tap FIR chains with 1 and 10 FIR filters connected sequentially. Below AIE dynamic power values are for window_size of 2048. In the case of the HLS or DSP implementation, the power slope is a straight line. For the AI Engine implementation, a single filter starts off with a much higher dynamic power, but the slope is shallower, so we can see that the power utilization is better for a one DSP implementation of a single FIR filter , but the AI Engine implementation efficiency is better as the number of filters in a chain increases.In ten FIR filters in the chain, the power of the AI Engine implementation is using ~2.362 Watt less than that of the HLS and DSP based FIR filter chain. Below table shows power utilization of FIR AIE and HLS for 240-taps
No of Filters | AIE FIR | HLS FIR |
---|---|---|
1 | 1.217 | 0.948 |
10 | 2.362 | 4.314 |
Note: DSP Refers to the HLS Implementation.
Computational Efficiency
Computational Efficiency
Computational efficiency is a very common and important metric for comparing two designs. It is calculated by dividing the throughput by the power consumed (MegaSamples/Watt). For a given design, the one with a higher number is more efficient in its use of power to perform the computations. In the following graph computational efficiency is plotted for a 240-tap FIR filter chain with 1 and 10 filters. Below AIE Computational efficiency values are for window_size of 2048. For this graph the slope is not relevant, but whether for a given chain, the efficiency of a design is better or worse than the other implementation. Here we can see that the computation efficiency is better for a one DSP implementation of a single FIR filter , but the AI Engine implementation efficiency is better as the number of filters in a chain increases. Below table shows computational efficiency of FIR AIE and HLS for 240-taps
No of Filter | AIE FIR | HLS FIR |
---|---|---|
1 | 256.430 | 315.1102 |
10 | 49.4079 | 28.62282 |
Note: DSP Refers to the HLS Implementation.
AI Engine Specific Design Considerations
Assigning Multiple AI Engines per Filter
Assigning Multiple AI Engines per Filter
For a HLS implementation, specifying the number of clocks per sample establishes the throughput and is the primary factor in determining how many resources are required, and the relationship is quite linear.
For the AI Engine DSPLib FIR filter kernels, the kernels provide a parameter called cascade length (CASC_LEN), which can be used to assign multiple AI Engines to a particular filter kernel. This results in increased throughput, but the relationship is not linear. The following graphs and table shows the results for a single 129 tap FIR filter, with CASC_LENs of 1,2, and 4.
Cascade length | Throughput (MSPS) |
---|---|
1 | 200.96 |
2 | 332.92 |
4 | 488.64 |
Cascade length | Dynamic power(W) |
---|---|
1 | 0.817 |
2 | 0.950 |
4 | 1.220 |
CASCADE LENGTH | Performance(MSPS/W) |
---|---|
1 | 245.9790 |
2 | 350.8082 |
4 | 401.509 |
As can be seen, going from CASC_LEN =1 to CASC_LEN=2 produces a significant improvement in performance. Going from CASC_LEN=2 to CASC_LEN=4 increases performance even further, but offers diminishing returns. Given that power increases with increasing AI Engines, the resulting computation efficiency chart shows that adding more AI Engines can potentially decrease computational efficiency as seem in this case.
However, some application may need every bit of throughput performance available and are not power constrained, others may see the two cascade option as optimal as it gives the best performance while maintaining the design within the power constraints. All decisions should be made with the complete application and its requirements in mind.
The following table provides some additional information on data on throughput for various filter sizes implemented on the AI Engines using different cascade lengths:
Filters | Taps | Throughput (CASC_LEN=1) | Throughput (CASC_LEN=2) | Throughput (CASC_LEN=4) |
---|---|---|---|---|
1 | 15 | 1199.99 MSPS(*) | 1199.999 MSPS | Too small to cascade |
1 | 64 | 344.081 MSPS | 511.573 MSPS | 660.201 MSPS |
1 | 129 | 200.964 MSPS | 332.917 MSPS | 488.637 MSPS |
1 | 240 | 116.911 MSPS | 200.024 MSPS | 325.380 MSPS |
(*)Note: this result is I/O bound.
Window Size
Window Size
The AI Engine processes data in bursts and these data bursts are transferred between AI Engines utilizing ping-pong buffers. The data from one engine is written into one of the two buffers and when it is filled, the buffers are swapped and the data read out by the downstream engine. The size of these data bursts is referred to as the window size, and establishing the optimum window size is a balancing act between throughput and latency. Larger window sizes provide higher throughput because there the burst overhead is less of an influence on the performance. However, latency increases proportionately to the window size.
Thus, the window size should be chosen to be just large enough such that the desired throughput target is met.
The following is data for the AI Engine with one 64-tap FIR filter example for various window sizes:
Impl | Filters | Taps | Window Size | Latency | Execution Time | Throughput |
---|---|---|---|---|---|---|
AIE | 1 | 64 | 64 | 1.100 us | 136.53 us | 120.00 MSPS |
AIE | 1 | 64 | 256 | 3.333 us | 136.5333 us | 119.999 MSPS |
AIE | 1 | 64 | 1024 | 12.30 us | 136.53 us | 120.00 MSPS |
AIE | 1 | 64 | 2048 | 8.306 us | 47.61 us | 344.08 MSPS |
If, for example, our throughput requirements were 250 MSPS, a window size of 64 would satisfy that performance requirement with the least amount of latency.