Versal AI Engine/HLS FIR Filter Tutorial - Versal AI Engine/HLS FIR Filter Tutorial - 2026.1 English - XD100

Version: Vitis 2025.2

Introduction

AMD Versal™ adaptive SoCs combine programmable logic (PL), processing system (PS), and AI Engines with leading-edge memory and interfacing technologies. These features 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 is one of the several to perform two system-level design approaches using AI Engines and high-level synthesis (HLS) with DSP engines in a Versal device. The PL resources include look-up tables (LUTs), flip-flops (FFs), and blockRAM modules. In each implementation, you perform hardware emulation and hardware runs in the context of a complete Versal adaptive SoC system design. Each tutorial includes a makefile 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. Throughout the tutorial, you work with the Vitis application acceleration development flow and library kernels to integrate kernels easily and scale them in a system design. In the Vitis application acceleration development flow, the Vitis HLS tool automates many code modifications required to implement and optimize the C or C++ code in PL. This automation includes simplifying data mover kernel coding. The tool infers pragmas to define correct interfaces for your function arguments and to pipeline loops and functions. This process is central to Vitis HLS in the application acceleration flow. The inference of required pragmas to produce the right interface for your 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 can increase PL-based performance. For example, LogiCORE™ finite impulse response (FIR) Compiler IP and register transfer level (RTL)-based data movers can boost raw performance but also raise dynamic power and extend design time.

A common question is whether using AI Engines, HLS, or RTL targeting digital signal processors (DSPs) produces the best implementation. The answer depends on your design objectives, complexity, and unique characteristics. Review the section in this tutorial that discusses trade-offs to identify the best choice for your design. Another section explains AI Engine-specific design considerations because AI Engines are a relatively new technology compared to the mature field‑programmable gate array (FPGA) fabric or PL with DSPs.

Overview

This tutorial implements a FIR filter chain in two ways: one targeted at AI Engines and one targeted at DSP engines using Vitis HLS.

Explore the FIR filters large design space using the following fixed/constant parameters:

• Data Type: cint16

• Coefficient type: int16

• Symmetric FIR

• Fixed, non-reloadable coefficients

Specify the number of filter taps and cascaded filters in the chain 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. You can further simplify the design by using a triangular window for the filter coefficients. This generates the taps through linear interpolation. (Refer to https://www.recordingblogs.com/wiki/triangular-window or https://en.wikipedia.org/wiki/Window_function#Triangular_window for more information.)

You deploy the same filter chain in AI Engine and DSP engine implementations. The design compiles through v++ and creates a Petalinux-based platform using a script and generates the programmable device image (PDI) and host application.

Direct the makefile-based build process to build chains of different lengths with a specified number of taps. Maintain matching harnesses for both implementations to store input and output vectors in DDR memory. Use the data mover kernels to move data to and from AI Engine and HLS FIR kernels. Control data flow with XRT running on the Arm Cortex A-72 processor. Use graph control APIs for AI Engine kernels. Use HLS APIs to control HLS or PL kernels.

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

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 2025.2

• Obtain licenses for AI Engine tools

• Download and set up the VCK190 Vitis Platform for 2025.2

• DSP Library (DSPLib) Documentation

• Download the DSP Library

Environment: Setting Up the Shell Environment

After installing the elements of the Vitis software platform, 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-2025.2-PLATFORM-DIRECTORY>
export XILINX_VITIS = <YOUR-2025.2-VITIS-DIRECTORY>/2025.2
export COMMON_IMAGE_VERSAL=<YOUR-XILINX-VERSAL-COMMON-V2025.2-DIRECTORY>
export DSPLIBS_VITIS=<YOUR-PATH-TO-2025.2-DSP-LIBRARY>

source $COMMON_IMAGE_VERSAL/environment-setup-cortexa72-cortexa53-amd-linux
source $XILINX_VITIS/settings64.sh

Then source the environment script:

source sample_env_setup.sh

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

The output of the previous command is 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 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. Base your decision on specific application requirements of performance and resource usage. Use high-level guidelines to assist with architecting your design to a Versal device with AI Engines. For example, small functions with modest amounts of computation most likely need to be more efficient targeting the PL and DSP engines. As computational need increase, move those functions to the AI Engine for more efficiency.

Do not decide engine placement in isolation at the function level. Evaluate the problem within the complete dataflow path. An inefficient function implemented in the AI Engine can improve total efficiency if surrounded by highly efficient compute functions in the dataflow. Such placement can deliver better throughput and latency compared to moving the data to PL for that function and back into the AI Engine array.

For this discussion, define computational efficiency as the throughput (samples per second) divided by power (watts). Use computational efficiency only when comparing functionally identical designs. Given two identical designs with identical throughputs, this tutorial considers the design using less power as a better solution.

Typically, start a design by deciding on an architecture and implementation to meet throughput and latency targets. Recognize that the architecture and implementation usually determine resource usage and power consumption, which can be critical for meeting specific targets.

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:

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 processes one sample every four clock cycles. This reduces the throughput, but also proportionately reduces the logic and power. If ck_per_sam is 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

In general, smaller designs are more power-efficient in the PL than in AI Engines. As designs grow larger, efficiency advantage shifts to AI Engine implementations. This is represented in the following dynamic power graph for 240-tap FIR chains with 1 and 10 FIR filters connected sequentially. The AIE dynamic power values below use a window_size of 2048. For 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. One DSP implementation of a single fir filter uses less power than one AI Engine implementation filter. As the number of filters increases, AI Engine efficiency improves. In a ten-FIR chain, AI Engine implementation uses about two watts less than HLS or DSP-based FIR filter chains. The following table shows power utilization of FIR AIE and HLS for 240-taps

Note: DSP Refers to the HLS Implementation.

Computational Efficiency

Computational efficiency is a common and important metric for comparing two designs. Calculate it by dividing the throughput by the power consumed, in mega samples per watt (MS/W). For a given design, a higher number is more efficient in its use of power to perform the computations. The following graph plots the computational efficiency for a 240-tap FIR filter chain with one and ten filters. The AIE computational efficiency values use a window_size of 2048. In this comparison, slope is irrelevant. Focus on whether, for a given chain, one design is more efficient than another. For a single FIR filter, a single DSP implementation is more efficient. As the number of filters increases in the chain, AI Engine implementations become more efficient than HLS or DSP designs. The following table shows computational efficiency of FIR AIE and HLS for 240-taps

Note: DSP Refers to the HLS Implementation.

AI Engine Specific Design Considerations

Window Size

The AI Engine processes data in bursts. Data bursts transfer between AI Engines using ping-pong buffers. One engine writes burst data into one of the two buffers. When full, buffers swap, and the downstream engine reads the data. Window size refers to the size of these data bursts. Establishing the optimum window size is a balancing act between throughput and latency. Larger window sizes provide higher throughput because burst overhead impacts performance less. Latency increases proportionately to the window size.

Thus, choose the window size that is only as large as the desired throughput target.

The following is data for the AI Engine with one 64-tap FIR filter example for various window sizes:

If, for example, our throughput requirements are 200 MSPS, a window size of 64 satisfies that performance requirement with the least amount of latency.