As an ever-increasing number of embedded systems are designed with multiple CPUs – most commonly multiple cores on a chip – multicore design continues to be a hot topic. A challenge with understanding multicore is that the term is used widely to describe a number of design approaches and architectures. Some clarity is needed.

Figuring out the terminology is the first challenge ...

The term “multicore” brings to the mind of many people the microprocessor chips used in desktop computers, tablets, smartphones, etc. These devices are constructed with a number (sometimes a large number!) of identical CPUs and these provide enormous computing power and the opportunity to run parallel algorithms, which is greatly beneficial for certain applications. These devices are correctly termed “homogeneous multicore,” as all the CPUs are identical. The architecture of the software is Symmetrical Multi-Processing (SMP), which is implemented by running the operating system – Windows, Linux or MacOS – across all the CPUs. (A single copy of the OS is employed.)

In embedded systems, SMP has a place too. It is used where a lot of computing power needs to be available in an economic and power-efficient configuration. As a result, SMP versions of a number of real-time operating systems are available.

Predictably, the alternative multicore architecture to homogeneous is heterogeneous, where the various cores have different architectures. This is attractive to the embedded systems developer, as the CPUs may be deployed to the parts of an application for which they are best suited. The software architecture of such a system is necessarily Asymmetrical Multi-Processing (AMP), where each CPU runs its own OS (or maybe no OS at all). This means that different operating systems may be deployed of each CPU, as appropriate. For example, some CPUs might run an RTOS, whereas others, considering real-time behavior is not required, might run Linux.

Some further facets of multicore designs:

• You can implement AMP on a homogeneous multicore device, if required.
• In a complex system, there may be a combination of SMP and AMP. As a cluster of CPUs running SMP looks somewhat like a single CPU, it can be part of an AMP system.
• An AMP design approach provides a great opportunity to segment the software in various ways. Not only can real-time and other software be separated, but safety-critical software components can be readily separated (and protected) from other software sub-systems.
• Inter-CPU communications in an SMP system is accommodated by the OS; normal inter-task communications can be used. For an AMP system, a suitable mechanism and protocol need to be chosen.

Multicore system design is challenging, and I would identify two areas as being particularly troublesome:

1. Configuration – Building a system involves getting all the parts – OS, inter-core communications, etc. – playing together nicely. As the variety of cores becomes wider, this challenge is becoming more critical. A good approach is to consider some heterogeneous multicore infrastructural software – a framework or hypervisor – that provides well-proven “glue.”
2. Debugging – Typically, more time is spent debugging than coding (even if developers would deny this!). If you use an RTOS, debugging multi-threaded code is tough, as the interactions between apparently simultaneously executing threads is subtle. In a multicore system, where there is true simultaneity, it just gets worse. Traditional “stop and stare” debugging does not hack it. More sophisticated tools are needed that capture the operation of a complete system and enable the developer to zoom in to look at detail, as needed.

There is no doubt that multicore will soon move from being common to ubiquitous. The design and development challenges will remain and recognizing new ways to think and approach problems are needed.