Versal devices have a centralized platform management controller (PMC) that boots the device after power on reset. Versal devices support different boot modes, including primary (JTAG, SD, eMMC, UFS, OSPI, QSPI, SelectMAP) and secondary (PCIe) boot modes. Depending on the boot time requirement, you must select the appropriate boot device.
- For PCIe-based applications, there is a requirement to detect an Endpoint in less than 100 ms of system power on. Use a faster boot device like OSPI. Partition the image to enable a minimal boot image to boot from the OSPI boot mode in less than 100 ms. Transfer the larger boot partition over PCIe in Tandem PCIe boot mode.
- Use QSPI, SD, and eMMC boot devices for general embedded applications. Use eMMC boot mode for embedded applications that require higher density.
- For Versal AI Edge Series Gen 2 and Versal Prime Series Gen 2 devices, the highest capacity and performance, use the UFS boot mode. This interface uses gigabit transceivers for clock and data with a couple of LVCMOS pins for detection and clock configuration.
- Use JTAG boot mode for initial system bring-up and for debug. To enable system debug, ensure the boot mode pins are set to JTAG. Alternatively, switch to JTAG boot mode by configuring the boot mode register from the TAP chain.
- Use SelectMAP for applications that require a single external boot control solution for multiple Versal devices.
Applications that require device-level security need to implement boot image encryption and authentication supported by the Versal adaptive SoC hardware. With encryption and authentication enabled, there is a corresponding increase in the system boot time. For more information on boot time estimator, see Support. For more information, refer to the following documents:
- Versal Adaptive SoC Security Manual (UG1508)
- Versal AI Edge Series Gen 2 and Prime Series Gen 2 Security Manual (UG1724)
- Asymmetric Hardware Root of Trust Secure Boot (XAPP1357)
- Symmetric Hardware Root of Trust Secure Boot (XAPP1358) available from the Design Security Lounge (registration required) on the AMD website
Versal adaptive SoC flash boot devices support partition fallback to avoid catastrophic boot failure. During a field upgrade, the upgraded image can have an error. In that case, the platform loader and manager (PLM) can fall back to a golden image to recover the boot mode. The golden image can reside in the same boot device as other upgrade images.
Select the OS depending on your application-specific use case. For applications requiring buffer management, locked access, and interrupt handling with multiple processes running in parallel, use the Linux OS. These applications can leverage the open source Linux framework that provides higher level abstraction. Typical applications include video, OpenCL™ , OpenCV, and networking stacks that can leverage the Linux framework. AMD provides Linux runtime support using the XRT stack that handles interrupt management, starting and stopping of kernels, buffer allocation, and sharing.
XRT can interface with higher-level software stacks like OpenCL, OpenCV, FFmpeg, and Python-based frameworks. One downside of using the Linux-based stack is the stack overhead, which is not suitable for real-time operations. Also, the Linux OS requires full-power domain (FPD) power to be on. Applications requiring significant power saving can use Arm Cortex-R5F processor that works in low-power domain (LPD).
Applications that require real-time processing can leverage the Arm Cortex-R5F processors in Versal adaptive SoC. Arm Cortex-R5F processors are ASIL-C safety compliant. Typical application mapping involves system monitoring, hardware monitoring, direct hardware control with light weight stack, and so forth. AMD recommends placing the application code in the tightly-coupled memory (TCM) if you target the Arm Cortex-R5F processor for a functional safety application. This approach is preferred over accessing the code from DDR memory.
The Arm Cortex-R5F processor can also work as a co-processor to the Linux OS. It monitors specific hardware functionality and provides hardware status to the Linux application. The communication between the Linux OS and RTOS/bare-metal OS on the Arm Cortex-R5F can happen via the inter-processor interrupt.
Versal devices support virtualization. You can use the same hardware for multiple guest OS using a hypervisor. There is a longer interrupt processing overhead with virtualized hardware. Virtualization causes latency. If your application is latency sensitive, do not use virtualization.