No, OpenAMP is not some community project to design the next guitar amplifier. Instead, it stands for Open Asymmetric Multi-Processing, an open source framework that provides software tools for developing applications in systems with multiple processors.
The framework is maintained by the OpenAMP project, which includes members from companies such as Xilinx, ARM, Linaro, STMicroelectronics, Texas Instruments, Nordic Semiconductor, and Wind River. Within the Xilinx ecosystem, OpenAMP is supported on both the Zynq-7000 SoC and Zynq UltraScale+ MPSoC.
First off, you may be wondering, what exactly is Asymmetric Multi-Processing (AMP)? A computer system is considered asymmetric when it contains multiple processors and not all of them are “treated equally.” Typically, this means that there is no single unified operating system or task scheduler managing all processing resources in the system. This is the compliment of Symmetric Multi-Processing (SMP), where a single operating, such as Linux, is responsible for scheduling tasks across all processors. AMP is commonly applied in heterogenous System-on-Chip (SoC) platforms, where there is a mixture of application and real time processors.
The OpenAMP framework is built upon a foundation known as libmetal. The libmetal library provides an abstraction layer that hides the details of the underlying operating system or processor architecture. This enables the OpenAMP library to be portable across platforms such as Linux, FreeRTOS, and baremetal. It also provides the benefit of allowing your applications and libraries to be portable as well.
There are three important components of the OpenAMP framework that you should be aware of. They are virtio, rpmsg, and remoteproc.
Back to the question at hand, why should you consider asymmetric computing? And why should you use OpenAMP? While general purpose application processors are more powerful than ever, they are not well suited for many real-time applications. Moreover, general-purpose operating systems such as Linux were not specifically designed for correctness and determinism; a no-go in applications with stringent safety or security requirements. But these operating systems bring a large complement of capabilities and libraries that cut down significantly on product development time; for example, a full networking stack or graphical user interface library.
Heterogenous computing provides the convenient middle ground, where critical code is segregated to dedicated processors, giving you the benefits of both worlds. However, segregating your design like this comes with the problem of how to mesh your applications together across processors and operating systems. Such a design would use interfaces that are above and beyond what most operating systems APIs provide, requiring you to develop a custom implementation. This is where OpenAMP comes in, providing an established framework for AMP lifecycle management and the exchange of data between processors.
Out of the box, OpenAMP is supported on Linux, FreeRTOS, and baremetal platforms. Additionally, DornerWorks has previously demonstrated OpenAMP working on both the seL4 microkernel and Xen hypervisor.
Let’s use an example to demonstrate how OpenAMP could be used in an application.
Say we want to implement a networked industrial robotic controller on the Xilinx Zynq UltraScale+ MPSoC, which contains a quad core Cortex A53 Application Processor Unit (APU) and a two Cortex-R5 Real-time Processor Units (RPU). We could split the application design so that real-time motion control of the robot arm runs on the RPU with FreeRTOS, as this application must meet hard deadlines for control and safety protections to prevent harm to people and equipment. We can then use Linux on the APU to take advantage of a fully featured network stack and accelerate development efforts while minimizing the scope of the safety and real-time requirements.
In this design, Linux will boot up first on the APU. We could develop a Linux application named “robot-control” responsible for managing the remote processor, receiving network traffic, and generating coarse position coordinates. This application could use the remoteproc APIs during initialization to read a firmware file from the filesystem, load it into memory, and kick off the RPU. This design makes updating the RPU firmware simple, as it is a matter of updating a file on the Linux filesystem.
For our system, we will need two data paths between the robot-control and RPU applications. The first is a virtio device that streams the position coordinates from the robot-control application to the RPU application. The robot-control application can buffer several seconds worth of this position data to smooth out any jitter from the network or Linux kernel and guarantee the buffer is never empty. The RPU application can then read one coordinate at a time from the virtio stream in real-time and perform its motion control algorithm.
The second data path could be an event and control channel for asynchronous messaging both ways between the robot-control and RPU applications. This would enable the robot-control application to send control messages to the RPU application such as start, stop, set/get configuration, and poll status. It would also enable the RPU to issue asynchronous events to the robot-control application such as run state changes and fault codes.
This design goes a long way to separating critical and non-critical code and minimize development efforts. However, alone it does not guarantee isolation of these two components. For instance, it is possible for a critical flaw or vulnerability in the Linux kernel to cause it to interfere with the RPU application, such as overwriting memory. This is where SoC architecture can help; for instance, the Xilinx Zynq UltraScale+ MPSoC provides several features to provide hardware isolation.
OpenAMP is open source and free to use under the BSD 2 or 3 clause license, making it an easy choice for your application. However, it is just one piece of the puzzle for AMP – to ensure that your design is meeting critical safety or security requirements requires full understanding of the SoC architecture. This is where DornerWorks comes in, with extensive experience in SoC architectures such as the Xilinx Zynq UltraScale+ MPSoC to guide you to a stronger business.
Contact us today and schedule a free meeting.
