This page provides a general description of the AMD Embedded+ platform architectures which brings together an AMD Ryzen and an AMD Versal FPGA SoC. The goal of this page is to give an overview of the hardware architecture and the two AMD developed example SW solutions that a customer can use as a reference and starting point on these platforms.

This page will not try to describe detailed hardware designs (e.g. schematics) for physical platforms. For this information please consult the corresponding hardware vendor.

The architecture captures the standard practices used for creating an integrated system of a Ryzen x86 + AMD Versal SoC. If you match these hardware practices, then the example designs, tools, and software examples that AMD provides can be more readily leveraged across specific hardware platform implementations.

The Embedded+ systems leverage an AMD embedded x86 processor connected via PCIe to AMD’s Versal Edge device as the primary application interface. Side-band interfaces such as UARTs are optionally enabled to support debug and low-speed side-band interfaces when available.

The Versal device includes an I/O board expansion connector to enabled application specific I/O to be mapped into the Versal FPGA and abstracted to the Ryzen PCIe interface within the Versal application logic implementation. This allows for the flexible Versal FPGA to be mapped to a variety of different interfaces, sensors, and connectors through a custom I/O board design.

A hardware architecture connection between Versal and Ryzen is shown in the figure below. Key interfaces are:

• The PCIe interface between Ryzen and Versal SoC.

  • The primary physical interface between Ryzen and Versal is PCIe. It can be configured as x1, x2, x4, x8, or x16. Current example platforms are all PCIe x4.

  • The Ryzen SoC configures one of its PCIe controller interfaces as the root port.

  • The Versal SoC uses an integrated PCIe controller configured as the endpoint.

• USB is used for debug interface between the Ryzen and Versal devices using an FTDI device to interface to the device JTAG and UARTs

  • Recommended: The Ryzen USB controller is interfaced to an FTDI device that provides a Ryzen JTAG interface and one or more Versal UART interfaces. This interface allows for the x86 device to act as a debug and development environment for the Versal SoC.

  • Optional: The Versal USB controller is interfaced to an FTDI interface, providing JTAG and UART interface to the Ryzen device. This interface allows for Versal to provide debug and UART based back channel communication to the Ryzen.

Open

There are two example platform software design references provided for Embedded+. They differ in terms of their intended scope and which is the best starting point is dependent on the layer at which a user intends to customize the solution. The functionality of each solution is categorized into three high-level scope:

• Management Plane - Solves the aspects of loading, updating, and maintaining Versal artifacts and Versal non-volatile memory from the Ryzen device.

• Data Plane - Application data mover selection and runtime APIs. This impacts specific DMA IP selection and API structure used once the Versal design configuration has been loaded.

• Control/Execution Plane - Application execution of Versal functionality such as start, stop, and sequencing of Versal based application kernels.

The two platform software examples and their scope are summarized in the following table:

The selection of the runtime software example is user dependent. A more complete solution like the Vitis XRT solution has a-priori made selections around the specific DMA IP and execution orchestration model in order to be able to build a higher level SW kernel solution stack. For users not customizing data movers and or kernel execution patterns the Vitis XRT Platform solution is a good starting point. For users customizing at a lower layer of the solution stack the AMR solution may be a better starting point as it only tries to solve the application agnostic management plane and allocates a PCIe PF (PF1) for the user to map their custom solution and binder their Ryzen side driver to.

The Vitis workflow is enabled through the Vitis Design Tool and the Vitis Accelerator workflow works in conjunction with the XRT runtime software.

The runtime software architecture for a Vitis accelerator based platform is outlined in the screen capture below. The Versal SoC is configured and booted as a PCIe endpoint interacting with the PCIe host served by the x86 processor. The software architecture consists of four main components and assumes an XRT x86 host supported Linux OS:

1. Versal Management Runtime (VMR) - Firmware that runs on the Versal device and handles device boot and management functions.

2. Versal XRT-ZOCL - Software that runs on the Versal device and handles application runtime interfaces and orchestration with x86 host.

3. Host XCLMGMT - x86 host side XRT device management driver which interacts with VMR.

4. Host XRT XOCL - x86 host side XRT runtime application driver which interacts with XRT-ZOCL.

Open

The Versal Management Runtime (VMR) boots from the OSPI device dedicated to the Versal device. This boot firmware runs on a dedicated RPU and controls the initial PCIe configuration. The VMR is a FreeRTOS implementation that provides all Versal related device management functionality including loading the APU based ZOCL image from the Ryzen host. The VMR function is mapped to PCIe PF0. The VMR interfaces with the XCLMGMT driver that runs on the Ryzen host. The source for VMR is available on GitHub: GitHub - Xilinx/VMR: XRT RPU firmware for Versal

The ZOCL is runtime software that runs on the Versal APU. It provides the primary on-target user application functionality. It is loaded as a binary from the x86 Host. The ZOCL APU functionality is mapped to PCIe PF1. The ZOCL interfaces with the XOCL driver that runs on the x86 Host.

The XCLMGMT function is a component of the XRT software that runs on the x86 host to support AMD PCIe peripheral devices and control functions. Details can be found in the XRT-XCLMGMT documentation at this link.

The XOCL function is a component of the XRT software that runs on the x86 host for supporting user application interfaces to the AMD PCIe peripheral device. Details on the XRT-XOCL can be found in the documentation at this link.

In the Vitis work flow, the platform shell is a base hardware configuration that is application agnostic and is used to support the device boot with the necessary infrastructure to allow users to download XRT based acceleration kernels to the target. The User partition contains a user compiled binary called xclbin which is loaded by XRT using DFX technology. For more details on platform partition between the shell and user, refer to this platform loading overview page.

The base design implemented in Vivado has three major components:

• CIPS – Instantiates the PS subsystem configurations defined in this document.

• PCIe + DMA – PL based data mover interface and configuration of the hardened PCIe block

• NoC – Instantiates the necessary interconnect and configuration for the CIPS, CPM, DDR controller, and infrastructure interconnects for board logic platform (BLP) and user logic platform (ULP).

A functional diagram of the platform shell is shown below, outlining which parts of the Versal configuration will be managed by the platform shell and which resources will be allocated for the user application.

Open

A given accelerator generated by Vivado will have a parent-child relationship with the shell it is built against. These are tracked by Vivado as a “UUID”. The Vitis accelerator loaded to a running platform shell must have their UUIDs aligned.

The Embedded+ example Vitis platforms are released to the Embedded+ Vitis Platforms GitHub repository.

The Vitis flow, in which the Versal device is managed and the software stack is managed, is similar to that of Alveo. More information on Alveo’s Vitis acceleration can be found in this link.

The AMR solution focuses only on solving the management plane solution within the PCIe PF0 interface and leaving PF1 for a user to create customer application logic and a corresponding driver that would bound to PF1 within the Ryzen OS. This provides a clean segmentation between the management plane solution and a sandbox for custom application development and extension within the application PF (PF1) as shown in the figure below:

Open

The AMR solution has been demonstrated on the Sapphire VPR-4616 but is open-sourced with the intent for maximal re-use when a user creates their custom solution on an Embedded+ platform target. The VPR-4616 examples uses a 2-PF variant of the XDMA IP to minimize resource utilization within the Versal SoC.

This section lists example Embedded+ Hardware platforms available on the market and links to more information.

• Sapphire Edge+ Platforms

  • HW Platforms

    • VPR-4616 / HW-4616-SYS

    • VPR-5050

    • VPR-5050A (note: prebuilts not available for this device)

  • Sapphire FPGA I/O Boards

  • Supporting SW Examples:

    • Vitis XRT Platform

      • Vitis HW Platform: GitHub - Xilinx/emb_plus_vitis_platforms

      • Versal APU & Runtime SW: GitHub - Xilinx/meta-embedded-plus

      • Example applications: GitHub - Xilinx/emb-plus-examples

    • AMR Platform - GitHub - Xilinx/amr

  • Vivado Board File (Applies to both VPR-4616 and VPR-5050) - XilinxBoardStore/boards/Xilinx/emb-plus-vpr-4616/1.0 at 2024.2 · Xilinx/XilinxBoardStore