A platform provides design context to integrate AI Engine design and PL kernels. Platform hardware is represented by an XSA container built using the Vivado Design Suite, and a platform software that includes a board support package (BSP), in addition to operating systems, boot files, drivers, libraries, and file systems to link application software and build boot images. The Vitis SDK and PetaLinux tools can be used to build BSPs, in addition to system and application software customized to your implemented hardware that includes AI Engine and PL kernels. There are two kinds of platforms as described below.
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 Unified Software Platform Documentation: Embedded Software Development (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, in addition to 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.
The Tcl command to export a fixed XSA is write_hw_platform -fixed <.xsa> and the command to export an
extensible XSA is write_hw_platform -force
<.xsa>. Synthesis and implementation must run before exporting
the fixed XS from Vivado.
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. 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 Vitis via the v++ command 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.