Promo Web

What’s Best for Your Multicore Design—a Hypervisor or Multicore Framework?

Dec. 21, 2020
Multicore embedded systems generally need some overall supervisory software that provides control of boot order and inter-core communication and security. There are two main options: a hypervisor and a multicore framework.

What you’ll learn

  • Pros and cons of using a hypervisor.
  • Pros and cons of multicore frameworks.

Today’s multicore system-on-chip (SoC) hardware offers the promise of being able to pack more into your embedded project than ever before. Designers no longer have to segregate software domains into separate devices. Multicore processing clusters within the same device can lower bill-of-materials (BOM) costs and help shorten design times through tighter domain integration.

However, for more complex systems, it remains the task of the systems architect and software designers to correctly configure the application domains, keep important data separate and secure, and effectively manage how the overall system will communicate. One critical decision should be made early in the process: What’s the best domain manager for your multicore system? Is a hypervisor required, or is a multicore framework a better solution?

Multicore Systems

In a multicore SoC, facilitating functional segmentation of a project results in designs being configured as asymmetric multiprocessing (AMP) systems. An AMP system may be constructed from any combination of core architectures. All of the cores may be identical (homogeneous) or there may be a rich mixture of core types that includes conventional processing units as well as specialized cores; for example, (heterogeneous) digital signal processors (DSPs).

Each core executes independently in an AMP architecture, with or without an operating system. In addition, each core’s operating system may be selected on the basis of the required functionality.

An AMP design comes with unique challenges:

  • An inter-core communication facility is most likely required.
  • There may be safety/security issues that require the cores to be protected from one another.
  • Boot order—the sequence in which the software on each core starts—may be important to avoid synchronization and security issues.

Debugging the different workloads running on the potentially heterogeneous cores can be quite challenging.

Although the cores in an AMP system are independent, these challenges indicate that some overall control facility is necessary. Broadly there are two options:

  • Hypervisor: A complex software component that runs across all the cores.
  • Multicore framework: A software component that allows enablement for AMP systems, which runs on each core.

It should be noted that multicore applications can be implemented using a symmetric multiprocessing (SMP)-enabled operating system. However, that approach doesn’t allow for independent workloads to be executed on different cores, and it doesn’t support heterogeneous cores.


A hypervisor is a fairly complex, versatile software component that provides a supervisory capability over a number of operating systems, managing CPU access, peripheral access, inter-OS communications, and inter-OS security. A hypervisor may be used in a number of ways. For example, multiple operating systems can be run on a single CPU to protect an investment in legacy software. But, with the growth of multicore processors, this is becoming rarer.

Alternatively, hypervisors can be used in embedded applications in AMP designs, where supervision of inter-core communication and allocation of peripherals to specific cores is needed. A hypervisor can also take care of the boot sequence and manage shared peripheral access.

One of the main advantages of using a hypervisor is that if an operating system “crashes,” it will not affect execution of workloads on other cores. In some cases, the hypervisor can even reboot that operating system without requiring a reboot of the device. It is, of course, very advisable to utilize a hypervisor that’s specifically designed for use in embedded applications for better performance.

Although it’s possible to develop a hypervisor that will enable all of the required separation and virtualization features in software, it’s quite difficult and unusual these days. Today hypervisors are designed to use underlying virtualization features present on most multicore processors.

Pros and Cons of Hypervisors

Hypervisors have advantages and disadvantages compared with other solutions.


  • Great flexibility enables efficient resource sharing, dynamic resource usage, low latency, and high-bandwidth communication between virtual machines (VMs)
  • Strong inter-core separation
  • Enables device virtualization and sharing
  • Ability to assign ownership of peripherals to specific cores


  • Only work on a homogenous multicore device (i.e., all cores are identical)
  • Significant code footprint
  • Some execution overhead
  • Require hardware virtualization enablement in the processor

Multicore Frameworks

Because of their separation, management, and sharing capabilities, hypervisors have far more functionality than many embedded designs demand—and they can be overkill. To address this issue, a few embedded runtime vendors developed an alternative that was specifically engineered to support an AMP multicore system: the multicore framework.

Frameworks are designed very specifically to support the multicore application, providing just the key functionality: boot order control and inter-core communications. The result is that a framework loads a system with a much lower overhead and can be run on much more basic systems. Although each core in an AMP design probably runs an operating system, 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 (IPC)

Once the remote processor OS and application stack are running, many use cases will require communication with other parts of the system. The Mentor Embedded Multicore Framework provides a clean-room implementation of a remote processor messaging framework feature called rpmsg to establish a communications channel between the master operating system and the remote operating systems. In this way, data can be passed back and forth between the two in an inter-processor communication channel.

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

Remote Processor Lifecycle Management

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

The remoteproc feature within the Mentor Embedded Multicore Framework enables remote processor interoperability between Mentor Embedded Linux, Nucleus RTOS, and Bare Metal Environments (BME) and Linux and RTOS products from other vendors. A key benefit to remote processor lifecycle management is reduced 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.

Pros and Cons of Multicore Frameworks

Multicore frameworks have advantages and disadvantages compared with other solutions.


  • Provides the minimally required functionality for some applications
  • Modest memory footprint
  • Minimal execution time overhead
  • Can work on heterogeneous multicore devices (i.e., all cores needn’t be identical)
  • Support bare-metal applications


  • The core workloads aren’t isolated from each other
  • Can be more difficult to control boot sequence, and to debug


Although some multicore frameworks are proprietary, some standards have been proposed that govern their functionality, interfaces, etc. A popular example of such a standard is OpenAMP.

There are two key functionalities in OpenAMP:

  1. Lifecycle management using remoteproc. This facilitates control of boot order, etc.
  2. Inter-core communications using RPMsg.

A current reference implementation of the OpenAMP standard is available on GitHub. Mentor Embedded Multicore Framework (MEMF) and Mentor Embedded Multicore Framework Cert 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 (Fig. 1).

Mixed Safety-Criticality Systems

A mixed safety-critical system is a system that requires the execution of several applications of different safety integrity levels (SILs) or different criticalities, such as 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 does this by certifying the hypervisor itself.  The virtual machines can then have different criticality levels running with the certified hypervisor. The separation is provided by the certified hypervisor, 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 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. It also provides interrupt throttling and polling mode to prevent interrupt flooding. It’s even possible to use a non-safety certified hypervisor along with a mixed criticality-enabled multicore framework (Fig. 2).


Deciding to use a hypervisor or a multicore framework, or both, to control and manage a multicore system is a critical architecture decision. The final choice will depend on the specific application requirements and the use case for the device. The options should be considered as complementary solutions that can unlock the power of a multicore SoC, enabling the management of the various project domains, and ultimately allowing designers to focus on the unique IP of their projects.

Jeff Hancock is a Senior Product Manager for Mentor Embedded Platform Solutions, Siemens Digital Industries Software.

Sponsored Recommendations


To join the conversation, and become an exclusive member of Electronic Design, create an account today!