You’ve probably been hearing a lot of buzz lately about multiprocessor chips. Putting multiple processors on a chip isn’t a new idea, of course. But such chips are gaining significant momentum both in general-purpose computing applications and in embedded systems. In the world of embedded digital signal processing applications, multiprocessor chips are becoming attractive for an expanding range of systems—even cost-sensitive applications like consumer products. As a result, effective software development for multiprocessor systems is increasingly important.
In some cases, creating software for a multiprocessor system is straightforward. For example, some digital signal processing applications handle multiple channels, with identical processing for each channel. In such applications, the software development process for a multiprocessor may not be very different from the tried-and-true approach used for uniprocessors.
The real challenge comes in using multiprocessors for applications that are not channelized. In these cases, each processor is expected to handle a different part of the application or algorithm, and the processors must closely coordinate their activities.
If you’re lucky, the partitioning is straightforward. For example, “control” functions—such as the user interface—go on one processor, and signal processing functions on another. But often the best partitioning is less obvious. Perhaps the application requires more signal processing throughput than a single processor can deliver—or more than a single processor can deliver efficiently. In such cases it may be necessary to do careful surgery on the application.
Partitioning a complex workload among multiple processors requires more than evenly carving up the computation load. Interprocessor communication and synchronization, and contention for shared resources such as memory, can create significant inefficiencies and must be carefully evaluated. For example, with a heterogeneous multiprocessor chip it can be tempting to assign each major processing task to the processor best suited for that task. But doing so may create so much interprocessor communication overhead that the advantage of matching each task to its ideal processor is lost.
Working with multiprocessor chips is complicated by the fact that today’s mainstream embedded software development tools and techniques have evolved over decades with a strong uniprocessor orientation. Not surprisingly, they aren’t geared towards solving the kinds of problems that are critical in multiprocessor software development. The mismatch between new multiprocessor chips and the existing embedded software development paradigm reverberates through the entire software development ecosystem, and there is significant inertia to overcome. For example, most software profiling and optimization tools are geared towards identifying and mitigating the bottlenecks commonly found in single-processor chips. Off-the-shelf software components and frameworks are generally crafted for uniprocessors. And few embedded software engineers have training or experience with multiprocessor architectures and their associated challenges, such as partitioning applications.
Realizing the potential gains of multiprocessor chips will require a major shift in software development approaches and tools. It’s not simply a matter of extending the single-processor mindset for multiple processors—we engineers need to go back to first principles and think creatively about how to best leverage multiprocessor chips for our signal processing applications.
Add new comment