Read an Excerpt
Real World Multicore Embedded Systems
A Practical Approach Expert Guide
By Bryon Moyer Elsevier
Copyright © 2013 Elsevier Inc.
All rights reserved.
ISBN: 978-0-12-391461-3
CHAPTER 1
Introduction and Roadmap
Bryon Moyer Technology Writer and 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-level architecture 5
Memory architecture 5
Interconnect 5
Infrastructure 5
Operating systems 6
Virtualization 6
Multicore-related libraries 6
Application software 6
Languages and tools 7
Partitioning applications 7
Synchronization 7
Hardware assistance 7
Hardware accelerators 8
Synchronization hardware 8
System-level considerations 8
Bare-metal systems 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.
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 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.
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.
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.
(Continues...)
Excerpted from Real World Multicore Embedded Systems by Bryon Moyer. Copyright © 2013 Elsevier Inc.. Excerpted by permission of Elsevier.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
