This page provides a general description of the AMD Embedded+ platform architectures which captures an AMD x86 paired with an AMD Adaptive SoC. The goal of this page is to give an overview of the Hardware architecture concepts and the various workflows that a customer can use with 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.

Table of Contents

Hardware Architecture

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 infrastructure that AMD provides as examples can be more readily leveraged across specific hardware platform implementations.

Physical interface connections

The Embedded+ systems leverage an AMD embedded x86 processor connected via PCIe to AMD’s Versal Edge device. The Versal device is connected to expansion slots to enable it to interface with different interfaces, sensors, and connectors.

A hardware architecture connection between Versal and Ryzen is shown in the figure below.
Important connections 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

Customer Workflows

AMD FPGA SoCs in general are supported through two main work flows:

1. Vivado - Focuses on the traditional RTL developer, doing low-level FPGA SoC device definition.

2. Vitis - Focuses on software application developers by using a pre-defined “Vitis Platform” that fixes physical hardware interfaces and assumes DMA architecture decisions.

The Embedded+ platform is no different in this regard and an application developer can use either workflow to develop applications on Embedded+ type platforms.

Vitis Workflow

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

Vitis Accelerated XRT Based Work Flow Software Architecture

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

Versal Management Runtime (VMR)

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.

ZOCL

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.

XCLMGMT

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.

XOCL

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.

Vitis Workflow Platform Shell

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.

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.

Vivado based flow

The Vivado based flow is functional for Embedded+ as it is for any chip down design. A Vivado board file is provided as the starting point for Vivado based application development. The Vivado board files are released and managed within the Xilinx Board Store on GitHub.

Example Hardware Systems

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

• Sapphire VPR-4616

  • Vitis Platform: https://github.com/Xilinx/emb_plus_vitis_platforms

  • Example applications: https://github.com/Xilinx/emb-plus-examples