Software for multicore embedded systems can be very complex. A frequent subject of discussion is how to implement the code on each core so that it is utilized optimally. In this short article, there is a different perspective: a focus on software that can run across multiple cores.
Multicore hardware architectures
From the hardware perspective, there are broadly two types of multicore devices: homogeneous multicore, where there are multiple cores all of the same type, and heterogenous multicore, where the cores are of differing types. A heterogeneous device may include some identical cores.
To run a single piece of software across multiple cores, the cores must be identical (from an instruction set perspective anyway). So, a homogeneous multicore device or an “island” of homogeneity in a heterogeneous device is required.
One reason to build a multicore system is to maximize computing power in an energy-efficient manner. This is the approach taken by designers of personal computers; multicore processors are almost ubiquitous in laptop and desktop systems. Embedded developers may have the same objective. The best approach is to use an operating system that supports Symmetrical MultiProcessing (SMP).
An SMP OS distributes the processes over the available cores. This usually is automatic, but an embedded developer may need to exercise some control and perhaps lock certain applications to specific cores. The processes do not “know” that they are running on different cores; the OS provides communication and synchronization between them. SMP versions of several real-time operating systems (RTOSes) are available; Linux is also available in an SMP variant.
Although an embedded SMP OS provides some level of control, embedded developers generally want to be sure that the allocation of resources is configured entirely to their liking. So, another option is to configure each core with its own OS instance – and all the cores need not be running the same OS – and application code. Then, run a hypervisor over all the cores that can control their operation (boot order etc.) and provide inter-core (or inter-OS) communication.
For more flexibility …
So far, we have increased flexibility by moving from a single (SMP) OS in the system to multiple, perhaps differing OS instances. But what if even more flexibility is needed that necessitates using cores of different architectures? This removes the option of running code across multiple cores – an SMP OS or a hypervisor both require a homogeneous multicore environment. However, another option is available: run a multicore framework (perhaps a product based on OpenAMP) on each core. This approach provides inter-core communication and lifcycle management. Additionally, the option to run an application on “bare metal” (i.e. with no OS) becomes available.
Developing software on a multicore embedded system is a complex undertaking. It is essential to appreciate some of the options – the trade-offs between relative simplicity and complete flexibility.
|Colin Walls has over forty 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, a Siemens business, and is based in the UK. His regular blog is located at: https://blogs.sw.siemens.com/embedded-software/. He may be reached by email at firstname.lastname@example.org.|
- The multicore lexicon: Defining the terminology
- Ensuring software timing behavior in critical multicore-based embedded systems
- How embedded development has evolved over the past two decades
- Software-defined automobiles: An efficient platform for essential parallelization
For more Embedded, subscribe to Embedded’s weekly email newsletter