Real World Multicore Embedded Systems

624 Pages·2013·12.982 MB·English

by  Bryon Moyer (Eds.)

CHAPTER 1
Introduction and Roadmap
Bryon Moyer
Technology Writerand Editor, EE Journal
Chapter Outline
Multicore is here 1
Scope 3
Who should read this book? 3
Organization and roadmap 4
Concurrency 4
Architecture 4
High-levelarchitecture 5
Memoryarchitecture 5
Interconnect 5
Infrastructure 5
Operatingsystems 6
Virtualization 6
Multicore-relatedlibraries 6
Applicationsoftware 6
Languagesandtools 7
Partitioningapplications 7
Synchronization 7
Hardwareassistance 7
Hardwareaccelerators 8
Synchronizationhardware 8
System-levelconsiderations 8
Bare-metalsystems 8
Debug 8
A roadmap of this book 9
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.
RealWorldMulticoreEmbeddedSystems.
DOI:http://dx.doi.org/10.1016/B978-0-12-416018-7.00001-8 1
©2013ElsevierInc.Allrightsreserved.
2 Chapter 1
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 (cid:1) baseband
processing, graphics processing, applications processing, etc. (cid:1) 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.
Introduction and Roadmap 3
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:
(cid:1) desktop-style general computing (although desktop computers are
sometimes harnessed for use in embedded applications)
(cid:1) 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:
(cid:129) Systems architects that are transitioning from single-core to multicore
systems.
(cid:129) Chip architects that have to implement sophisticated systems-on-
chips (SoCs).
(cid:129) Software programmers designing infrastructure and tools to support
embedded multicore.
(cid:129) Software programmers writing multicore applications.
(cid:129) Software programmers taking sequential programs and rewriting
them for multicore.
(cid:129) Systems engineers trying to debug and optimize a multicore system.
4 Chapter 1
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 (cid:1)
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
Introduction and Roadmap 5
be written. It’s nice to think that embedded systems are a perfect
marriage between purpose-built hardware and software that have been
co-designed, but, in reality, especially when designing an expensive SoC,
the hardware must serve more than just one application.
High-level architecture
This chapter takes a broad view of multicore hardware architecture as it
applies to embedded systems. Author Frank Schirrmeister focuses on the
arrangement of processing cores, but he must necessarily include some
discussion of memory and interconnect as well. The intent of this chapter
is to help you understand either how to build a better architecture or how
to select an architecture.
Memory architecture
Memory can be arranged in numerous different ways, each of which
presents benefits and challenges. In this chapter, author Gitu Jain picks
up on the more general description in the high-level architecture chapter
and dives deeper into the implications not only of main memory, but
also of cache memory and the various means by which multiple caches
can be kept coherent.
Interconnect
Processors and memory are important, but the means by which they
intercommunicate can have a dramatic impact on performance. It can
also impact the cost of a chip to the extent that simply over-provisioning
interconnect is not an option. Sanjay Deshpande provides a broad
treatment of the considerations and trade-offs that apply when designing
or choosing an interconnect scheme.
Infrastructure
Once the hardware is in place, a layer of services and abstraction is
needed in order to shield applications from low-level details. This starts
with something as basic and obvious as the operating system, but
includes specialized libraries supporting things like synchronization.
6 Chapter 1
Operating systems
Operating systems provide critical services and access to resources on
computing platforms. But with embedded systems, the number of options
for operating systems is far larger than it is for other domains. Some of
those options can’t deal with multicore; others can. Some are big and
feature-rich; others are small or practically non-existent. And they each
have different ways of controlling how they operate. So in this chapter,
with the assistance of Bill Lamie and John Carbone, I discuss those
elements of operating systems that impact their performance in multicore
systems, including the ability of associated tools to assist with software-
level debugging.
Virtualization
The increased need for security and robustness has made it necessary to
implement varying levels of virtualization in embedded systems. Author
David Kleidermacher describes the many different ways in which
virtualization can be implemented, along with the benefits and
drawbacks of each option.
Multicore-related libraries
The details of multicore implementation can be tedious and error-prone
to put into place. A layer of libraries and middleware can abstract
application programs away from those details, making them not only
more robust and easier to write, but also more portable between systems
that might have very different low-level features. Author Max Domeika
takes us on a tour of those multicore-related resources that are available
to help ease some of the burden.
Application software
The goal of a good multicore system is to make the underlying
configuration details as irrelevant as possible to the application
programmer. That’s less possible for embedded systems,
where programmers work harder to optimize their software to a
specific platform. But multicore raises specific new issues that
cannot be ignored by programmers.
Introduction and Roadmap 7
Languages and tools
Some languages are better than others at handling the parallelism that
multicore systems make possible. That said, some languages are more
popular than others without regard to their ability to handle parallelism.
Author Gitu Jain takes us through a variety of languages, covering their
appropriateness for multicore as well as their prevalence.
Meanwhile, tailoring an application for a multicore platform suggests
analysis and tools that don’t apply for single-core systems. Author Kenn
Luecke surveys a range of tools from a number of sources that are
applicable to multicore design.
Partitioning applications
Since multicore systems can do more than one thing at a time,
application programs that were once sequential in nature can be teased
apart to keep multiple cores busy. But that process of splitting up a
program can be very difficult. I’m assisted by Paul Stravers in this
chapter that describes the issues surrounding partitioning and then shows
you how to do it both manually and with new specialized tools designed
to help.
Synchronization
The success of various pieces of a program running in parallel to yield a
correct result depends strongly on good synchronization between those
different pieces. This concept lies at the heart of what can make or break
a multicore application. Author Tom Dickens runs through a litany of
dos and don’ts for keeping an application program on track as it
executes.
Hardware assistance
While there may appear to be a bright line defining what is expected in
hardware and what should be in software, there are some gray areas. In
some cases, hardware can assist with specific functions to improve
performance.
8 Chapter 1
Hardware accelerators
There are times when a hardware block can increase the performance of
some compute-intensive function dramatically over what software can
manage. Those accelerators can be designed to operate in parallel with
the cores, adding a new concurrency dimension. In this chapter, Yosinori
Watanabe and I discuss hardware accelerators and their considerations
for integration into embedded multicore systems.
Synchronization hardware
Much of the bookkeeping and other details required for correct
functioning of a multicore system is handled by low-level software
services and libraries such as those described in the earlier chapter on
multicore libraries. But hardware infrastructure can help out here as
well (cid:1) to the point of the processor instruction set having an impact.
So author Jim Holt takes a look at some important low-level hardware
considerations for improving embedded system performance.
System-level considerations
We close out with system-level optimization concepts: bare-metal
systems and debugging. These chapters complement the preceding
material, leveraging all of the concepts presented in one way or another.
Bare-metal systems
The performance of some systems (cid:1) notably, the packet-processing
systems mentioned at the outset of this introduction (cid:1) is so critical that
the overhead of an operating system cannot be tolerated. This suggests a
completely different way of doing multicore design. Sanjay Lal and I
describe both hardware and software considerations in such a system.
Debug
Finally, debug can be much more difficult in a multicore system than in
a single-core one. It’s no longer enough to stop and start a processor and
look at registers and memory. You have multiple cores, multiple clocks,
multiple sets of interrupts and handlers, and multiple memories and
caches, each of which may be marching to the beat of a different
drummer. Successful debug relies heavily on the existence of robust
Introduction and Roadmap 9
control and observability features, and yet these features entail costs that
must be balanced. Author Neal Stollon discusses those trade-offs and
trends for multicore debug.
A roadmap of this book
Figure 1.1 illustrates the relationships between the various chapters
and their relationship to system design. The particular depiction of the
design process may feel oversimplified, and, in fact it is. But, as with
everything embedded, each project and process is different, so this
should be viewed as a rough abstraction for the purposes of depicting
chapter relevance.
Based on this model:
(cid:129) Everyone should read the Concurrency chapter.
(cid:129) System architects and designers can jump into the various platform-
design-related chapters, with Architecture, Memory, and Interconnect
being the most fundamental. Hardware synchronization is important
if designing accelerated infrastructure.
Figure 1.1
A rough depiction ofembedded multicore system development.
10 Chapter 1
(cid:129) For those engineers adapting an OS or virtualization platform or
writing drivers or adapting libraries, there are chapters specifically
introducing those topics.
(cid:129) For application writers, Partitioning and Synchronization are
important chapters. Hardware accelerators are also included here
because our focus is not on designing the hardware for the
accelerator, but rather on using it within the system: invoking it in
software, writing drivers for it, and handling the concurrency that it
can bring. There is also an overview of languages and tools as they
pertain to multicore to help make choices at the start of a project.
(cid:129) Integration and verification engineers can tackle the Debug chapter.
(cid:129) System designers and programmers trying to extract maximal
performance can take on the Bare-metal chapter.
That said, everyone can benefit from the topics they’re not specifically
involved in. A hardware designer can design a better platform if he or
she understands the real-world issues that software programmers face
either when writing an application or building firmware. A programmer
writing an application can write better code if he or she understands the
nuances and trade-offs involved in the platform that will run the code.
Our goal is to bring to you the experiences of those that have been
tackling these issues before it was mainstream to do so. Each of their
chapters encapsulates years of learning what works and what doesn’t
work so that you don’t have to repeat those lessons. We hope that this
serves you well.
Welcome to the age of embedded multicore.