Application development in a converged DSP/RISC environment

Application development in a converged DSP/RISC environment
By Bernard Cole, Embedded.com
Jul 4 2005 (9:00 AM)
URL: http://www.embedded.com/showArticle.jhtml?articleID=165600337

Many of the "hot" application areas in today's connected computing environment are embedded applications in consumer, home and industrial electronics that require the capabilities of both interrupt-driven RISC controllers and flow oriented DSP engines.

Unfortunately from a programming point of view, developers are often faced with two distinct development environments, one for control oriented and C-friendly RISC devices and another for DSP engines, with their data- and math-intensive, but often subtle and difficult machine-code "inner loop" programming requirements. Complicating their jobs, code development must be done in a heterogeneous multiprocessor environment, with at least two compute elements and sometimes more.

In consumer segments, there is some commonality of architecture on the RISC side, with many designs being based on processor cores licensed from either MIPS Technologies or ARM Ltd. On the DSP side, there is no such commonality, nor is there any consensus on how to build a converged DSP/RISC architecture, much less how to program one efficiently and bug free.

But help may be coming, and from unexpected quarters.

A diversity of converged DSP/RISC solutions
"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 MCUs with additional instructions and/or hardware blocks for DSP operations, dual MCU/DSPs with dual or single instruction streams, VLIW DSP engines with event-control capabilities, VLIW RISC engines with special DSP modes, to name a few."

For example, at Microchip, the aim in the development of its 16-bit Digital Signal Controller family was to preserve the familiar MPLab Integrated Development Environment (IDE) the company had developed for its 16-bit Pic Micro MCU. The architectural approach chosen was to maintain a single program flow, with as few changes in the Instruction Set Architecture as possible.

At Analog Devices, Inc., in addition to a range of DSP engines, the company's focus is on its Blackfin converged architecture. Casting a broader DSP/RISC net is Texas Instruments, which has a range of converged engines, including OMAP, for the mobile and portable media player segments. Similarly, Freescale addresses some of the same markets with a range of DSP and RISC/DSP platforms, including its ARM-based i.mx consumer computing platform.

Atmel Corp. is targeting some of the same home/car/office/medical multi-microphone sound processing applications as Microchip is. 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, combining an ARM7TDMI RISC with its proprietary mAgic floating point 1-GFLOP VLIW DSP.

Matching IDEs to the hardware
Third party software companies have been working with silicon vendors to supply developers with the necessary linkers, debuggers, and compilers for these converged designs. But there is no industry wide consensus yet on how to do quick and efficient code development for both the RISC and DSP portions of a design. There are IDEs, but they have been developed by the silicon vendors and are usually specific to the engines they provide.

For example, the platform for software development at Analog is VisualDSP++, adapted for each processor. At Texas Instruments, the basic tool framework used as the umbrella under which all tools, either third party or generated by the processor design teams is CodeComposer Studio. Freescale, rather than develop an IDE specifically designed for its various DSP/RISC and converged architectures, instead acquired Metrowerks, whose third party CodeWarrior IDE now serves as the umbrella under which all Freescale processor code development can be done.

Unlike Analog, Freescale or TI, which in their architecture specific IDEs have made room for third party software vendors and their tools, Atmel is supporting Diopsis with internally developed tools. According to Pier Stanislao Palolucci, Technology Director, Atmel Roma, while there are dual processors in the design, the company's MADE IDE (see Figure below)) allows development of C language RISC and DSP code in the same program flow. "The designer can write in serial fashion in C-code and the assembler schedules optimized code that takes advantage of the DSP VLIW instruction level parallelisms, " he said, "taking into account data dependencies and latencies automatically, without any programmer intervention.

Most of the familiar third party IDEs still extant are focused on the RISC side of the equation for a simple reason: the architectures are not so different that each requires totally different methodologies. Not so within the DSP and converged DSP/RISC environments where architectures are specific to particular applications and markets.

These third party IDEs are usually tied to a particular underlying RTOS. But while there are a few OSes, such as ThreadX from ExpressLogic and Green Hills, which are sufficiently lean to provide the real time responses that DSP engines require, most IDE support is heavy on the RISC side. One of the few companies to take on the challenge of converged RISC/DSP architectures in a multiprocessing environment has been Quadros, with its multiprocessing RTXC/mp and RTXC/dm RTOSes designed for applications with multiple DSP/RISC cores (see Figure below), such as Freescale's i.mx, Analog Device's 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 and which 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 very likely if you are depending on leadership from the semiconductor 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 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's Tornado, which supported development on a wide range of RISC engines that used its VxWorks RTOS.

Based on the use of TCL (Tool Command Language), a common Internet scripting language, as a software backplane, it allowed the company to quickly integrate a wide number of tools and software environments into the framework. Although access was closely guarded, the backplane allowed anyone with sufficient TCL experience to add their own proprietary tools and software building blocks to the environment.

However, TCL-based Tornado has been superseded by Workbench, for which Wind River has opted to use a framework that is virtually identical to the Java-based backplane used by the open source Eclipse. This latter framework uses Java plug-in mechanisms to incorporate tools that span the software development lifecycle, including support for modeling, language development environments for Java, C/C++ and others, testing and performance, rich client applications and, of course, embedded development.

Originally developed by IBM to tie together all of its internal tools, Eclipse is now an open source IDE tool environment which many of the embedded software companies have adopted, rather than continue development of their own frameworks.

Although neither Workbench nor Eclipse currently have extensive support for either DSP or converged DSP/RISC development, said John Bruggeman, chief marketing officer, Wind River Systems Inc., there is nothing to prevent third party vendors, silicon providers, or OEM developers from adding the appropriate enhancements to the openly available framework. "Within Workbench, both VxWorks and Linux are supported, and while neither are optimized for DSP code development, it also supports ExpressLogic's ThreadX, which has been used in DSP applications.

Because of the nature of the targets for which ThreadX has been optimized, said John Carbone, vice president of marketing at Express Logic Inc., that RTOS has been used in a number of DSP and converged DSP/RISC environments and incorporates support for both types of code flows, including a variety of third party and in-house tools.

Future integration of tools within the Eclipse open source IDE to support DSP and DSP/RISC co-development are in the works. Mark Buccini, marketing manager for advanced embedded controllers, at Texas Instruments, said that the company is looking closely a 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. "

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

And in Europe, a continent-wide consortium of universities and companies is being formed, called SHAPES (Scalable software Hardware Architecture Platform for Embedded Systems), to develop an architecture-independent way to address these issues. According to Paolucci, Technology Director, Atmel Roma, the basic idea behind SHAPES is to develop a model-based design environment for embedded DSP/RISC multiprocessor applications.

"Basically SHAPES will allow multiprocessor applications to be described in terms of a set of interacting components which can be automatically mapped by a Distributed Operation Layer (DOL)," he said. "The DOL is designed to use a set of pre-characterized components enriched by non-functional constraints, such as the number of processors, communication schemas, execution time profiling, and whether the operating processor is event control oriented or DSP flow control oriented."

Yet another way software developers can achieve the functional equivalent of a common development environment, said Pentek's Hosking, is to do move back up to a system-level and use a graphical framework to define the problem and let an underlying modeling engine do the creation of the underlying code.

"That is what is happening with high performance FPGA-based DSP designs: 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," he said. "The same thing is happening in the mainstream at the boundary between DSP and RISC in these so-called converged platforms."

Riding that trend is National Instruments, Inc., which has within the last month introduced two new extensions of its LabView Graphical Design Environment, one for 32 bit embedded RISC developmentand a second one 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, Inc. "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."