Multicore’s place in the real-time world

Multicore’s place in the real-time world

Today’s multicore landscape encompasses real-time systems

BY MATT GORDON
Senior Applications Engineer
Micrium
http://micrium.com

Multicore CPU architectures are a little like hybrid vehicles: Once seen as anomalies, both are now encountered on a regular basis and are widely accepted as possible solutions to challenging problems. Also, much as hybrid designs are not expected to fully supplant the traditional, internal combustion engine in the foreseeable future, multicore architectures likely won’t force the extinction of single-core MCUs anytime soon.

Within the embedded community, a few applications now seem to be almost exclusively multicore, but in many others multicore remains rare. The reasons for not migrating to multicore include concerns over the complexity of multicore platforms and uncertainty about the benefits that multicore offers.

Uncertainty about the benefits may be the primary reason for the lack of multicore adoption amongst one particular subset of developers—those who deal with real-time systems. Multicore devices seem to have acquired a reputation as not suitable for the rigors of real-time design. Although there is certainly some truth to this characterization, it is also true that today’s multicore landscape encompasses a number of hardware platforms and design techniques that hold potential for developers of real-time systems.

Multiple flavors of multicore

The impression that multicore hardware and real-time systems are incompatible may have arisen, in part, as a result of the technology now found in most PCs. Practically every desktop and laptop PC sold today is based on a multicore processor, and these PCs, along with the operating systems they run, are hardly exemplars of real-time performance.

However, for developers formulating an opinion on multicore systems, it is important to keep in mind that “multicore” is really a blanket term covering a variety of hardware. A multicore system can be homogenous or heterogeneous, meaning that it can be comprised of cores that are alike, or that differ from one another. It can also be symmetric or asymmetric, depending on whether its cores are general-purpose processing units or are specialized.

Fig. 1: In a multicore PC, each core plays the same role.

Typically, multicore PC processors are homogenous, and they run operating systems that perform symmetric multiprocessing (SMP). In the block diagram of an example PC processor (see Fig. 1) , there are four identical cores, all of which are managed by the OS. It is the job of the OS to share the CPU cores among a collection of different tasks. In performing this job, it mostly treats the cores as identical.

The operating systems found in PCs are general-purpose operating systems (GPOSes) written with a focus on average response times, not the worst-case response times that are key in real-time design. However, even in a hypothetical PC with a real-time operating system (RTOS), instead of a GPOS, there would be barriers to achieving real-time performance.

For instance, such a system could run into problems if it maintained the symmetric multiprocessing organization of the PC. In single-core systems, it’s possible to use relatively straightforward techniques to make sure that all of the tasks in a given set will be able to meet their deadlines. However, in an SMP system, with multiple processing units from which to choose, task scheduling can become a rather challenging exercise in logistics.

Another potential source of problems would be the system’s memory setup. Memory access tends to become a performance bottleneck, so most PCs include caches that help to reduce average access times. The caches, as many developers of real-time systems are well aware, also increase unpredictability, because their contents must occasionally be invalidated or flushed.

Cores with special roles

PCs are only one type of multicore platform. Other multicore varieties have characteristics much more closely aligned to the needs of a real-time system.

Asymmetric multiprocessing (AMP) is a multicore approach that offers a way around some of the challenges presented by the PC’s SMP architecture. Although “asymmetric” may seem to imply different cores, a system built on AMP does not have to be heterogeneous. There are currently numerous homogenous multicore platforms available that are intended for use in either an AMP or SMP mode.

Fig. 2: Devices in Altera’s SoC FPGA family combine a dual-core ARM Cortex-A9 with FPGA fabric.

Several examples of homogeneous multicore devices that are equally well suited for AMP and SMP can be found in Altera’s SoC FPGA family. Each of the highly capable devices in this family features a dual-core ARM Cortex-A9 CPU. As Fig. 2 illustrates, the processor is accompanied by a bevy of peripherals, and it can interface with custom IP via the devices’ FPGA fabric.

An SoC FPGA configured for SMP would have a single operating system managing both processor cores. However, a device configured for AMP would have either two different operating systems or two copies of the same operating system. In both cases, AMP offers some interesting possibilities for developers of real-time systems.

The AMP scheme involving two copies of the same operating system could use an RTOS, such as the popular µC/OS-III from Micriµm. Since each core would have a separate copy of the RTOS, a special multicore version of the software would not be necessary. Developers working with this type of system could use a single-core RTOS — one devoid of the complex scheduling algorithms that the SMP approach might need.

The alternative strategy for setting up an AMP platform, using different operating systems, opens the possibility of coupling an RTOS with a GPOS. In a system set up using this technique, one core could be devoted to real-time tasks while another could be assigned jobs having flexible deadlines. Such a system might, for instance, have a µC/OS-III-based core for processing UART data and A/D conversions, along with a Linux-based core for the user interface.

Rounding out the rough edges

While the AMP approach has upside, it is not a panacea for the many issues that multicore presents in a real-time context. One notable drawback to AMP is that it does not solve the memory problems that plague SMP; the cores of an AMP system, though they might each be distinct from the perspective of software, often use the same memory. Thus, a task running on one core may have memory access times that depend on the activities of tasks running on other cores (and, possibly, the vagaries of a cache).

Another potential problem area in AMP systems involves task dependencies that are not related to memory, but that arise out of the natural need for data to be shared amongst the different parts of an application. The careful partitioning of a system can lead to fewer of these dependencies, but, at a minimum, there is often still a need for tasks on different cores to communicate.

Developers then must decide how to implement their intercore communication and minimize its impact on performance. While issues of this sort are troubling, their consequences for developers of real-time systems are diminishing apace, thanks to continuing research on a variety of multicore topics.

Researchers have performed extensive analysis of the problems that the typical multicore processor’s memory system poses for real-time applications and have begun formulating clever strategies for avoiding these problems. Multicore experts have looked into the challenges of communication across cores, and these efforts have resulted in the formulation of standards, like MCAPI, as well as the introduction of time-saving tools, such as Poly-Platform from PolyCore Software.

No matter where the ongoing research takes the multicore idea, there are probably a number of applications that will never need more than one core. Certainly, there are real-time applications in which the positive aspects of multicore still appear to be outweighed by the negative. Multicore, though, is a highly malleable paradigm, manifested in a surprisingly diverse array of hardware platforms. These platforms cover a broad spectrum of performance requirements and are worthy of a second look from developers who may have once thought their real-time needs beyond the capabilities of a multicore processor. ■