Multicore systems: heterogenous architectures – untangling the technology and terminology

Multicore continues to be a hot topic, as an ever-increasing number of embedded systems are designed with multiple CPUs – most commonly multiple cores on a chip. One of the challenges with understanding multicore is that the term actually covers a number of architectures and approaches to design. This is a topic that I have discussed somewhat before, but the increasing popularity of multicore and additional technology options make it a topic worth revisiting.

Figuring out the terminology is the first challenge …

For many people, the term “multicore” brings to mind the microprocessor chips used in most desktop computers and many tablets etc. These devices contain a number of identical CPU cores, which offer a tremendous amount of computing horsepower and the opportunity to parallelize certain operations. [They are correctly termed “homogeneous multicore”.] Their software architecture is normally Symmetrical Multi-Processing [SMP], which is managed with an appropriate version of the operating system – Windows, Linux or OS X – a single copy of which runs on all the CPUs.

SMP architecture has its uses in the world of embedded systems too, where a lot of computing power needs to be marshaled. Hence, there are SMP versions of a number of real time operating systems, including Nucleus from Mentor Embedded.

The other type of multicore hardware architecture is heterogeneous multicore, where the numerous cores have different architectures. This is particularly interesting to the embedded developer, as different CPU architectures may be particularly well suited to specific applications, enabling the system to be constructed in an optimal fashion. Because the CPU architectures are non-identical, the SMP software architecture is no longer possible and each CPU runs its own operating system [or may not have one at all] – this is termed Asymmetrical Multi-Processing [AMP]. Furthermore, each CPU’s operating system may be different. For example, some CPUs might run an RTOS, like Nucleus, whereas others, which are not required to perform real-time tasks, might run Linux.

There are various other facets of multicore design to think about:

• The AMP software architecture may also be utilized on a homogeneous multicore design.
• A complex system may run some combination of SMP and AMP; each cluster of CPUs running an SMP operating system looks somewhat like a single CPU, so can be part of an AMP system.
• With SMP, inter-CPU communication is taken care of by the operating system; with AMP, a suitable mechanism must be selected [VirtIO, rpmsg and MCAPI are possibilities].

With all this complexity, multicore design is very challenging and I think that there are two areas that come top of the list of headaches for the software developer of a multicore embedded system:

1. Configuration – Getting all the various parts – operating systems [RTOSes and others], inter-core communications, networking etc. – to work together is becoming exponentially more difficult as the number and variability of cores increases. Mentor Embedded’s announcement of an fully integrated solution for heterogeneous multicore should be very welcome.
2. Debugging – Although software developers are often in denial of the fact, much more time is spent debugging software than coding. Multithreaded code can be challenging to debug, as interactions between the apparently simultaneous threads of execution can result in very subtle bugs. With a multicore design, this kind of problem is exacerbated drastically by the actual simultaneous execution of multliple cores. A developer needs to have a view of the system as a whole, but also be able to zoom in to look at detailed problems. A web seminar is scheduled for 5 August, which looks at this topic. I, for one, look forward to attending. [The session will be available as an archive recording after the event.]