Multicore embedded designs are becoming increasingly common. Faced with this technology for the first time, a developer is bombarded with terminology. Understanding the alphabet soup that describes this technology is essential to ensure that an optimal design is achieved. This article systematically defines many of the key terms and puts them into context.
Here are some, at least, of the key terms that are used in multicore discussion:
- Multicore system
- Homogeneous multicore
- Heterogeneous multicore
- Bare metal
- Asymmetric Multiprocessing (AMP)
- Symmetric Multiprocessing (SMP)
- Inter-core communication
- Boot order
- Life cycle management
- Device virtualization
- Multicore framework
- Mixed criticality
There are probably more terms, but a working understanding of these would be a great start for a developer new to the field. The rest of this article is a series of definitions of these terms and how they link together.
A processor of some kind – something that can execute code – on a system-on-chip (SoC) device. This may be a conventional CPU, or it could be a specialized processor like a Graphics Processor Unit (GPU) or Digital Signal Processor (DSP). A Microcontroller Unit (MCU) is a possibility, where the CPU has its own localized memory and peripherals. On an FPGA a soft core may be employed.
An embedded system that has multiple processor cores. This might be multiple boards in a system, or multiple chips on a board, but most commonly this term is used to describe a chip containing multiple processors. This may be system-on-chip (SoC) device or it could be an FPGA on which multiple soft cores are instantiated (or the FPGA may have some “hard” cores embedded within the fabric).
This is a hardware architecture. A multicore system where all the cores are identical. It is possible that this term may be used where the cores are all from the same family and are almost identical. This may be applicable to customizable cores like RISC-V.
This is a hardware architecture. A multicore system where the cores are not all identical. The cores may be slightly different from one another or radically so. There may be a mix of regular CPUs, DSPs and/or GPUs or other specialized devices. Within the mix of cores there may be several that are identical; this can be thought of as a homogeneous multicore within the heterogeneous environment and this has implications on the software architecture.
Heterogeneous multicore is the most common hardware architecture employed in embedded applications.
A term that describes a core in a multicore system that is not utilizing an operating system.
Asymmetric Multiprocessing (AMP)
This is a software architecture. Each core runs its own operating system or maybe no OS at all (this is termed bare metal). The OSes may be selected so that each one is optimal for the required functionality of the core. Additional software components are needed to facilitate overall control of the device and inter-core communications; this may be a hypervisor or a multicore framework.
AMP is the most common software architecture employed in embedded applications.
Symmetric Multiprocessing (SMP)
This is a software architecture. A single instance of an operating system (which needs to be a specific variant with SMP support) runs across multiple cores. The OS manages distribution of work between the cores. The application code need not be specially written for the SMP context. The main reason for utilizing this architecture is to maximize computing power while minimizing energy use. A group of cores may constitute an SMP subsystem within an AMP design.
In a multithreaded system, tasks commonly need to communicate to exchange data or synchronization; in a multicore environment this communication may be between cores. With an AMP system, some specific support for communication is needed – typically utilizing rpmsg. This capability is generally accommodated using a hypervisor or a multicore framework. With an SMP system, the operating system facilitates communication between tasks using regular service calls.
An AMP system, with any level of non-trivial complexity, is very likely to need some control over the sequence of cores booting. Normally, one core would be the master of the system. This capability is generally accommodated using a hypervisor or a multicore framework.
Life cycle management
The control of an AMP system may go beyond boot order and encompass the entire operation of the non-master cores. Their operation may be monitored, and they may be shut down or rebooted, as required.
A facility provided by a hypervisor that enables the application software to use a device which is actually shared between multiple cores, without the code being modified to accommodate the sharing.
A software component that, in a multicore system, runs across multiple cores and provides control and inter-core communication services. A hypervisor can only run across identical cores – i.e. it must be a homogeneous multicore device. The cores must also be running an operating system of some kind.
An alternative software component to a hypervisor that provides similar capabilities but is lighter weight. A multicore framework has an instance on each core, so they do not need to be of the same architecture – i.e. it can be a heterogeneous multicore device. An underlying operating system is also not essential – i.e. a multicore framework may run on bare metal.
This is an implementation of device virtualization that is normally applied to networking and storage.
Remote Processor Messaging is a bus/API that facilitates communication between cores.
An open standard that guides the implementation of a multicore framework. See: https://www.openampproject.org
A system where some components have safety/security implications and require certification. In various industries, devices that present safety or security issues must comply with specific standards and get that compliance certified. This is an expensive process. By partitioning a design into critical and non-critical subsystems, the costs may be reduced by only certifying the critical subsystem. Such a design is said to exhibit mixed criticality.
|Colin Walls has over forty years’ experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, Colin is an embedded software technologist with Mentor, a Siemens business, and is based in the UK. His regular blog is located at: https://blogs.sw.siemens.com/embedded-software/. He may be reached by email at firstname.lastname@example.org.|