Multicore is here
Scope
Who should read this book?
Organization and roadmap
Concurrency
Architecture
High-level architecture
Memory architecture
Interconnect
Infrastructure
Operating systems
Virtualization
Multicore-related libraries
Application software
Languages and tools
Partitioning applications
Synchronization
Hardware assistance
Hardware accelerators
Synchronization hardware
System-level considerations
Bare-metal systems
Debug
A roadmap of this book
Multicore is here
Actually, multicore has been around for many years in the desktop and supercomputing arenas. But it has lagged in the mainstream embedded world; it is now here for embedded as well.
Up until recently, multicore within embedded has been restricted primarily to two fields: mobile (assuming it qualifies as an embedded system, a categorization that not everyone agrees with) and networking. There have been multiple computing cores in phones for some time now. However, each processor typically owned a particular job ā baseband processing, graphics processing, applications processing, etc. ā and did that job independently, with little or no interaction with other processing cores. So multicore really wasnāt an issue then. Thatās changed now that application processors in smartphones have multiple cores: itās time to start treating them as full-on multicore systems.
Meanwhile, networking (or, more specifically, packet-processing) systems have used multicore for a long time, well before any tools were available to ease the multicore job. This has been a highly specialized niche, with rockstar programmers deeply imbued with the skills needed to extract the highest possible performance from their code. This has meant handcrafting for specific platforms and manual programming from scratch. This world is likely to retain its specialty designation because, even as multicore matures, the performance requirements of these systems require manual care.
For the rest of embedded, multiple cores have become an unavoidable reality. And multicore has not been enthusiastically embraced for one simple reason: itās hard. Or it feels hard. Thereās been a huge energy barrier to cross to feel competent in the multicore world.
Some parts of multicore truly are hard, but as it reaches the mainstream, many of the issues that you might have had to resolve yourself have already been taken care of. There are now tools and libraries and even changes to language standards that make embedded multicore programming less of a walk in the wild.
And thatās where this book comes in. There have been people quietly working for years on solving and simplifying multicore issues for embedded systems. And letās be clear: what works for desktops is not at all acceptable for embedded systems, with their limitations on size, resources and power. It has taken extra work to make some of the multicore infrastructure relevant to embedded systems.
Some of the people involved in those processes or simply with experience in using multicore have contributed from their vast knowledge to help you understand multicore for embedded. Most importantly, the intent is that, by taking in the various topics weāve covered, youāll cross over that energy barrier and be able to start doing the multicore work you need to do.
Scope
The term āembedded systemā is broad and ill-defined. You probably know it when you see it, although community standards may vary. We wonāt try to define what is included; itās probably easier to say what isnāt included:
ā desktop-style general computing (although desktop computers are sometimes harnessed for use in embedded applications)
ā high-performance computing (HPC), the realm of supercomputers and massively parallel scientific and financial computing.
Many of the concepts discussed actually apply to both of those realms, but we will restrict examples and specifics to the embedded space, and there will be topics (like MPI, for example) that we wonāt touch on.
Who should read this book?
This book is for anyone that will need to work on embedded multicore systems. That casts a wide net. It includes:
ā¢ Systems architects that are transitioning from single-core to multicore systems.
ā¢ Chip architects that have to implement sophisticated systems-on-chips (SoCs).
ā¢ Software programmers designing infrastructure and tools to support embedded multicore.
ā¢ Software programmers writing multicore applications.
ā¢ Software programmers taking sequential programs and rewriting them for multicore.
ā¢ Systems engineers trying to debug and optimize a multicore system.
This means that we deal with hardware, firmware/middleware, software, and tools. The one area we donāt deal with is actual hardware circuit design. We may talk about the benefits of hardware queuing, for example, but we wonāt talk about how to design a hardware queue on a chip.
We have assumed that you are an accomplished engineer with respect to single-core embedded systems. So weāre not going to go too far into the realm of the basic (although some review is helpful for context). For example, we wonāt describe how operating systems work in general ā we assume you know that. We talk about those elements of operating systems that are specific to multicore.
Organization and roadmap
In order to give you the broad range of information that underpins multicore technology, weāve divided the book into several sections. These have been ordered in a way that allows a linear reading from start to finish, but you can also dive into areas of particular interest directly if you have experience in the other areas. Each chapter is an independent āessayā, although weāve tried to avoid too much duplication, so you will find some references from chapter to chapter.
Concurrency
We start with a review of the concept that underlies everything that matters in this book: concurrency. The reason everything changes with multicore is that our old assumption that one thing happens before another no longer holds true. More than one thing can happen at the same time, meaning we get more work done more quickly, but we also open up a number of significant challenges that we havenāt had to deal with before. Understanding concurrency in detail is important to making sense out of everything else that follows.
Architecture
The next section concedes the fact that hardware is expensive to design, therefore hardware platforms will be created upon which software will be written. Itās nice to think that embedded systems are a perfect marriage between purpose-built hardware and software that have been ...