Feature

Logical combination?

Convergence products need both RISC and DSP processors, but merging them may not be the answer.

Richard A Quinnell, Contributing Editor -- EDN, 1/23/2003

As convergence continues to drive communications and multimedia functions into more and more devices, product-development teams face a daunting challenge. They must build in ample capacity for both general-purpose processing and specialized signal processing while also adhering to cost, size, and power commandments.

Meeting this tall order has often meant including both a data-oriented RISC processor and a specialized DSP (digital signal processor). But in recent times, RISC processors have become fast enough—and thus powerful enough—that they appear to threaten purebred DSPs. Meanwhile, chip vendors are cooking up recipes that blend RISC and DSP elements in various proportions.

Are such concoctions palatable? Or is this a case of never the twain should meet? When it comes to combining RISC and DSP, today's product team enjoys more options than ever before. That's great news, but it also translates into more gut-wrenching decisions.

This air of competition arose as RISC processors began pushing their clock speeds toward 1 GHz. At the same time, interest in signal-processing functions, such as digital audio and modems, increased. The mainstreaming of these signal-processing applications, along with the growing surplus of conventional processing power, turned RISC and DSP into competitors for the same sockets.

“The majority, if not all, applications need...a combination of abilities: decision-making, a robust user interface, and real-time performance for multimedia, communications, and the like.”
Andrew Soukup, Texas Instruments

The trend has accelerated in the last few years, as DSP functions became increasingly commonplace in embedded systems. "The embedded world is moving from data processing to signal processing," says Stefan Steyerl, strategic marketing manager at Analog Devices. "Data processing dominated the last decade, but growing interest in different media, networking, and wireless is driving it toward signal processing." Victor Berrios, strategic marketing manager for Motorola's DSP operation, agrees. "Applications that have traditionally been handled by 8- and 16-bit microcontrollers are needing extra performance and some analog processing as requirements increase," he says.

Why can't one type of processor handle everything? In theory at least, it can. The early descriptions of digital computers by mathematician Alan Turing indicate that any such "Turing machine" can be programmed to behave like any other. With a fast enough clock, then, a RISC device can do everything a DSP can do, and vice versa.

"In the limit that's a true statement," says Joe Circello, Motorola's chief architect for its Coldfire processor. "But practical applications have a tremendous sensitivity to cost and power. You wouldn't use a 2-GHz processor that costs several hundred dollars to handle an application being served by DSPs that cost $10. The best solution will depend on the application environment."

Evolutionary paths

The two processor architectures certainly evolved for different application environments. RISC processors support bit-and byte-wide operations, necessary for designs in which interpretation of binary data varies from word to word. Control functions, where individual bits represent signals from sensors and to switches, need such flexibility of interpretation. So do networking functions, where each byte in a stream of data has a different use. This flexibility of data interpretation also makes RISC systems well suited to running operating systems and user interfaces, where one word may represent a character of text while the next is the color palette of an image pixel. Flexibility sacrifices efficiency, however, making the RISC processor a jack-of-all-trades but master of none.

DSPs, on the other hand, are built specifically for efficient computation, with binary data usually representing numerical values having a consistent interpretation. Because the data is all in the same format, DSP architectures can maximize their speed of operation, adding hardware accelerators where the data's interpretation is fixed in the logic. This consistency of data format allows great numerical processing throughput, but makes the DSP poor at handling information in other formats, such as control signals.

When these architectures were first developed, they targeted entirely different applications. But convergence is changing that. "The majority, if not all, applications need some of both," says Andrew Soukup, program manager for the OMAP product line at Texas Instruments. "They need a combination of abilities: decision-making, a robust user interface, and real-time performance for multimedia, communications, and the like. Every semiconductor manufacturer looking at these applications is looking for a combination of abilities, and they have come up with a variety of solutions."

Double trouble

The most intuitive solution is to use two processors: one RISC CPU and one DSP. But this approach has several drawbacks. One is simply the extra cost of a second processor and its memory in terms of component expense, board space, and power.

A second, and more subtle, drawback is the cost of software development. "Where the dual processor design comes up short is in the development environment," says Brett Black, DSP marketing manager at Motorola. Two processor architectures means two different tool chains and parallel software-development efforts that are difficult to blend. "A common tool chain would make software development easier," Black says. "Instead, you end up with separate compilers that historically have been hard to integrate."

To address these issues, semiconductor manufacturers have made numerous attempts to combine the two architectures. These generally break into three categories: a DSP-enhanced RISC CPU, a control-enhanced DSP, and a new, blended architecture. Each has found its own application niche.

“There are designs where a CPU has been stretched to do DSP, and at the low end that’s enough. It’s if you try to do too much that you run into problems, mostly with power consumption.”
Victor Berman, Improv Systems

Vendors starting with a RISC architecture typically begin by adding MAC (multiply and accumulate) hardware to their design, because that is a major function essential to all DSP algorithms. Often, that's as far as they go. "If you take a general-purpose processor and add a MAC, you've covered most of what you need," says Tom Riordan, vice president and general manager of the MIPS processor division at PMC-Sierra.

Not everyone fully agrees. "This is just the tip of the iceberg," notes Brian Carlson, marketing manager for the ZSP product at LSI Logic. "A MAC may give the [chip] 20 to 30 percent better performance, but DSPs still run many times faster." Victor Berman, director of marketing at Improv Systems, takes a moderate stance. "There are designs where a CPU has been stretched to do DSP, and at the low end that's enough. It's if you try to do too much that you run into problems, mostly with power consumption. To do DSP you have to boost the processor's clock rate, because it's a very inefficient way of doing it."

Yet for many applications, a 20 to 30 percent boost in performance is all that's needed. In this category you'll find devices that have complex user-interface or system-control functions and that also need simple modems or the ability to handle basic media such as audio and still images. Examples include audio players, Internet appliances, and basic PDAs, as well as printers and copiers.

At the other end of the spectrum are parts that started from a DSP and added control features. They, too, have a place. "A characteristic of those applications," says TI's Soukup, "is that they don't need a high-level operating system and don't have a high level of real-time requirements. They need mid-level signal processing with high integration for cost effectiveness." Digital motion control is a prime example of an application for such enhanced DSPs.

Reaching the limit

To handle applications where the blend of signal processing and control needs is more balanced, however, simple enhancement of an existing RISC or DSP architecture quickly runs into problems. "You pay a big penalty when an architecture is extended where it's not meant to go," says Bob Markunas, vice president of market development at Ziptronix. "DSPs trying to do control burn power because they're wasting all their computational hardware. RISC processors doing DSP have low performance. When you try to extend an architecture you just end up with a case of bloat."

That leaves the third approach: a hybrid architecture that handles DSP and control operations with balanced facility. "People want to move to a hybrid because it allows the adaptation of a design's features to a wider range of applications, both for DSP and control," says Motorola's Black. "It also allows an integration of function types."

This integration comes about because the hybrid processor uses a single tool chain and produces a unified code, making the coordination of tasks easier. Designing with a hybrid processor can also help to futureproof designs. Developers can avoid having to make an architectural shift away from RISC as their product's needs for signal-processing performance grow. "It used to be that if you needed more performance you had to jump to a 24-bit DSP," says Motorola's Berrios. "The blended architecture allows designers to still experience the RISC environment," adds Black. "It's somewhat of a half step into the realm of higher performance."

The blended architecture isn't as optimized for computation as a DSP, but it is more than a RISC processor with a MAC attached. "In a blended architecture you find both types of features," says Finbarr Moynihan, product line manager at the DSP division of Analog Devices. "It has the hierarchical memory and pipelining of a CPU with the hardware pointers and special addressing modes of a DSP to access data efficiently. There's no point in having a MAC if you can't get the data in and out fast enough."

Duality wins

Despite its advantages, the blended-processor approach hasn't caught on for most high-volume applications. One reason is that it does represent a compromise in performance. The blended architecture is well suited to applications that have modest signal-processing requirements, such as wireless messaging and industrial systems like bar-code scanners. But high-performance applications, such as digital video, need more. "When you get into higher-performance applications, the blended architecture starts to fall down," Black observes.

What many vendors are thus realizing is that even with all its difficulties, the dual-processor approach remains the best way to tackle leading-edge convergence applications. "Using dual processors lets you get the right architecture doing the right job," says Ziptronix's Markunas. "You can't do better than that. The middle ground, while incremental and seductive in that respect, will lose out to a dual architecture."

Embracing the dual architecture brings vendors right back to the problems—size, cost, and development effort—that prompted the search for a unified architecture in the first place. Their latest answer to the size and cost problem, at least, is straightforward: Use two processors, just put them on a single chip.

“The market is broad, and there will be an area where each approach fits.”
Brian Carlson, LSI Logic

With today's SOC (system on chip) process technologies, the dual-core chip can offer cost and size advantages similar to that of a hybrid architecture. "Processors are pretty cheap, and you can add a second core for very little money," says Improv's Berman. "Chip cost is typically set by gate count. To build a DSP/RISC hybrid you would need pretty much the same gate count as for two processors."

Ian Ferguson, strategic marketing manager for IDT's integrated processor division, goes further, pointing out that the second core doesn't add that much overhead to a chip. "There is enough space to put multiple processor cores on chip," Ferguson says. "In fact, buses and memory take up most of the room." Motorola's Black agrees. "Memory and peripherals drive die size," he says, "not cores."

As to the software-development concerns, they may be sorting themselves out. Silicon vendors have recognized the impact of software development on processor design wins and are trying to make development easier. "Silicon drove the business a few years back," notes Motorola's Berrios. "Now the development environment and software availability are becoming important. So, we're providing algorithms, drivers, and sample applications code."

Vendors are also trying to structure their tool sets to simplify software development. For its new OMAP product, for instance, Texas Instruments has created a software-development approach that turns the DSP into a coprocessor for the ARM core. "The heart of the software infrastructure is a DSP-BIOS bridge," says OMAP program manager Soukup. "Developers program the ARM architecture in its native tools, then set up and control DSP tasks using API calls in the BIOS bridge."

Familiarity breeds contentment

Time is also helping to lessen concern over software development. Developers are becoming accustomed to multiprocessor designs and dual software efforts, and are starting to prefer them. "There's a lot of inertia due to existing designs," says Improv's Berman. "People tend to not want to make radical changes to those designs unless they have to. Our early architecture was a blend, and there was a lot of resistance to it. It's not the way people want to design. There's a lot of investment in DSP software, RISC operating systems, and interface code that people want to preserve."

With cost and software issues apparently resolving, the once-maligned dual-processor approach is becoming the design of choice for convergence applications, at least for now. Looking ahead, vendors foresee chips with three or more processor cores as the next logical step. "The trend is to have a control processor and one or more signal processors," says IDT's Ferguson. Bob Payne, deputy chief technical officer at Philips, agrees, noting "all of our digital media platforms have both a RISC and a DSP. Future video platforms will have two DSPs, and we see a megatrend toward even more, offering lots of parallel computing."

“When you get into higher-performance applications, the blended architecture starts to fall down.”
Brett Black, Motorola

One of the motivations for this trend is the desire to increase performance without increasing clock rates and, by extension, power demands. "We'd rather have 10 processors at 100 MHz than use a gigahertz machine," Payne says. "The gigahertz machine needs a relatively high supply voltage, while the 100-MHz devices can run at a minimum voltage." Because power varies with the square of the voltage, keeping the voltage down more than offsets the power demands of the added circuitry.

Evolving elements

The desire to increase performance is also affecting the nature of the signal processing elements. They are becoming simpler and more focused. "Rather than time-share a fast machine, use lots of simpler dedicated machines, computing in space rather than with time sequencing," Payne says. Designers would use these simplified processors to handle individual signal-processing tasks, each working on its own data stream. The design would employ as many processing elements as needed to handle the application.

Some of the newest architectures starting to enter the market are embracing this approach, providing a controller core with a collection of configurable signal processing elements in a single chip. Elixent, for instance, combines a RISC CPU with an array of 4-bit ALUs (arithmetic logic units) in its D-Fabrix device. Intrinsity offers a MIPS core with a configurable matrix computation engine in its FastMath adaptive signal processor. Chameleon Systems has an ARC core with a collection of 108 computational units in its reconfigurable communications processor.

While the emergence of these new architectures underscores the continued viability of the separate-processor approach for designs with both control and signal-processing needs, it does not necessarily signal a demise for any of the alternatives. Whether it's a dual core, enhanced DSP, RISC with MAC, or blended architecture, all of the products remain viable for certain classes of applications. "The market is broad, and there will be an area where each approach fits," notes LSI Logic's Carlson. "It always comes down to performance, power, price, and ease-of-use," adds TI's Soukup. "And having the right processor for the right task supports all of these."


Author Information
Contributing Editor Rich Quinnell's first processor-based design ran at the then-astounding speed of 1 MHz. His DSP was built entirely out of logic gates.



ADVERTISEMENT

ADVERTISEMENT

Feedback Loop


Post a CommentPost a Comment

There are no comments posted for this article.

Related Content

 

By This Author


ADVERTISEMENT

Knowledge Center



Technology Quick Links

EDN Marketplace


©1997-2008 Reed Business Information, a division of Reed Elsevier Inc. All rights reserved.
Use of this Web site is subject to its Terms of Use | Privacy Policy

Please visit these other Reed Business sites

ADVERTISEMENT
You will be redirected to your destination in few seconds.