Mobile devices' new roles need new tools

In the case of desktop computers, increases in CPU clock speed and memory sizes to support all applications mean higher cost and power dissipation. However, the constraints on size and power dissipation in the cell phone rule out this brute force approach and instead force multiprocessor solutions. Thus, developers of next-generation multimode, multistandard mobile devices need multiprocessor platforms with open software architectures to reduce time-to-market and development costs. The software architecture has to be versatile, open, scalable and able to integrate software components from different sources.

On the hardware side, mobile devices need both DSP cores to handle the complex physical layer portion of communications and general-purpose processor (GPP) cores to handle control-oriented tasks such as protocol stacks and user interfaces. There has been an extended debate on this, but the fact is that millions of handsets currently are based upon a dual-processor combination of a DSP and GPP. Future handset IC designs will use multiple DSPs and GPPs to handle all the tasks, as both the complexity of the physical layer and user interface soar.

On the software side, handsets must support multiple 2G/2.5G/3G standards as well as the multiple applications. Hardware-based solutions are not as effective in dealing with these design challenges and tend to have a slower time-to-market and much less flexibility. The most effective way to surmount these design challenges is software programmability on multiprocessor platforms. Some of the baseband algorithms may be amenable to complete software implementation on the DSP and others might have to be augmented with some kind of algorithm-specific hardware acceleration.

Media-processing algorithms such as audio/video compression and speech compression are complex signal-processing algorithms and involve a large amount of DSP and decision-oriented computations. Other algorithms and applications that future mobile handsets will have to support include adaptive antennas for increasing the spectral efficiency, speech recognition to replace keypad entry and biometrics for identity verification.

Software programmability is essential here as these algorithms are notoriously difficult to fix in hardwire alone. Also, as more-effective algorithms are developed, they can be more rapidly introduced to the mainstream with software upgrades rather than complete hardware redesign.

As the complexity of the mobile communications standards increase, software programmability must continue to extend into the physical layer of the mobile platform. This implies that we need scalable software architectures not only for the GPPs but also for the DSPs in a mobile platform.

The key to efficient software architectures for DSPs is the ability to integrate algorithms and applications from multiple sources as easily as possible. These sources for the applications or the algorithms could be the DSP core vendor or independent developers, or the mobile device chip maker.

Irrespective of the source, they should work seamlessly when integrated. To achieve this, an active and engaged developer community needs some insulation from the complexities of the embedded DSP core.

The above requirements necessitate a development environment based on a framework of open software architecture. It must be useful for a wide range of DSP applications on standalone DSPs or multiprocessor platforms. Such an open architecture should provide compatible algorithms and applications from different source. That includes:

• Scalability from single to multichannel and single to multicore subsystems;

• Configurability of algorithms and applications to app-specific needs;

• Portability across hardware platforms with a common underlying DSP core.

This open software architecture should provide an application module, algorithm module and platform-interface module.

The application module would be responsible for task scheduling, algorithm execution and high-level I/O control. It functions as the architecture's application layer and provides an interface between the algorithm modules and the platform-interface modules. The application module should be capable of handling both single-algorithm, single-port and multiple-algorithm, multiple-port applications.

The algorithm modules should provide both hardware-independent and -dependent software components for both baseband and media algorithms. Voice- and audio-compression algorithms do not require any external hardware acceleration, but algorithms such as equalization and channel decoding may require some external hardware acceleration. This requires a proper interface specification between the modules. Also, a key aspect of independent algorithm development is that the software components must meet the algorithm module interface specification to be integrated successfully.

The platform-interface modules provide developers with a hardware abstraction layer. Here, independent software developers can access a collection of device drivers and support libraries. A high-level application-programming interface delivers access to DSP-GPP communications, serial data streams and peripherals. The platform interface modules handle all the low-level device driver operations internally.

An example of such open software architecture is the application development framework. Such a software architecture requires a DSP-GPP interface to manage communication between the two subsystems. LSI Logic Corp. and ARM Ltd. are collaborating to define such an open interface for the design community.

A simple and efficient way of implementing communications between processors is via direct message passing through shared-memory mailboxes. A small dual-ported RAM can be used as a mailbox between the processors. The mailbox will have two sections: one for the messages coming from GPP and the other for the DSP. The processors post their messages in the respective mailboxes. A simple interrupt mechanism between the processors enables them to inform each other after posting a message to the mailbox.

Bridge strategy

An alternative and more complex approach for implementation of interprocessor communications is to use bridges between the processor subsystems. That enables each processor to access the other processor's local subsystems memories directly with read, modify and write privileges and provides a more scalable and more power-efficient approach than the mailbox technique. A more complex interrupt mechanism can be employed in this strategy, depending on the requirements.

The software architecture should not be affected by the particulars of the hardware interface. That's because the software will provide an abstraction layer that hides particulars of the hardware.

Jitendra Rayala, Stephen Jarboe and Wei-Jei Song are advanced DSP developers at LSI Logic Corp. (San Jose, Calif.).

http://www.eet.com