RTC Magazine

Open up the simplest consumer device—cell phone, MP3 player, etc.—and you will see a dizzying number of chips, each performing a specific function. The model that you buy today will be replaced in six months, by a new model that is smaller, lighter and packed with more functionality. Like a mouse on a wheel, embedded programmers are constantly running to make the complex simple, with a due date of yesterday.

As embedded systems evolve to support an ever-greater number of functions and capabilities, an increasing number of designers are turning to multiple processor architectures to achieve their performance, power, cost and time-to-market goals. Today’s embedded systems are no longer stand-alone, single-processor architectures that can be neatly controlled by a single team using a single development environment. In many cases, these architectures are a heterogeneous mix of single and multicore general-purpose processors (GPPs), digital signal processors (DSPs) and field programmable gate array (FPGA) processing components.

Further complicating design is the need for overall system flexibility. Not only do designers need to be able to repartition functionality between processing components to resolve bottlenecks and maximize efficiency, they also need mechanisms in place to enable them to quickly and effortlessly take advantage of future innovations in processors, operating systems and application-specific algorithms for next-generation designs.

Effectively developing the architecture of these new multiple processor systems—as well as the applications that span them—requires a new approach to system design. They must be treated as small networks unto themselves. System architects need an efficient and reliable communication infrastructure, commonly referred to as middleware, in order to pass data between processing components. While at first glance it may seem like a straightforward process to design and implement an efficient communication infrastructure specific to an application, doing so can actually place unnecessary and undesirable long-term constraints on a system.

Every time you repartition functionality, you will need to redesign multiple custom interfaces as well. When the time and effort needed to adjust communication interfaces manually becomes too high, the overhead involved can exceed the value in performance gained by repartitioning. Consequently, you lose the performance benefits of optimizing your system through repartitioning.

Standardizing the Communication Framework

The Common Object Request Broker Architecture (CORBA) standard was developed to provide a common communication framework between software components in a system. By abstracting applications, hardware components and the interfaces used to communicate between them, CORBA enables different parts of a system to communicate with each other, independently of how and where functionality is actually implemented (Figure 1).

For example, consider a military radar application that needs to process a high-speed signal. From an application perspective, what matters is the resulting signal, not whether it has been processed by a DSP or FPGA or both. CORBA ensures that the appropriate signal and signal processing workload are moved as efficiently as possible to the DSP or FPGA (or both) without requiring involvement from the application or developer. This is made possible through the use of a standard interface.

As important as making sure functionality can be moved to a DSP is the ability to easily and efficiently remove from the DSP all the tasks that might interfere with its optimal performance. Thus, this same standard interface enables system architects to further break down large partitions into several smaller ones. It now becomes both possible and simple to divide an algorithm initially assigned completely to one processor to multiple different processors, e.g., GPPs, DSPs and FPGAs. This further maximizes performance, minimizes latency and reduces system cost.

Flexibility of this magnitude is essential at the system level. System architects can then migrate logic transparently to optimize an architecture in many different ways, depending upon the application’s requirements. Voice applications, for example, may implement voice processing on a DSP with signaling handled by a GPP. Various stages of a video pipeline such as color correction or scaling can be interspersed back and forth between a DSP and an FPGA. When the cost of repartitioning is minimized, system architects can test out more partitioning and processor options to achieve the optimal system architecture.