How to choose between a hypervisor and a multicore framework

By Jeff Hancock |  No Comments  |  Posted: September 28, 2020
Topics/Categories: Embedded - Architecture & Design, - Embedded Topics  |  Tags: , , , , , , , , ,  | Organizations:

Jeff Hancock is a Senior Product Manager in the Embedded Platform Technology Business Unit of Mentor, A Siemens Business. He oversees the Nucleus and Mentor Embedded Hypervisor runtime product lines, as well as associated middleware and professional services.Jeff Hancock is a Senior Product Manager for the Embedded Platform Solutions group at Siemens Digital Industries Software. He oversees the Nucleus real-time operating system and Hypervisor runtime product lines, as well as associated middleware and professional services. Over the last 20 years, Jeff has held numerous roles in the embedded space. Jeff earned his Bachelor of Science degree in Electrical Engineering Technology from Purdue University.

With the increasing adoption of multicore to embedded devices, key decisions are required to ensure an optimal design. For the overall control and management of a multicore system, which is better: a hypervisor or a multicore framework?

Multicore systems

There are several reasons for implementing an embedded system using multiple cores. You may simply want to attain more processing power but the most likely involves the functional segmentation of a design configured for asymmetric multiprocessing (AMP).

An AMP system can be constructed from any combination of core architectures; all the cores may be identical or it can comprise a mixture of core types that includes conventional processing units and specialized ones (e.g., DSPs). Each core executes independently in an AMP architecture, with or without an operating system (OS), and is selected based on the required functionality.

Here are four specific AMP design challenges:

  • The design will most likely require inter-core communication.
  • Safety and security issues may require the cores to be protected from one another.
  • The boot order – the sequence in which the software on each core starts – will need to to avoid synchronization and security issues.
  • There are the issues posed by debugging disparate workloads often running on heterogeneous cores.

Cores in an AMP system are independent, but these challenges require some overall control facility. There are two options:

  • A hypervisor: A complex software component that runs across all the cores; or
  • A multicore framework: A software component enabling AMP systems to run on each core.

Note that multicore applications can be implemented using a symmetric multiprocessing (SMP)-enabled OS. Still, it does not allow for independent workloads to be executed on different cores or support heterogeneous cores.


A hypervisor is a reasonably complex, versatile software component that provides a supervisory capability over several OSes, managing CPU access, peripheral access, inter-OS communications, and inter-OS security. With a hypervisor, multiple OSes can run on a single CPU to protect investments in legacy software, but the growth of multicore processors is making this rarer.

Alternatively, hypervisors can be used in embedded applications in AMP designs that need the supervision of inter-core communication and the allocation of peripherals to specific cores. A hypervisor can also take care of the boot sequence and manage shared peripheral access. The main advantage of a hypervisor is that if an OS crashes, it will not affect the execution of workloads on other cores; the hypervisor can even reboot the OS without requiring a device reboot.  It is advisable to utilize a hypervisor that is specifically designed for embedded applications to ensure better performance.

Although it is possible to develop a hypervisor to enable all of the required separation and virtualization features in software, it is quite tricky and unusual today.  Hypervisors are now designed to use underlying virtualization features on most multicore processors.

Hypervisors – Pros & Cons


  • Great flexibility enables efficient resource sharing, dynamic resource usage, low latency, and high bandwidth communication between VMs;
  • Strong inter-core separation;
  • Enabling device virtualization and sharing; and
  • Assigning ownership of peripherals to specific cores.


  • Only works on homogenous multicore devices (i.e., all the cores are identical);
  • Significant code footprint;
  • Some execution overhead; and
  • Needs hardware virtualization enablement in the processor

Multicore frameworks

Because of their separation, management, and sharing capabilities, hypervisors provide more functionality than many embedded designs demand – they can be overkill. Thus, a few embedded runtime vendors developed an alternative specifically engineered to support an AMP multicore system: the multicore framework.

Frameworks are designed very specifically to support the multicore application, providing just the critical functionality: boot order control and inter-core communications. The framework loads a system with much lower overhead and can run on much more basic systems. Although each core in an AMP design probably runs an OS, one or more cores may be bare metal (i.e., running no OS at all). A multicore framework can accommodate this possibility.

Inter-processor communication

Once the remote processor OS and application stack is running, many use-cases will require communication with other parts of the system. The Mentor Embedded Multicore Framework (MEMF) provides a cleanroom implementation of a remote processor messaging framework feature (RPMsg) that establishes a communications channel between the master OS and the remote OSes. Thus, data can be passed back and forth between the two in an inter-processor communication (IPC) channel.

The transport layer that enables both remote processor lifecycle management and IPC is VirtIO, a virtualization standard for high-performance input/output device drivers widely adopted in virtualized Linux environments.

Remote processor life cycle management

Assuming control over a remote processor, and then starting or stopping an OS and/or application stack within that remote processor is known as remote processor (remoteproc) lifecycle management. The Linux community has adopted a framework for managing this scenario. Remoteproc allows a principal OS to bring up other OSes on other cores.

The remoteproc feature within the Mentor Embedded Multicore Framework allows remote processor interoperability between Mentor Embedded Linux, Nucleus RTOS, and Bare Metal Environments (BME), as well as Linux and RTOS products from other vendors. A key benefit of remoteproc lifecycle management is that it reduces power consumption. The remote core stays in a low power state when not in use. Only after remoteproc is used to bring up the remote core and deploy the necessary firmware does the remote core draw any notable power.

Multicore frameworks – pros & cons


  • Provide the minimally required functionality for some applications;
  • Modest memory footprint;
  • Minimal execution time overhead;
  • Work on heterogeneous multicore devices (i.e., all cores do not need to be identical); and
  • Support bare metal applications.


  • Core workloads are not isolated from each other;
  • More difficult to control the boot sequence; and
  • More difficult to debug.


Although some multicore frameworks are proprietary, some standards have been proposed that govern their functionality, interfaces, and other relevant components. OpenAMP is a well known example and two of its key functionalities are:

  • Life cycle management using remoteproc to facilitate control of the boot order etc; and
  • Inter-core communications using RPMsg.

A current reference implementation of the OpenAMP standard is available on GitHub. The Mentor Embedded Multicore Framework (MEMF) and MEMF Cert products are proprietary implementations of the OpenAMP standard. Extensions to the standard include additional functionality to support Linux as a Remote, Large Buffer, Zero Copy, Proxy support for Ethernet, and additional development tools.

Mixed safety-criticality systems

A mixed safety-critical system is one that requires the execution of several applications of different safety-integrity levels (SILs) or different criticalities (e.g., safety-critical and non-safety critical) on a single SoC. Both a hypervisor and a multicore framework can support this type of configuration.

A hypervisor can certify the hypervisor itself.  Virtual machines can then have different criticality levels running with the certified hypervisor.  The certified hypervisor provides separation, which typically uses underlying hardware virtualization and separation features on the SoC.

A multicore framework leverages other hardware-assisted separation capabilities provided by some SoC architectures to obtain the required separation between the safe domain and the non-safe domain. This includes the separation of processing blocks, memory blocks, peripherals, and system functions.  The multicore framework provides enhanced bound checking to ensure the integrity of shared memory data structures, plus interrupt throttling and polling mode to prevent interrupt flooding. You can use a non-safety certified hypervisor along with a mixed-criticality enabled multicore framework (Figure 1).

Figure 1. Combining a multicore framework and a hypervisor (Mentor)

Figure 1. Combining a multicore framework and a hypervisor (Mentor)


Using a hypervisor or a multicore framework – or both – to control and manage a multicore system is a critical architecture decision.  It will ultimately depend on the specific application requirements and the use-case for the device. The options should be considered as complementary solutions to unlock the power of a multicore SoC. The availability and understanding of these choices allow the designer to achieve a more optimal multicore design.



Comments are closed.


Synopsys Cadence Design Systems Siemens EDA
View All Sponsors