SOFTWARE TOOLS FOR MULTICORE DSPs
Due to the hard, real-time nature of DSP programming, one of the main require- ments that DSP programmers insist on having is the ability to view low-level code, to step through their programs
instruction by instruction, and evaluate their algorithms and “see” what is happening at every processor clock cycle. Visibility is one of the main impediments to multicore DSP
ADDING MULTIPLIER UNITS IS THE SIMPLEST FORM OF DOING
MULTIPROCESSING IN A DSP DEVICE.
set of resources that can be accessed by the OS.
The OS is responsible for assigning processes to different cores while balancing the load between all the cores. An
programming and to real-time debugging as the ability to “see” in real time decreases significantly with the integration of multiple cores on a single chip. Improved chip-level debug techniques and hardware-supported visualization tools are needed for multicore DSPs. The use of caches and multiple cores has complicated matters and forced programmers to speculate about their algorithms based on worst-case scenari- os. Thus, their reluctance to move to multicore programming approaches. For programmers to feel confident about their code, timing behavior should be predictable and repeatable [5]. Hardware tracing with embedded trace buffers (ETB) [18] can be used to partially alleviate the decreased visibility issue by storing traces that provide a detailed account of code execu- tion, timing, and data accesses. These traces are collected internally in real time and are usually retrieved at a later time when a program failure occurs or for collecting useful statis- tics. Virtual multicore platforms and simulators, such as Simics by Virtutech [19], can help programmers in developing, debugging, and testing their code before porting it to the real multicore DSP device.
Operating systems (OSs) provide abstraction layers that
allow tasks on different cores to communicate. Examples of OSs include SMP Linux [20], [21], TI’s
DSP BIOS [22], and Enea’s OSEck [23].
PCC DOC DMI DMA SBI
One main difference between these OSs is in how the communication is per- formed between tasks running on differ- ent cores. In SMP Linux, a common set of tables that reflect the current global state of the system are shared by the tasks running on different cores. This allows the processes to share the same global view of the system state. On the other hand, TI’s DSP/BIOS and Enea’s OSEck supports a message passing pro- gramming model. In this model, the cores can be viewed as “islands with bridges” as contrasted with the “global view” that is provided by SMP Linux. Control and management middleware platforms, such as Enea’s dSpeed [23], extend the capabilities of the OS to allow enhanced monitoring, error handling, trace, diagnostics, and interprocess com- munications.
As in memory organization, program-
ming models in multicore processors include SMP models and AMP models [24].
example of such an OS is SMP Linux [18], [19], which boasts a huge community of developers and lots of inexpensive soft- ware and mature tools. Although SMP Linux has been used on AMP architectures such as the mesh interconnected Tilera architecture, SMP Linux is more suitable for SMP architec- tures (see the section “Interconnect and Memory Organization”) because it provides a shared symmetric view. In comparison, TI’s DSP/BIOS and Enea’s OSE can better support AMP architectures since they allow the programmer to have more control over task assignments and execution. The AMP approach does not balance processes evenly between the cores and so can restrict which processes get executed on what cores. This model of multicore processing includes classic AMP, processor affinity, and virtualization [23].
PCC DOC DMI DMA SBI
PCC DOC DMI DMA SBI
Classic AMP is the oldest multicore programming approach. A separate OS is installed on each core and is responsible for handling resources on that core only. This sig- nificantly simplifies the programming approach but makes it extremely difficult to manage shared resources and I/O. The developer is responsible for ensuring that different cores do not access the same shared resource as well as be able to com- municate with each other.
In an SMP model, the cores form a shared
|
