Meeting the Challenge of Multicore

Multicore Processors Open Our Embedded World

Migrating legacy code onto new multicore processors is not to be taken lightly. But with a new range of SMP RTOS and Virtualization solutions now available, there are options to both make the task easier, and at the same time increase the functionality and connectivity of the embedded system.


  • Page 1 of 1
    Bookmark and Share

Article Media

Multicore systems are not new to the embedded world. In fact, most embedded systems use multiple cores or chips, with many of these cores or chips being used to help performance or enhance the operation of a particular function. However, these dedicated chips are usually not on the same die as the main processor, are often a completely different architecture, and are programmed completely independently of the main processor and its operating system. These are known as heterogeneous multicore systems, and the cores can be treated and programmed somewhat autonomously from one another.

More recently we have had the advent of multicore processors, where a single chip contains multiple cores of the same type, which often share resources and where the use of the cores is controlled by the processor. These “homogenous” multicore processors are now becoming the norm in 32- and 64-bit architectures, and embedded developers now have to understand the implications, both positive and negative, for using multicore processors in their next generation of products.

Many embedded real-time systems are very carefully designed and coded to meet the relatively stringent requirements of performance, power, memory size, timing and latency. The introduction of a new processor model can throw some of these system characteristics off, and the embedded developer is faced with the question “How does one take a legacy single core embedded system and spread it over multiple cores without causing the system to behave differently?” Before answering that question, it’s also worth looking at the use of multicore processors as an opportunity rather than a problem, and then pose the question “What additional functionality could I add to my legacy single core embedded system by using a multicore processor?” This is a particularly interesting question when the new “Internet of Things” is brought into the mix, as embedded systems now become embedded systems connected to the Internet, where additional connectivity, functionality and security are new requirements.

Looking at the migration of a legacy system to multicore processor is quite a complicated topic with more than one approach. The potentially least painful migration path is to just run the legacy system on one of the processor cores, and forget about the other one(s). Apart from the obvious “waste” in not utilizing the other core(s), this strategy relies on the fact that the multicore processors are the same type and clock speed as the single core versions. This is not typically the case, as by multiplying the core count by at least 2x, the processor vendor can reduce the performance or the clock rate of the cores and still get a performance increase over the single core version. Therefore, if the application is running on just one of the cores, there will actually be a degradation in performance over the previous generation of single core processors. Now, there are certain industries where this approach is still the best option. For example, when migrating certified legacy systems (such as avionics) to new hardware platforms, the cost and risk to re-engineer and re-certify the software to run across multiple cores can be prohibitive.

For the rest of the embedded world, the migration of embedded systems from single core to multicore is becoming a “when” rather than an “if,” and so we should now consider some approaches to make that migration feasible. As most 32- and 64-bit embedded systems are likely to be running some kind of operating system, either RTOS or GPOS, we will make the assumption here that both the legacy and new systems will use an OS. The use of an OS can actually make the migration job easier, as the OS can often do much of the heavy lifting when it comes to managing the multiple cores on a processor. But this is where we need to clarify approaches, as it impacts how much the OS can actually help. The two main approaches to running code on a multicore system are asymmetric multi-processing (AMP) and symmetric multi-processing (SMP). AMP essentially treats the multiple cores as separate entities, and runs code (including OSs) on the individual cores. SMP has a single copy of the OS running across the multiple cores and manages how the code (in the form of tasks, processes or threads) is allocated to the different cores (Figure 2).

Figure 2
Figure 2: Different approaches to migrating legacy applications to multi-core processors.

Asymmetrical Multi-Processing

Comparing these approaches really boils down to how much application migration work is needed to be done by the developer, and how much is left to the OS. Using an AMP approach means that the developer must take the existing legacy code and decide which functions will run on which of the cores, essentially load balancing the system manually. The complexity of the system, the structure of the legacy code and the performance tolerances that it must adhere to, will really determine how big of a job this is. Assuming that the legacy code used an OS, then the code should already be well structured, and it is really down to the interdependencies and inter-communications between the functions that will help guide which core they run on. It is still possible to communicate between functions running on different cores, but it is more complex, and often with a greater overhead. Not only does the legacy code need to be changed, but usually changes need to be made to the legacy operating system as well.

A single core OS is used to having all the hardware resources, such as memory and devices, at its disposal, and now these resources are being shared between different instantiations of the OS. Each of them will need to be modified to only access the parts of the system that are being used by the applications running on this core, so device and memory contention can be avoided. At best, this requires a new and different board support package (BSP) for each OS instantiation, but can also require changes to the operating system itself, especially if there are specific hardware dependencies in the original single core implementation. Another issue with running an AMP system is that a copy of the operating system is required for each core, which means additional memory will be required. Even though memory is considered “cheap” in today’s computer and mobile devices, this could present cost, power or size problems either for constrained embedded devices, low-power embedded devices, or if large GPOSes are being used. 

AMP can be a possible approach to adding new functionality to existing systems by running the new functionality on the second core and keeping the legacy system on a single core, but obviously many of the complications discussed above still apply.

Symmetrical Multi-Processing

As multicore processors became more prevalent, so did the number of operating systems that provided SMP support. Using an SMP approach means that a single copy of the OS runs across and manages the multiple cores in the processor. If an OS was used in the original single core system, and now the same operating system is available in SMP form, and assuming the OS APIs have not changed dramatically with the SMP version, then the OS can take care of many of the migration issues faced with an AMP solution. The SMP OS will manage the allocation of memory, cores, and to a certain extent the shared devices, and will make decisions on which cores the tasks or processes will execute on. An SMP OS has the advantage of only running one instantiation, so memory footprint will not grow dramatically as in AMP, and device and memory contention is not an issue, as it’s all managed by the OS.

Although this appears to be the Nirvana for legacy code migration, there are a couple of considerations that need to be thought through. Firstly, an SMP OS is somewhat more complex than its single core sibling, and the scheduling mechanism for running across multiple cores really needs to be understood by the developer as the system is moved from single to multiple cores so that the execution characteristics of the code can be tuned accordingly.

This leads to the second consideration—the ability to run code in parallel across the multiple processors. In a single core system using an OS, there is perceived parallelism from multiple tasks running concurrently, but as far as actual processor execution, the code is running sequentially, with the magic of multi-tasking carefully controlled by the OS. On a multicore system, the tasks are actually running in parallel on the multiple cores, which can lead to obvious performance increases provided the code is structured appropriately. If tasks running on different cores are competing for the same resources, or waiting for communication with tasks that are not currently running, then they will get stalled and the performance drops dramatically. It can actually be worse than the single core execution. This is really the key part in migrating from a single to multicore device, as the single core code would not have been built with true parallelism in mind, and now a careful redesign is necessary, re-allocating functions with applications, and re-designing the applications themselves to exploit parallelism.


As discussed above, the migration of code from single to multiple cores is not a task that should be treated lightly, even with the help of multicore OSs, so adding an extra layer of complexity would seem like a nonsensical idea. However, bringing virtualization into the mix actually can simplify the migration process, and also add some other key capabilities that were not covered when discussing AMP and SMP approaches.

The use of virtualization is still relatively new in the embedded world, despite most modern embedded multicore processors also having virtualization assistance built in. However, it is well established in the enterprise world. One of the key reasons that the enterprise has embraced virtualization is that it has allowed corporations to continue to use legacy PC applications and operating systems that are key to their business, while migrating to new, faster multicore hardware platforms. Virtualization basically presents virtual motherboards, with processors and devices expected by the legacy applications and operating systems, regardless of the actual hardware they are running on, usually without any modification required to either the OS or the applications (Figure 3).

Figure 3
Figure 3: Virtualization offers ease of migration, new capabilities and security.

This approach can also be taken with embedded code migration, using an embedded hypervisor. The hypervisor runs directly on top of the hardware and manages the processors, memory and devices, and then presents a “virtual” view to each of the “guest” OSs that run on top of it. The guest OSs typically can be run unmodified and will be presented with a virtual version of the legacy hardware. Virtualization can take the benefits of both the AMP and SMP OS approaches above and let legacy systems run unmodified on new hardware platforms with the hypervisor controlling and managing all of the new hardware resources. The advantage of using an embedded hypervisor is that it typically has a small footprint and deterministic real-time scheduling mechanisms that provide a very low overhead. The task of code migration becomes more of a configuration task than other approaches, as once the virtual motherboards are configured, the operating systems and their applications can run unmodified, and should execute in a similar manner to the original system.

Where virtualization really becomes interesting is in the addition of extra capabilities to the original system. These extra capabilities can include connectivity, security, GUI or just extra features. By the nature of virtualization and multicore processors, many of these capabilities can be added without having to make dramatic (if any) changes to the legacy system. In fact, unlike the AMP and SMP approaches, a completely different operating system could be used, running on its own virtual motherboard, which offers better support for new functionality than the existing RTOS (Figure 4). 

Figure 4
Figure 4: Using virtualization on multicore processors can offer multiple OSs performing different functions on a single system protected from one another.

Examples include GUI functions, where a well-known GUI like Microsoft Windows or Android could make the user experience easier, and also easier for the developers as the tools for building GUIs are part of these OSs. Another example is networking, where embedded devices are now required to connect over different connection media such as Wi-Fi, Bluetooth and cellular, and where modern operating systems are more likely to have support for these new connection technologies, even if it’s just a more recent version of the legacy OS. Using virtualization to run multiple different OSs on a single multicore processor really opens up the possibility of adding new functionality to legacy systems without compromising the legacy code, and being able to take advantage of modern technologies (Figure 4).

Figure 4
Figure 4: Using virtualization on multicore processors can offer multiple OSs performing different functions on a single system protected from one another.

The last aspect of using virtualization really applies to the new world of connected embedded devices, known as the Internet of Things, where embedded devices can be managed, controlled or communicated with over the Internet. Traditionally, most embedded devices are either not networked, or if they are it is typically on a private or proprietary network, making it easier to protect them from malicious attacks. However, when connected via the Internet, these devices are open to attacks from anyone and anywhere in the world. Using an embedded hypervisor, especially one built on a secure foundation such as a separation kernel, can allow for protection of the legacy system, even though it is now connected. If the legacy system is running on its own virtual motherboard, and the network communication is on another virtual motherboard, any attacks can be largely contained within the network side of system. This means an attack like a Denial of Service (DoS) could well interrupt the network part of the system. However, with the legacy system (the real-time component) and often its data running on a separate virtual motherboard with its own processor and resources, these should continue to function while the network attack is being sorted. This security is vital in systems that are controlling our critical infrastructure, as any issues with the real-time aspect of the system could be catastrophic.

San Jose, CA
(408) 979-3900