Versal devices have a centralized PMC that boots the device after power on reset. Versal devices support different boot modes, including primary (JTAG, SD, eMMC, 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 where there is a requirement to detect an Endpoint in less than 100 ms of system power on, use a faster boot device like OSPI. The image can be partitioned so that a minimal boot image boots from the OSPI boot mode in less than 100 ms, and the larger boot partition can be transferred 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.
- 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 or switch to JTAG boot mode by configuring the boot mode register from the TAP chain.
Applications that require device-level security need to implement boot image encryption and authentication supported by the Versal ACAP hardware. With encryption and authentication enabled, there is a corresponding increase in the system boot time. For more information, see the Versal ACAP Security Manual (UG1508), Asymmetric Hardware Root of Trust Secure Boot (XAPP1357), and Symmetric Hardware Root of Trust Secure Boot (XAPP1358) available from the Design Security Lounge (registration required) on the Xilinx website.
Versal ACAP boot devices support partition fallback to avoid catastrophic boot failure. During a field upgrade, if the upgraded image has an error, the 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. Xilinx provides Linux runtime support using the Xilinx run time (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 FPD power to be on. Applications requiring significant power saving can use Arm Cortex-R5F processor that works in LPD.
Applications that require real-time processing can leverage the Arm Cortex-R5F processors in Versal ACAP. 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. If the Arm Cortex-R5F processor is targeted for a functional safety application, Xilinx recommends fitting the application code in the TCM instead of accessing the code from DDR memory. The Arm Cortex-R5F processor can also work as a co-processor to the Linux OS, monitoring specific hardware functionality and providing 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.