Work by the Multicore Association (MCA) to provide a standard way for applications running on different processors to communicate with each other is leading to active implementations.
Launched at the start of the year, the MCA’s OpenAMP group is developing a number of standards to manage resources and streamline communication between applications that run on different operating systems. Some may be implemented on top of Linux; others run on one of the many different forms of RTOS available. Many systems will have both.
Tomas Evensen, embedded software CTO at Xilinx and chair of the Multicore Association’s OpenAMP working group, points to a likely architecture for gateway devices on the internet of things (IoT): “People using our devices in these spaces have real-time needs but they have to connect to services running in the cloud using Microsoft Azure or Amazon. They don’t want to use an RTOS for handing those communications. They want to use Linux for that.”
Having borrowed an interprocessor communications (IPC) model developed by the Linux community, the OpenAMP group is developing reference implementations that take advantage of zero-copy techniques as well as documentation to support adopters.
“OpenAMP is two different things. As well as an open-source project it is a standardization effort. Sometimes it’s hard to keep them apart. But we try to make sure we have a standardization effort that allows for independent implementation. There will be implementations that need to be safety certified; some will be designed to run under a hypervisor. The standard is there to ensure that they are compatible with each other,” Evensen says.
“The API is based on
rproc that are already in Linux. We are adding clarifications to the standard but also adding extensions like zero copy. There is also a third layer that we are starting to discuss: a lower level interface. How that abstracts the underlying OS and make sure that it’s easy to port from one OS platform to another.”
In contrast to other standards work, the group is keen not to reinvent the wheel. “A lot of things we are working with are standardized in other places, such as
virtio [paravirtualization driver interface]. We are creating an architectural document so that anyone can read the document and do an implementation. It will have pointers to where those things are defined rather than trying to restandardize them. The other component will be the document were we standardize things people haven’t worked on before,” Evensen adds.
The group is building cleanroom implementations of the core IPC code, supplying the modules under a BSD license. This is intended to avoid the problems for embedded developers associated with the Gnu General Public License (GPL) used for Linux. The GPL demands developers make publicly available their own improvements and linked code.
Mentor Graphics has built several reference designs around OpenAMP, says Felix Baum, the company’s embedded virtualization product manager: “We have built an ethernet switch. Another is a shared graphics virtualisation framework, where you can have two or more cores sharing a GPU. You might have screens in a car dashboard that you want to be shared. One half may be owned by a subsystem running Android; the other half by Linux. Then at the top and bottom you show status information like battery level and signal strength. That’s controlled by an RTOS perhaps. We have real customers using that kind of framework.”
The group is keen to ensure that SoC implementations can take advantage of hardware features, although the APIs are designed to work on systems that only have shared memory for relaying messages between processors.
“What happens under the hood is up to each vendor. If they have a fast [onchip network] fabric they can use that. Shared memory instead? They can use that. Any silicon goodness they have they can use for optimization,” Evensen says.
Baum sees the rise of intelligent sensor systems in cars as being a driver for OpenAMP adoption: “One of the biggest pushes is in automotive. They are consolidating processing for ADAS and bringing in and running multiple pieces of software on SoCs. One core may be used for sensor fusion and handles communication with ECUs, for example. All these pieces that used to run on distinct CPUs are now running on one SoC.
Evensen adds: “From a Xilinx point of view, our partners are using this across a lot of different markets. Sometimes they are using stuff and they don’t realize it’s OpenAMP: they just see a library. Adoption is in automotive and ADAS: that’s one of the bigger markets for us. But it’s also in telecom, and aerospace/defense.”