Fixed Platforms versus Extensible Platforms - 2022.2 English

Vitis Unified Software Platform Documentation: Application Acceleration Development (UG1393)

Document ID
Release Date
2022.2 English

Traditional Fixed-Platform Design

A fixed platform design is a hardware design completed in the Vivado Design Suite. You can use the Vivado IP integrator feature to stitch together IP in a block design, or you can describe the hardware system in RTL. You can also use Vitis HLS to create hardware functions in C++ and generate Vivado IP to add to your hardware design.

You will use the write_hw_platform -fixed command to create a Xilinx Shell Archive (.xsa) of the completed hardware design; and use either the Vitis IDE, or the Xilinx Software Command-line Tool (XSCT) to define a platform project, import the fixed .xsa, and configure and define processor domains, or BSPs for the fixed-platform. The fixed platform (.xpfm) can be used in a traditional embedded software design flow to create embedded applications for Versal ACAP devices, or Zynq MPSoC devices.

The development of software applications for embedded processors requires the use of hardware drivers delivered as part of the exported hardware container (.xsa). You must manage and use the drivers to access your hardware design from your software application. This traditional embedded software design flow is fully documented in the Vitis Embedded Software Development User Guide (UG1400).

Extensible Platform-Based Design

The extensible platform also starts with the Vivado Design Suite to define an extensible hardware design (.xsa) that allows the addition of programmable components such as PS and AI Engine features to quickly vary the resulting embedded system design. The extensible .xsa is a container that provides the foundation of the hardware design for the v++ linker to extend by updating a dynamic region of the design. The extensible platform allows the embedded system designer to easily extend the functionality of the extensible hardware foundation.

For embedded system designs, a parallel development process can be used where different elements of the heterogeneous system can be developed concurrently. The application team starts work with a Xilinx base platform, such as the VCK190 or ZCU104, to develop the programmable components of the system. Using an available platform means that the application can be developed and tested independently using a known-good system. At the same time the platform team works to build and validate the custom platform. You are strongly encouraged to use an existing platform design as a reference for your own custom platform designs. Current Xilinx embedded platforms can be found in the Vitis installation, and their source code can be found in the Vitis Embedded Platform Source repository on GitHub.

The hardware part of the extensible platform is a Vivado project containing any required IP such as an interrupt controller and clock wizard, as well as any additional features you want to implement into the hardware design. Extensible platform designs have specific requirements as described in Creating Embedded Platforms in Vitis, such as AXI-4 interfaces for linking PL kernels into the system, memory controllers, one or more clock and reset signals, and a single interrupt. More information on required interfaces can be found at Adding Hardware Interfaces.

Tip: As described in Versal ACAP Design Guide (UG1273), you must use the IP integrator to configure and connect required IP such as the CIPS IP, the NoC/DDRMC IP, and hardware debug IP to take advantage of block design automation when building and updating your hardware design. However, you can use the IP integrator feature to configure and connect these critical Versal ACAP IP and then instantiate the resulting hierarchical module into a higher-level RTL design.
Figure 1. Fixed or Extensible Platform

The hardware design file (.xsa) is exported from the Vivado project using the write_hw_platform command and imported into a Platform project in the Vitis IDE, or XSCT. In the Platform project the software components (processor domains, DeviceTree, OS) are packaged with the hardware (.xsa) to create a custom extensible embedded processor platform (.xpfm):

  • Operating System includes standalone (or baremetal), FreeRTOS, or Linux. For systems running XRT, Linux is required.
  • Processor specifies the Arm core to use for the specified OS domain. Note that the choice of OS determines which processors are available to configure.
    Tip: The initial Platform project setup lets you configure one processor domain, but the IDE lets you configure additional domains once the project has been established. Advanced settings of the platform, such as for DFX platforms, must be accessed through XSCT.

When the platform has been built, an export folder is added to the hierarchy of the project, and the platform .xpfm file and ./hw and ./sw folders are added to the platform. The new platform is added to the $PLATFORM_REPOSTORY_PATHS environment variable, and the platform can be used for application development with the Vitis tools.

The platform-based design flow uses the Vitis tool for the definition of OS, domains, and software applications in the embedded system, but also uses the Vitis compiler (v++) to link PL kernels and AI Engine graph applications with the extensible hardware platform. This flow promotes concurrent development of the different elements of the system and facilitates the integration process of heterogeneous systems.

Important: The platform-based embedded system design flow is a more complex but more adaptable flow. It is the required flow for using AI Engine graph applications on Versal AI Core devices. This flow also requires XRT running on a Linux OS to control the components of the hardware design, and simplify writing software applications to work with the embedded hardware design.

The extensible platform is adapted by linking PL kernels (.xo) and AI Engine graph applications (libadf.a) to the hardware design using the v++ --link command. However, in designing the extensible platform, you can decide how much or how little to include in the hardware design (.xsa) of the platform. As described in Generate XSA file, an extensible platform has minimum content requirements such as interrupt controller and clock wizard. You can choose to design a platform with the minimum content required and add functionality to your system through PL kernels, or you can add features directly to the platform hardware design while relying less on PL kernels.

A minimal platform is more flexible, more easily defined, and quicker to iterate and implement new functionality. However, implementing functionality directly in the platform has the advantage of integrating existing RTL code rather than packaging the IP for use as PL kernel.