Jeff Bier’s Impulse Response—Are DSPs Dying?

Submitted by Jeff Bier on Wed, 06/12/2013 - 22:01

Recently I heard a presentation from a start-up chip supplier promoting a new type of programmable architecture for baseband processing in cellular base stations and handsets. The company's CEO contended that digital signal processors (DSPs) are becoming passé, soon to be replaced by more modern architectures. This caused me to think about the future of DSPs.

Industry pundits have been heralding the death of DSPs for over a decade.  And there's some evidence to support their view. For example, one-time DSP stalwarts like Freescale have stopped developing new DSPs, and there are fewer digital signal processor chips available for general-purpose use than was the case a few years ago. Often it seems that DSPs occupy a shrinking middle ground between CPUs and more specialized kinds of processors, such as image signal processors. On one hand, DSPs are more difficult to use than CPUs, and on the other hand, they’re not as powerful or efficient as more specialized architectures. So it's tempting to choose a CPU over a DSP on the basis of ease of use, or to choose a more specialized architecture over a DSP on the basis of greater efficiency.

Shipment volumes, however, tell a very different story. According to estimates from market research firm Forward Concepts, for example, Qualcomm alone shipped about 1.5 billion DSP cores (2.4 cores per chip, on average) in 2012, and recently unveiled the fifth generation of its “Hexagon” DSP family.  Meanwhile CEVA, a company that has built its business on licensing DSP cores, is thriving, reporting 2012 revenue of $54 million and a profit of $14 million. And Tensilica, another provider of licensable DSPs, was acquired by Cadence for $380 million in April.

How can we reconcile these seemingly contradictory trends? The answer is that DSPs have not died --  they’ve simply gone underground. Ten or twenty years ago, a digital signal processor was a chip. The chip consisted of the processor core, some memory, and I/O interfaces. Today, a DSP is usually one element of a system-on-chip, crammed with dozens of other features into a highly integrated chip, such as a mobile application processor or a hearing aid ASIC.

In this SoC era, the value proposition for DSPs has shifted: it's less about performance, and more about energy efficiency. For example, the DSPs in Qualcomm’s Snapdragon application processors run at a fraction of the CPU clock speeds on those same chips. But the DSPs are able to deliver significantly better performance per watt on many tasks. That’s a very valuable distinction in a world where smartphone users want to do more and more with their phones (including more multimedia functions) without needing to find a power outlet every few hours.

This coprocessor niche is a comfortable place for DSPs, in part because DSPs are more difficult to use than general-purpose processors. This stems from their specialized architectures (which require extra effort and knowledge to use efficiently) and limited software tools. (Surprisingly, there are still DSPs being designed-in today that lack a C compiler!) When a DSP is used as a coprocessor -- in a mobile application processor, for example -- very few people directly program that DSP.  Instead, most system and software developers who use these chips utilize the DSP indirectly, for example, via software component libraries or application development environments that hide the DSP behind benign application programming interfaces.

While the coprocessor niche is a comfortable one for DSPs, it isn't a good foundation for future growth.  Over time, the functionality of a typical SoC will continue to increase. If DSPs don't similarly expand the range of tasks they perform, eventually their functionality will become a negligible fraction of the total, and be absorbed by other types of processing engines with broader capabilities. The only way  DSPs will keep up -- in terms of broadening the tasks they run -- is if they are supported by very strong software development tools and a growing developer community. If DSPs are relegated to an SoC coprocessor role, however, there is little incentive for vendors to invest the tens of millions of dollars required to create state-of-the-art software tools, and there is little incentive for newly minted engineers to build careers around mastering DSPs.

So today, clearly, DSPs are neither dead nor dying. On the contrary, they are a booming business. But they are thriving in a different mode than in past decades. Rather than being general-purpose digital signal processor chips, today the vast majority of DSPs are coprocessors in highly integrated SoCs. That's good for business today, but it doesn't bode well for the future of DSPs.

Jeff Bier is president of BDTI and founder of the Embedded Vision Alliance. Post a comment here or send him your feedback at


mbutts Thu, 06/13/2013 - 07:42

There was once a time of minicomputers, which had no floating point arithmetic hardware, and floating point accelerator boards were a lively and profitable business. Eventually minicomputers got hardware FP. The same evolution happened in microprocessors. (8087's weird stack architecture remains part of the x86 ISA to this day.) Now even some $1 microcontrollers have floating point hardware.

DSPs followed the same evolutionary path. FP accelerators and coprocessors matured into DSP computers (anyone have an FPS AP-120B?) and then the DSP chips we know well. Now DSPs are subsumed into ARM cores everywhere. Compilers target them well and most developers don't think much about DSP architectures or instruction details.

The most interesting form of DSP today I think is the FPGA DSP block. Even $20 Spartans and Cyclones have dozens of DSP multiply-accumulate datapaths in hard silicon among the programmable logic and memory blocks. Big FPGAs can have thousands. Altera just announced future DSP blocks with hardware floating point. System level design tools like Simulink can use them effectively.

That wheel just keeps on turning.

Add new comment

Log in or register to post comments