With multicore embedded systems becoming so common, this article outlines some of the basics, reviewing the possible hardware architectures. Broadly, there are two options: Asymmetric Multi-Processing and Symmetric Multi-Processing. These are defined and the circumstances under which each may be selected are outlined, along with the implications to the embedded software engineer.

With multicore embedded systems becoming so common, this article outlines some of the basics, reviewing the possible hardware architectures. Broadly, there are two options: Asymmetric Multi-Processing and Symmetric Multi-Processing. These are defined and the circumstances under which each may be selected are outlined, along with the implications to the embedded software engineer.

Multicore designs

It is becoming common for embedded designs to incorporate more than one CPU – maybe multiple cores on a chip or multiple chips on a board or any combination of these. Indeed, it has been suggested that it will soon be the norm to build systems that way.

From a hardware perspective, there are broadly two types of multicore design. If all the CPUs have exactly the same architecture, it is termed homogeneous multicore; if there is variability in the architectures, it is heterogeneous multicore.

AMP and SMP

From the software perspective, the choice is between AMP and SMP. However this terminology can be confusing, so maybe I can set the record straight…

AMP stands for Asymmetric Multi-Processing ; SMP means Symmetric Multi-Processing . These terms are not at all transparent. So, I will try to advance modern working definitions.

Asymmetric Multicore – AMP

An AMP system has multiple CPUs, each of which may be a different architecture (but can be the same – i.e. may be either heterogeneous or homogeneous multicore). Each has its own address space (though some or all of the memory may be shared with other cores), and each may or may not run an OS (and the OSes need not be the same). Some kind of communication facility between the CPUs is provided for each.

AMP is most likely to be used when different CPU architectures are optimal for specific activities – like a DSP and an MCU. In an AMP system, there is the opportunity to deploy a different OS on each core – e.g. an RTOS and Android/Linux – as befits the required functionality.

However, the introduction of such diversity may be inappropriate for some designs. For example, a medical instrument may have two CPUs, both of which are performing real-time processing, but perhaps only one is considered “patient critical”, requiring full certification of the software. They could both be using an RTOS, which addresses the functional requirements. Since the code size is modest and source code is available, certification is reasonably straightforward. Localization of the code that requires certification to one CPU means that only the appropriate code is submitted for certification.

Another example might be a point-of-sale terminal. In this case too, a couple of CPUs, both running an RTOS, might make sense. Here, the attraction of the multicore design is the hard segmentation between the “secure” part of the application, which handles the financial transaction, and the other functional components, like UI.

Symmetric Multicore – SMP

Like AMP, an SMP system has multiple CPUs, but in this case each has exactly the same architecture – i.e. it must be a homogeneous multicore design. CPUs share memory space (or at least some of it). Normally a single OS is used that runs on all the CPUs, dividing work between them – another significant difference from AMP. Some kind of communication facility between the CPUs is provided – this is normally through shared memory, but accessed through the API of the OS.

Typically, SMP is used when an embedded application simply needs more CPU power to manage its workload, in much the way that multicore CPUs are used in desktop computers.

Hypervisors

A hypervisor is commonly thought of as being a layer of software that enables multiple operating systems to simultaneously co-exist on a single CPU, with each having the impression that it has sole control of the silicon. This can be useful to bring together a number of disparate software products in a single device. However, a hypervisor may have a valuable role to play on a multicore design.

In addition to oversubscription scenario described above, when a design demands to run more operating systems than cores available in the silicon, hypervisors are also used to enable consolidation and robustness or security of devices.

When migrating from a system with multiple CPUs to the single multicore device, it is common to have applications on various points on the real time spectrum. For example, one might need to mix an application that performs polling and cannot tolerate jitter with an application that needs graphics or connectivity, but can tolerate a bit of delay every once in a while. Thus we see many designs where users have Linux running side-by-side with an RTOS.

In a multicore system, special attention must be paid to make sure these operating systems and applications are properly separated from each other and not compromising each other’s resources, such as memory or peripherals. On the other hand, if there are limited resources, there might be a need to share them between various operating systems. For example one might need to run a GPOS such as Linux side by side with an RTOS like Nucleus and share one Ethernet or serial port between them. Embedded hypervisors enable virtualization to enforce strong isolation of guests for robustness, security, or the separation of IP.

Combining AMP and SMP

Although there is a clear distinction between AMP and SMP architectures, there is not necessarily a simple choice between the two. For example, there may be a number of cores of identical architecture which are configured to be an SMP sub-system. Logically, this sub-system looks like a single core and can, therefore, be included in an AMP system.

Conclusions

There is no doubt that multicore designs will be increasingly common going forward. There are a variety of choices in terms of both hardware and software architecture, the selection of which is strongly driven by the application.

I acknowledge the valuable input for this article that I received from my colleague Felix Baum.

Colin Walls has over thirty 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 Embedded (the Mentor Graphics Embedded Software Division), and is based in the UK.

He has a blog on the Mentor site. He can be reached by email at

Share this: Twitter

Facebook

LinkedIn

More

Reddit

Tumblr



Pinterest

WhatsApp



Skype

Pocket



Telegram

