Translation of Chapter 13 from the compilation “RFSoC-Book” is detailed in the first article of this series.
“An open-source masterpiece, ‘Software Defined Radio Based on Zynq UltraScale+ RFSoC'”
Mr. Big Cat, WeChat public account: Mr. Big Cat’s Little Bookcase, an open-source masterpiece, ‘Software Defined Radio Based on Zynq UltraScale+ RFSoC’
Processing System (PS) DesignRFSoC devices integrate a Processing System (PS) in addition to PL and hard IP resources. The PS contains Arm processing cores capable of running software programs. The PS subsystem of RFSoC is highly consistent with the architecture of MPSoC CG series devices, including: up to two Real-time Processing Units (RPU) and up to four Application Processing Units (APU). The RPU, based on the Arm Cortex-R architecture, is designed for real-time and safety-critical applications and can run bare-metal programs or Real-Time Operating Systems (RTOS). The APU, based on the more powerful Arm Cortex-A53 architecture, supports complete operating systems such as Linux and Android™.This article will introduce different software stacks and development processes for RFSoC PS development from a high-level perspective.1. Software StacksWhen developing systems for RFSoC PS, it is essential to choose the appropriate software stack to meet design requirements. A software stack refers to a set of foundational software layers upon which developers can add application layer software to build the final system.By assessing whether the system:
- Has two or more concurrent functions
- Requires real-time operations
- Needs graphical interface or user interaction capabilities
Choosing the right software stack can significantly reduce development time and enhance reliability and user experience. Different software stacks have varying levels of abstraction. Low abstraction levels require developers to manage memory, I/O, peripherals, and other system resources directly. High abstraction levels provide a unified API to manage system resources but introduce additional memory overhead and latency. The subsequent content will introduce the optional software stack solutions for RFSoC SDR systems. Bare-Metal“Bare-metal” refers to program instructions executed directly on hardware without any operating system layer as an intermediate abstraction. This is the lowest level of software abstraction, where system resources must be managed entirely by the programmer. Software runs in a single-threaded manner and can optionally rely on interrupts to handle high-priority or urgent events.AMD supports bare-metal application development on its SoCs (including APU, RPU, and MicroBlaze processors) through the Vitis Unified Software Development Environment. The Standalone BSP (Board Support Package) provides key libraries for PS and PL peripherals, standard C libraries (libc and libm), as well as middleware libraries for file systems, encryption/decryption, networking, etc. The BSP offers a simple, single-threaded runtime environment for applications.Bare-metal is suitable for designs with simple requirements, such as software that only contains single-loop tasks or interrupt-driven routines. It is also suitable for scenarios where developers need fine control, such as performing low-level optimizations to achieve specific performance metrics (e.g., low latency, low power consumption). When applications become more complex, with more concurrent tasks, or do not require manual low-level optimizations, it is more appropriate to adopt a higher-level software stack. Real-Time Operating System (RTOS)RTOS is a higher level of software abstraction than bare-metal, providing a unified mechanism for task creation, scheduling, and system resource management. RTOS has deterministic scheduling capabilities, ensuring that critical tasks are executed within a predictable time window after events or interrupts occur.Unlike complete operating systems (like Linux), RTOS libraries are linked with the application program at compile time into a single executable file and run directly after power-up. Most RTOS do not support dynamically loading or unloading code at runtime.AMD provides an official open-source port of FreeRTOS suitable for its SoCs’ APU, RPU, and MicroBlaze. Additionally, third-party RTOS (such as Microsoft Azure RTOS, Zephyr Project) also provide examples or porting solutions for some AMD SoC boards. Linux OSLinux is a free and open-source operating system kernel, originally created by Linus Torvalds in 1991. The kernel is one of the first programs loaded at system startup, providing a unified, architecture-independent API for managing system hardware resources, including memory, processes, network interfaces, and storage devices. GNU/Linux distributions (commonly referred to as Linux OS) are general-purpose operating systems composed of the Linux kernel and a large number of system tools and libraries, many of which come from the GNU project. Linux can run on various processor architectures, such as x86 commonly used in desktops and servers, as well as the Arm architecture used in RFSoC.Linux is the highest level of abstraction in the described software stack, where user applications run in user space and communicate with the kernel through the System Call Interface to access hardware resources. Typically, developers do not need to directly manipulate system calls, as most applications use higher-level libraries like glibc or musl. The separation of user space and kernel space ensures that applications safely access shared resources. Linux provides a rich set of system APIs, including file systems, networking, inter-process communication, etc., allowing developers to focus on business logic without manually managing system resources.By default, Linux provides a Completely Fair Scheduler (CFS), which fairly allocates CPU time to all applications based on the total number of runnable processes and the time these processes have been active. To achieve real-time functionality, other built-in scheduling algorithms can be used, or a real-time optimized alternative kernel can be switched to. Although real-time Linux is a good choice for many applications, it cannot achieve the determinism and hard real-time scheduling performance that dedicated bare-metal or RTOS implementations can provide due to the significant resource overhead required to run the operating system itself.2. Symmetric Multi-Processing (SMP) and Asymmetric Multi-Processing (AMP)Complex heterogeneous processing systems (such as the RFSoC processing system PS) support advanced deployment architectures for the software stacks mentioned above. The PS can be configured in two main operating modes: Symmetric Multi-Processing (SMP) and Asymmetric Multi-Processing (AMP). The specific descriptions of the two modes are as follows:
- SMP
In SMP mode, multiple processors are managed by a single instance of the operating system. The operating system handles most of the complex work of resource allocation and management, including core scheduling, cache coherence, load balancing, and peripheral interrupt handling. This mode only supports the Arm Cortex-A53 application processors in the PS.
- AMP
AMP systems consist of multiple central processors of the same or different architectures, each running its own program independently. Each core has its own address space and can choose to run or not run an operating system. Depending on design requirements, communication mechanisms can be configured between cores, or they can run completely independently. The AMP mode allows designers to mix bare-metal programs, real-time operating systems, and Linux operating systems within the same processing system, with each core in the PS running an independent software stack. For example, bare-metal programs or RTOS stacks can run on Arm Cortex-R cores to support critical task software, while other cores in the system (such as Arm Cortex-A application cores) can run user-facing software.