Vitis Key Concepts - Vitis Key Concepts - 2026.1 English - UG1701

Embedded Design Development Using Vitis User Guide (UG1701)

Document ID
UG1701
Release Date
2026-07-31
Version
2026.1 English

This topic introduces key concepts for understanding and using Vitis tools for embedded system design. The tools support a variety of development flows that use either scripted execution or interactive design entry through the Vitis IDE. All flows produce the same outcome, but your skill level and project requirements determine which flow is best suited to your needs. The following table describes the design steps.

Table 1. Conceptual Design Steps
Step Comment
Select Device Declared as a part or a board.
Set Up Basic Hardware Infrastructure Referred to as the hardware platform, which you create with AMD Vivado™ . A valid hardware platform consists of Vivado IP integrator components such as the CIPS, NoC, and at least one clock with an associated reset. You can also add the AI Engine, NoC DDRMC, AXI SmartConnect, and AXI Interrupt Controller, along with clock domains, resets, and custom RTL IP. Within the block design, PFM attributes on cells and ports define potential attachment points for kernel control, access to DDR and other memories, streaming input/output, clocks, resets, and interrupts. You export this initial design to Vitis as an extensible hardware platform.
Add Processing Elements Referred to as Vitis components, which include PL kernels and AI Engine graphs.
Note: You develop and verify these components independently before adding them. Component development is outside the scope of this document.
Implement Hardware In Vitis terminology, this is the process of compiling and linking the hardware system. The Vitis implementation step uses Vivado for PL synthesis, place, and route.
Add Software Applications Control or processing applications that run on processors such as the APU, RPU, or MicroBlaze.
Package Software and Hardware The process of combining loadable objects and executable applications into a binary deliverable, such as an SD card or QSPI flash image.
Deploy and Run on Target This step loads the binary deliverable and runs it on hardware or in hardware emulation.

The following figure shows a conceptual flow for designing and integrating an embedded system with AMD tools.

Figure 1. Vitis Conceptual Design Flow

Vitis tools support different design flows, as described in Vitis Flows and Build Environment. The following sections focus on the tools and techniques for creating and integrating these components.

Terminology for Embedded System Design

The following list introduces the tools and terms you encounter in this document.

Vitis core development kit
A framework for designing, building, and debugging heterogeneous applications using standard programming languages for both software and hardware components.
Vivado Design Suite
An RTL language design, synthesis, and implementation tool that lets hardware designers create and export hardware designs (.xsa).
AMD Embedded Development Framework
The AMD Embedded Development Framework (EDF) is a common framework that supports platform-level development and embedded software solutions for AMD adaptive SoC and FPGA products and their evaluation boards.
Hardware Design File (.xsa)
A hardware container exported from the Vivado Design Suite for multiple uses, including use in a fixed or extensible platform.
Fixed Platform (.xpfm)
Includes a completed hardware design (.xsa) and supporting software files that define the operating system, libraries, and boot files. In this context, "fixed" means that the hardware design is complete.
Extensible Platform (.xpfm)
The target platform of the Vitis heterogeneous system design flow. In this context, "extensible" means that the design can be further customized by adding programmable content, such as PL kernels and AI Engine graph applications, to build the embedded system. You can also use an extensible platform to develop software, just as you do with a fixed platform.
PL kernel (.xo)
A hardware function added to the PL region of an extensible platform to define custom hardware. You can define PL kernels using C++ code in Vitis HLS, or using RTL code and the IP packager feature of the Vivado Design Suite.
Vitis HLS
A high-level synthesis tool that translates C/C++ functions into RTL for implementation in the programmable logic (PL) region of a device. Vitis HLS generates a compiled object (.xo) file that you can import into the Vitis environment.
Vitis Compiler
The v++ command used to compile PL kernels (.xo) from C++ code, and to link multiple PL kernels with hardware platforms and AI Engine graph applications to build the device binary.
PS Application
A user-defined software application that runs on an Arm processor in an AMD MPSoC or adaptive SoC device and that can control and interact with PL kernels and AI Engine graphs.
Xilinx Runtime library (XRT)
Provides an API and drivers that let your software application control, transfer data to, and read the status of the PL kernels and AI Engine graph application in the hardware design.
AI Engine kernel and graph applications
Compiled by the Vitis aiecompiler and linked into the embedded system with v++. Kernels are functions that run on Versal AI Engines and form the fundamental building blocks of a dataflow graph application. The AI Engine graph application is an adaptive dataflow graph with deterministic behavior.
aiecompiler/aiesimulator
Vitis tools for compiling and simulating AI Engine graph applications.
Vitis Subsystem (VSS)
A platform-independent, reusable design component that targets a specific part and combines AI Engine kernels, programmable logic (PL) kernels, or other VSSs. The VSS is compiled and linked with v++ into a .vss library component.
Vitis Functional Simulation (VFS)
A toolset for functional simulation and verification of AI Engine graphs and HLS PL kernels in a MATLAB or Python environment.
Device Binary (.xclbin) file
Contains the programmable device image (PDI) for the Versal adaptive SoC or the bitstream for the Zynq MPSoC, along with the metadata needed to control the hardware design. Metadata-only .xclbin files can be used for runtime control of a loaded PDI image.