Consolidation is a long-standing trend within the embedded world. Itenables more capable, higher-performance embedded devices using fewercomponents, at lower cost and power budgets.
The latest round of this trend is the proliferation of multicore embedded microprocessors, offering multiple processor cores in a singlepackage ” with lower power consumption and cost than an equivalentsingle-core processor.
Taking advantage of multiple processor cores will require moresystem-level design cooperation between software and hardware teams. Inthat spirit, here are high-level overviews of three simple models formulticore systems which are straightforward to implement with today'stools and hardware.
These multicore design patterns are not intended to be rigid modelsfor exactly specifying a system. Rather, they are starting points forthinking and talking about the high-level picture of what your systemdoes, and provide a common terminology so that hardware and softwareteams can hash out a multicore system structure.
The first pattern is the Planar Pattern, named from the “control planes” and “data planes” which typicallydivide a telecommunication system's processing tasks. Shown in Figure 1 below , it is an example ofa broad and diverse category of multicore designs, collectively called Asymmetric Multiprocessing (also”AMP” or “ASMP”).
|Figure1: The first model is the Planar Pattern, named from the “controlplanes” and “data planes,” which typically divide a telecommunicationsystem's processing tasks.|
To use the Planar Pattern, your system needs to be divisible intoself-contained pieces that have significantly different processingrequirements.
In its classic telecom and media processing forms, this pattern'sadvantage comes from running data-heavy algorithms on a specialized DSPor network processor, while keeping the rest of the system software ona general-purpose CPU.
This specialization means that Planar Pattern systems are normallyimplemented on purpose-built hardware ” the high-level design ofsoftware for a Planar system will usually follow from the structure ofthe hardware it runs on. As many Planar hardware devices have only onegeneral-purpose CPU core, conventional single-core tools, operatingsystems, and design techniques can be used for design and debug of thegeneral purpose side of the system.
The Grid-on-Chip (or just “Grid”) Pattern (Figure 2, below ) is a variation ofthe Planar Pattern, and covers any multiprocessor system made up of acollection of fully independent, networked nodes. The Grid is theon-chip version of the office computer network ” a collection ofnetworked processing nodes that share physical proximity, but areotherwise independent. Some literature refers to this type of system asa distributed multiprocessing system, and it is also lumped into thegeneral category of AMP/ASMP systems.
|Figure2: The Grid Pattern is a variation of the planar pattern and covers anymultiprocessor system made up of a collection of fully independent,networked nodes.|
The key requirements to use the Grid Pattern are to first partitionyour system, and then find a suitable inter-node communication system. (Although more advanced Grid systems can bebuilt to reconfigure themselves at runtime, designers of a Grid Patternsystem need to carefully think through the assignment of systemfunctions to processing nodes. )
Aside from the partitioning, Grid systems have the fewest high-leveldesign constraints of these three design patterns. Once the system ispartitioned, design and implementation of each individual node proceedsjust like a standalone system. Grid systems can be implemented onspecialized hardware, but another common choice is to create Grid nodesby using SMP hardware and dividing up the shared memory into per-coresections.
Grid Pattern systems have several important advantages over otherdesigns. First, they easily integrate with legacy software ” legacysystems can even continue to run intact on their own nodes within theGrid. In addition, Grid systems have advantages in determinism anddebuggability.
The loose coupling of a Grid Pattern system design means fewersurprises regarding resource contention, and debugging is simplerbecause familiar single-core debug methods can be used for each systemnode in isolation. The partitioned nature of a Grid Pattern systemleads to its strengths, but is also the source of its weakness ” thepartitions make it difficult to redistribute resources, which can makeGrid systems less flexible for adapting to future, unanticipatedrequirements.
In a symmetric multiprocessing (orsimply “SMP”) system, a single-image operating system runs on top oftwo or more essentially identical processing cores which share memory.(The term “SMP” is slightly more general than this, but this is themost common usage.)
As shown in Figure 3 below ,just like a multicore desktop PC, SMP Pattern systems can dynamicallybalance tasks over a pool of processor cores. This ability toredistribute processing power to match the tasks at hand is a majorstrength of SMP systems, and is what makes them the most flexible andadaptable of these three patterns. With modern SMP real-time operatingsystems, this flexibility comes with no cost in determinism orreal-time responsiveness.
|Figure3: In an SMP system, a single-image OS runs on top of two or moreessentially identical processing cores which have memory.|
An SMP Pattern system requires two things: a symmetric, multicoreshared-memory processor platform and an SMP-capable operating system.SMP-capable hardware is available today in most processor families, andSMP operating systems are available from a variety of sources.
Two more key advantages of an SMP system are developer familiarityand a quick start ” in theory, you simply boot up your SMP-capableoperating system, port over your existing applications, and presto,you're taking advantage of the power of multicore hardware.
The reality isn't far from this, but there are a few gotchas to keepin mind. The first concerns hard real-time requirements. A capable SMPRTOS will not compromise real-time performance, but operating systemswithout hard real-time capabilities will tend to less determinism andhigher, more variable interrupt latency when using SMP.
Again, this is not a worry for a good SMP RTOS ” but keep in mindthat general-purpose operating systems may behave differently on SMPhardware than they do on uniprocessor systems.
The second potential gotcha is resource contention. One key strengthof SMP systems is that many resources are shared, making them veryflexible and adaptable. However, this strength is also a weakness “because all resources are shared, there may be unexpected performancevariations due to resource contention. This won't happen in everysystem, but keep it in mind if you want to design your system to veryrun close to capacity.
Implementation and Debug
As is always the case with embedded development, it pays to think aheadabout software development and debugging during hardware design. Makingsure your design allows access to your silicon's on-chip debug(OCD) capabilities will greatly speed system bring-up andgive you a reliable tool for programming and analyzing your system.
In Planar and Grid Pattern designs, a single OCD port can allowdevelopers to debug the individual cores of the system just as theywould a more traditional single-core system.
Real-time trace ports are another debug feature that becomes moreimportant as the number of cores in the system grows. Real-time traceoffers a standardized way to observe interactions between cores withoutdisrupting the subtle timing that may be key to reproducing a problem.If your multicore device includes a real-time trace port ” and manywill ” make sure your system is set up for easy access.
It's an oft-repeated myth that software development tools “aren'tready for multicore”, despite many successful deployments using thesethree design patterns. SMP-capable real-time operating systems areavailable now, and can give you the flexibility of the SMP Pattern withno loss of real-time determinism.
For designs using Planar and Grid Patterns, developers can leverageexisting, familiar, proven single-core tools and techniques. Amulticore design can make your system more complex, but establishedtools and techniques can help you manage the complexity and realize thepower and cost benefits that multicore hardware has to offer.
Anderson MacKay is EngineeringManager, Hardware Debug/Trace Probes, GreenHills Software