Multicore processors (processors with multiple processing cores) are being considered in more embedded designs. There are in general two drivers that are bringing people to  multicore: performance and/or consolidation.

The performance driver is simple. Many devices need the best performance in the smallest package with the lowest power demands. A multicore processor provides more MIPS per Watt than a single core processor. In 'the old days' performance could be improved by increasing the processing frequency on the processor, but for many designs this is no longer the case. The networking industry especially has been ahead of the rest of the pack in the migration to multicore. 

The consolidation driver covers the fact that a (for example) dual core can be used as two single core processors. This means that an old dual processor board or perhaps a dual card rack with one processed per card can be replaced by a single processor with multiple cores. This saves board space, reduces the bill of material and reduces power consumption. Besides consolidating existing processors into a single package, the multicore processor also provides the option of using one or more of the cores to add new functionality to an already existing design.

Much has been said about the fact that multicore processors are more difficult to develop software for than single core processors. Software needs to be able to benefit from the multiple cores and hence needs to be written for a parallel, rather than a serial execution model. Most of these articles talk about the programming problem, very few talk about how to configure multicore processors.

However, SMP is not the only way to configure a multicore system, AMP (Asymmetric MultiProcessing) is also an option where every core runs its own copy of an operating system and each core can be independently restarted if needed. The operating systems in an AMP system can potentially be different, such as different operating systems (VxWorks vs Linux) or different versions of the same operating system (different Linux kernel versions for example). Each core has its own designated memory and each device is typically owned by one of the cores.

There are two main challenges with AMP: 1) the setup is completely manual, so you need detailed knowledge of the processor and the operating system to configure the system, 2) there is no protection, so the software on core 0 can interfere with the memory of core 1. Luckily there is another technology that comes to the rescue here: virtualization.

Virtualization technology abstracts memory, devices and processing cores and partitions the physical hardware in multiple different virtual machines. Virtualization can abstract memory, devices, and processing cores, depending on what is needed for a particular system. Memory and device virtualization can make the configuration of an AMP system easier, virtualization in this case partitions the hardware and provides supervision of the operating systems to make sure they adhere to this partitioning - this is also referred to as 'Supervised AMP'. The virtualization layer is called 'the supervisor' and it provides basic partitioning functionality and then gets out of the way so the software can run at maximum efficiency.

Virtualization of processing cores is something that has become popular in IT (Information Technology) environments, but is also applicable to the embedded industry. It allows a single core to be configured with more than one operating system, every operating system executing in its own virtual machine. This can be used for example to run a real-time operating system (such as VxWorks) for real-time behavior alongside a general purpose operating system (such as Linux) for networking or user-interface content. This virtualization layer is called 'the hypervisor' and it provides scheduling functionalities of the virtual machines on the core, on top of the memory and device virtualization that the supervisor provides.

Both the hypervisor and the supervisor use the same technology, just configured differently. They also need to provide their capabilities as efficiently as possible, which means low latency, determinism, and small footprint - we are building embedded systems after all.

Performance is a key concern in embedded systems. Early usage of these technologies has shown that the performance impact is low, if measurable at all and easily outweighs the benefits provided.

Put SMP, AMP, sAMP, and virtualization together are the primary software configurations (see figure). Traditional single OS on a single core, hypervised with multiple virtual machine on a single core, multicore with SMP and multicore with supervised AMP. 

Of course these configurations can be combined, for example say you have an 8 core system (such as a 2 Intel Nehalem parts), you can use core 1 and 2 to run Linux in SMP for a control application; use core 3 through 7 to run VxWorks in AMP for data processing, and use core 8 as a watchdog - but since the watchdog will not require a full core, it can be combined via the operating system to support more data processing through core virtualization.

The introduction of multicore and virtualization has provided software developers with an additional set of parameters to work with when building their next generation of embedded systems. The logical layer (the definitions of the virtual machines) can be completely de-coupled from the physical layer (the processor with its cores). This provides the development team with additional flexibility while trying to achieve their time-to-market, cost, re-use, quality and similar targets.

In a follow up post I will look at some example situations as to how virtualization and multicore are being used today to build the embedded systems of tomorrow.

- Mark Hermeling, Senior Product Manager, Wind River Systems

If you missed the previous guest post on multiprocessing, check out what Alan Gatherer from Texas Instruments had to say when considering multicore.