Fixed Platforms versus Extensible Platforms - 2023.1 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 adaptive SoC 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 AI Engine and PL kernels and subsystem features to quickly customize 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 an AMD 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 a custom hardware platform. You are strongly encouraged to use an existing platform design as a reference for your own custom platform designs. Current AMD 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.

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 Vitis platform based design flow extends standard Vivado Embedded Design Methodology to build embedded system hardware, employing 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.

The extensible platform hardware is customized by linking PL kernels (.xo) and AI Engine graph applications (libadf.a) to the hardware design using the v++ --link command. In designing an extensible platform, you have considerable control over the structure and content of the hardware. As described in Generate XSA file, there are minimum requirements associated with CPU control, memory, and clocking; otherwise, you have control to employ the best tools for specific tasks in your platform design.

A minimal hardware platform is ideal for AI Engine and PL kernel subsystem development, and by aligning platform PFM interfaces, you can readily re-target such subsystems to more complete system platforms with minimal or no changes to your source code.