Understanding multicore basics: AMP and SMP
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 multi-core design. If all the CPUs have exactly the same architecture, it is termed homogeneous multi-core; if there is variability in the architectures, it is heterogeneous multi-core.
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.
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 multi-core). 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. Localisation 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 multi-core design is the hard segmentation between the "secure" part of the application, which handles the financial transaction, and the other functional components, like UI.
With multi-core 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.
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 multi-core 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 multi-core CPUs are used in desktop computers.
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 multi-core design.
|Related Articles||Editor's Choice|