Hypervisors and frameworks in the multicore environment

Multicore is symptomatic of the way embedded systems are developing. SoCs with multiple processors and accelerators combined with support logic lead to reductions in bill-of-materials and power costs. But the complexity of the SoC architectures that are now in common use makes debugging more difficult and functional safety potentially more difficult to achieve.

One important aspect of the multicore SoCs aimed at embedded systems is that they employ almost without exception heterogeneous multiprocessing in one way or another. Even those that sport homogeneous multicore complexes will generally have one or more assistant processors and accelerators in a hybrid configuration. In a presentation at the recent Embedded World show and conference, Colin Walls, embedded software technologist at Siemens Digital Industry Software described what is needed to help manage that complexity. “We need paradigms to accommodate heterogeneous multiprocessing where the software reflects the asymmetry in the hardware,” Walls said.

The result is a variety of multiprocessing software architectures that include symmetric multiprocessing for homogeneous complexes and asymmetric multiprocessing for heterogeneous architectures. It is possible to have unsupervised multiprocessing, where each core has its own operating system and works cooperatively with the others. In practice, some supervision is going to be necessary to stop software on one core interfering with tasks running on another. This is where the decision needs to be made on what kind of framework is needed: one based on a hypervisor; one based on a multicore framework; or both.

Separation policies

The hypervisor can act as an SoC manager, supervising the operation of multiple operating systems running on the platform. Because hypervisors typically enforce memory and resource separation if an operating system on one core crashes it will not disrupt the others, making them important for applications that need security and safety guarantees.

There are downsides. Hypervisors incur a processing overhead as well as a code-size overhead. They also only run on homogeneous multicore complexes as the hypervisor code needs to be able to run on any of the cores in the complex.

A multicore framework on the other hand is designed to support heterogenous multiprocessors, providing services such as interprocessor communication. The overhead is lower than with a hypervisor, even supporting bare-metal code. The downside is that there is no built-in isolation between cores, unless the hardware provides some kind of separation support, and other software might be needed to manage system-wide resources such as I/O ports. A key standard for multicore frameworks is OpenAMP, which is used in implementations such as Mentor’s Embedded Multicore Framework.

Which one is best? It may be the case the system will wind up using both. A processor complex on a heterogenous multicore SoC may run a hypervisor while a multicore framework instance is used to support OpenAMP-compatible communications between each of the cores that need to talk to each other.

If SoC hardware can be used to enforce separation, it provides the ability to support, in combination with a multicore framework, mixed criticality systems. With hardware protection in use, one processor complex can be isolated from others. This makes it possible to certify that part of the system without having to take the others into account, which makes it easier to update those other parts without forcing the system to go into a recertification process.

“If you are going to use a hypervisor, makes sure it’s optimized for embedded,” Walls said, and the same goes for multicore frameworks.