Multicore System-on-Chip (SoC) – Now What?

A quick Q&A with Jeff Hancock, senior product manager for Mentor Embedded Platform Solutions, Siemens Digital Industries Software. Jeff oversees the Nucleus® real-time operating system (RTOS) and Mentor Embedded 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.  Prior to joining Mentor in 2018, Jeff was a product manager at Renesas.  Before that he served as a product line manager at Wind River Systems, where he oversaw the entire Workbench Product Line, Helix App Cloud Development environment and the Build and Configuration for the VxWorks embedded operating system. Jeff earned his Bachelor of Science degree in Electrical Engineering Technology from the Purdue University.

Q1: So my first question is, what are the main pros and cons of using a hypervisor or a multicore framework?
A hypervisor is a reasonably complex, versatile software component that provides a supervisory capability over several operating systems, managing CPU access, peripheral access, inter-OS communications, and inter-OS security. A hypervisor may be used in many ways. For example, multiple operating systems may be run on a single CPU to protect an investment in legacy software, although with the growth of multicore processors, this is becoming rarer.

Hypervisors have advantages and disadvantages compared with other solutions.

Advantages

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

Disadvantages

• 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 are designed very specifically to support the multicore application, providing just the critical functionality: boot order control and inter-core communications. The result is that a multicore framework loads a system with 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.

Multicore frameworks have advantages and disadvantages compared with other solutions.

Advantages

• 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 do not need to be identical)
• Support bare metal applications

Disadvantages

• The core workloads are not isolated from each other
• It can be more challenging to control boot sequence and to debug

Q2: Okay, so why would you choose one over the other?
If the specific application is just a consolidation of existing systems onto a single device or the application requires multiple operating systems to virtualize different peripherals, then a hypervisor is a good choice. If the device utilizes heterogeneous processor cores of the SoC, or the device has a mixed safety-criticality requirement, then a multicore framework is a better choice. In the end, the final decision will depend on the specific application requirements and the use case for the device.

Q3/Q4: How can you leverage heterogeneous multicore SoCs when there is a functional safety requirement? What isolation methods can I use to separate my runtime environments in a multicore system?
In the past, to meet the functional safety requirement users would have to create different hardware systems, or certify the entire system (including the parts that did not impact safety functions). Now users can take advantage of the features of the heterogeneous multicore SoC to separate the safe world from the unsafe world and establish communication by a certified framework. This results in lower hardware and certification costs.

A multicore framework leverages other hardware-assisted separation capabilities provided by some SoC architectures to obtain the required separation between the safe and non-safe domains. 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 is even possible to use a non-safety certified hypervisor, and a mixed safety-criticality enabled multicore framework.

Q5: Are there any performance reductions or improvements in using either method?
It is not logical to think in terms of performance reduction; a clearer concept is the amount of overhead introduced by a hypervisor or multicore framework. Although it can never be zero, a hypervisor, being quite a small piece of software, need not introduce much overhead at all when managing guest operating systems running on multiple cores. An area where performance may be a consideration is hardware access. If the hypervisor is used to virtualize devices, the overhead will be introduced.  Since the operating systems run directly on the cores, the execution time overhead is minimal.