The to and fro of DSP/RISC Convergence

In today's connected-computing environment, many of the hottest application areas can be found in consumer, home and industrial electronics, where the capabilities of both interrupt-driven RISC controllers and flow-oriented digital signal-processing engines are needed.

Working with both RISC and DSP architectures poses some programming difficulties for developers, however. First, they often must juggle distinct development environments: While RISC devices are control-oriented and C-friendly, DSP engines require difficult, data- and math-intensive machine code "inner loop" programming. In addition, code development must be done in a heterogeneous multiprocessor environment, with at least two or more compute elements.

In consumer segments, there is some commonality of architecture on the RISC side: Many designs are based on processor cores licensed from either MIPS Technologies Inc. or ARM Ltd.

But on the DSP side, there is no such commonality, nor is there consensus on how to build a converged DSP/RISC architecture-much less how to program one efficiently while producing a bug-free product.

In an effort to simplify the development process, various companies are offering a range interesting approaches.

"In the past, the complex programming issues posed by high-power DSP and RISC/DSP engines concerned developers of designs at the bleeding edge of computing," said Roger Hosking, vice president of marketing at Pentek Inc.

"Now it is the mainstream. Pick up your average commodity mobile device or portable media player, and you will find an incredible mix of multiprocessor configurations and converged processor solutions: single microcontroller units with additional instructions and hardware blocks for DSP operations, dual MCU/DSPs with dual or single instruction streams, very long-instruction-word DSP engines with event-control capabilities, VLIW RISC engines with special DSP modes."

For example, Microchip Technology Inc., when developing its 16-bit digital signal controller family, sought to preserve the familiar MPLab integrated development environment (IDE), which the company had developed for its 16-bit Pic Micro MCU. Microchip chose an architectural approach that maintained a single program flow, with as few changes in the instruction set architecture as possible.

Analog Devices Inc., for its part, is focusing on its Blackfin converged RISC/DSP architecture, in addition to a range of DSP engines. Texas Instruments Inc. has cast a broader DSP/RISC net: The company has a variety of converged engines, including Omap, for the mobile and portable media player segments. And Freescale Semiconductor Inc. addresses some of the same markets with an array of DSP and RISC/DSP platforms, including its ARM-based i.mx consumer computing platform.

Like Microchip, Atmel Corp. is targeting multimicrophone sound processing for home, auto, office and medical applications. But rather than adapt its 8-bit AVR and 32-bit ARM microcontrollers to DSP, it has jumped into the high-end 32-bit converged-DSP/RISC segment with the Diopsis 740 dual-core engine. The device combines an ARM7TDMI RISC with the company's proprietary Magic floating-point 1-Gflops VLIW DSP.

Matching IDEs to hardware
On the support front, third-party software companies are working with silicon vendors to supply developers with the necessary linkers, debuggers and compilers for converged designs. But as yet there is no industrywide consensus on how to do efficient code development for both the RISC and DSP portions. There are IDEs, but they have been developed by the silicon vendors and are therefore usually specific to the engines their creators provide.

For example, the platform for software development at Analog is VisualDSP++, adapted for each processor. At Texas Instruments, CodeComposer Studio is the basic tool framework: It is used as the umbrella under which all tools reside, whether they're third-party or generated by the processor design teams.

Freescale has taken a different tack. Rather than develop an IDE specifically for its various DSP/RISC and converged architectures, Freescale acquired Metrowerks, whose third-party CodeWarrior IDE now serves as the umbrella under which all Freescale processor code development can be accomplished.

Unlike Analog Devices, Freescale or TI, whose architecture-specific IDEs allow room for third-party software vendors and their tools, Atmel is supporting Diopsis with internally developed tools. According to Pier Stanislao Paolucci, technology director at Atmel Roma, the company's Made IDE allows development of C-language RISC and DSP code in the same program flow.

Most of the familiar third-party IDEs still extant are focused on the RISC side of the equation, for a simple reason: The RISC architectures are not so different from one another that each requires a distinct methodology. That is not the case with the DSP and converged DSP/RISC environments, however, where architectures are specific to applications and markets.

Third-party IDEs are usually tied to a particular underlying real-time operating system. But while there are a few OSes, such as ThreadX from Express Logic and Green Hills Software, that are sufficiently lean to provide the real-time responses that DSP engines require, most IDE support still skews to the RISC side.

Quadros Systems Inc. has been one of the few companies to take on the challenge of converged RISC/DSP architectures in a multiprocessing environment. The company's multiprocessing RTXC/mp and RTXC/dm RTOSes are designed for applications with multiple DSP/RISC cores, such as Freescale's i.mx, Analog Devices' Blackfin and TI's Omap.

Help is on the way
What are the chances of a converged IDE that is independent of the underlying OS and/or processor architecture-one that will allow developers to move from one environment to another without the expense and time required to come up to speed on new tool methodologies?

Not great, if you are depending on leadership from chip vendors. "While the major semiconductor companies are spending a lot of money on tools that help developers, most of that effort is focused on supporting their own architectures," said Pentek's Hosking. "It is not in their interest to help developers move seamlessly, or relatively so, between architectures built by others."

The one IDE that up until recently offered some possibility of being flexible enough to accommodate diverse tools, OSes and architectures was Wind River Systems Inc.'s Tornado. The product supported development of a range of RISC engines that used the VxWorks RTOS.

Wind River has replaced Tornado with Workbench, however, and the framework for Workbench is virtually identical to the Java-based backplane used with Eclipse. Originally developed by IBM Corp. to tie together all of its internal tools, Eclipse is now an open-source IDE. Many embedded-software companies, rather than continue development of their own frameworks, have adopted the environment.

Tools are in the works that will run within the Eclipse open-source IDE to support DSP and DSP/RISC co-development. Mark Buccini, marketing manager for advanced embedded controllers at Texas Instruments, said the company is looking closely at integrating its tool environments with Eclipse. "TI has a fundamental belief in the importance of open standards in this new, converged marketplace," he said, "and Eclipse shows signs of becoming a very important factor."

The approval of the Device Software Development Platform (DSDP) project last month by the Eclipse.com board of directors increases the likelihood that Eclipse will fill such a role. According to Mike Milinkovich, executive director of Eclipse Foundation Inc., one of the first subprojects to be started under DSDP is the creation of a common debug model, interfaces and views that will work with the many available debug engines to support conventional RISC, digital signal and network processors.

To develop an architecture-independent way to address these issues, a continentwide consortium of universities and companies is being formed in Europe. According to Atmel's Paolucci, the basic idea behind the Scalable Software Hardware Architecture Platform for Embedded Systems (Shapes) is to develop a model-based de-sign environment for embedded DSP/RISC multiprocessor applications.

Yet another way that software developers can achieve the functional equivalent of a common development environment, said Pentek's Hosking, is to move back up to the system level, using a graphical framework to define the problem and letting a modeling engine create the underlying code.

"That is what is happening with high-performance FPGA-based DSP designs," Pentek said. "Rather than get involved in the underlying hardware implementation issues, many developers are moving to high-level graphical environments such as Mathworks to avoid the coding complexities involved. The same thing is happening in the mainstream at the boundary between DSP and RISC in these so-called converged platforms."

Higher-level abstraction
Riding that trend is National Instruments Inc., which has within the last month introduced two extensions of its LabView Graphical Design Environment. One is for 32-bit embedded RISC development and the other for DSP.

"Several things are driving interest in higher-level design tools that remove the developer from the intricacies of coding details," said Gerardo Garcia, real-time product manager at National Instruments. "One is this divide between RISC/DSP and ways to bridge it in an efficient way. Another is the shortage of software developers to match the growing demand, especially in the converged DSP/RISC area. A third is the growing importance of knowledge domain and algorithm expertise over software-coding expertise.

"The only way to bridge these gaps and allow domain experts to focus on the algorithms, rather than the specific coding, is to move to a higher-level system design methodology."

Bernard Cole (bccole@acm.org), Embedded.com editor and partner in the Techrite Associates LLC writing consultancy (www.techrite-associates.com)