30 years of DSP: From a child’s toy to 4G and beyond

As Texas Instruments principal fellow Gene Frantz tells it, the aha moment for the company’s DSP pioneers came in the late 1970s, shortly after TI’s seminal Speak & Spell learning toy hit retailers’ shelves. Frantz recalls that a customer asked, “If you can [use DSP to] add speech synthesis to a toy, what else can you use it for?”

This year, as TI celebrates its 30th year in the DSP market, that long-ago question has been answered many times over. Without DSP and the advances it has enabled in audio, graphics, and multimedia processing, there would be no “infotainment” content, no smartphones or tablets, no Internet or ecosystem of apps.

TI’s “toy” technology not only moved the company into a new business but set the stage for developments by TI, its competitors, and tool vendors that have pushed DSP technology into diverse applications and markets. At the same time, traditional DSP devices have seen competition from an array of alternative signal-processing platforms, including CPUs with DSP-oriented features; digital signal controllers, which pair a DSP core with an MCU; FPGAs, which can be used to design custom data paths for digital signal processing or even to create custom programmable processors; and, most recently, massively parallel processing graphics processors that can tackle data-parallel problems.

Figure 1: TI’s Speak & Spell team—from left, Gene Frantz, Richard Wiggins, Paul Breedlove, and Larry Brantingham, showing off the product at its introduction—went on to push DSP technology into diverse applications and markets.

Partner Content

Precision Timing Special Report

10.19.2026

HUSB237: The Cost-Effective PD Sink with Just 2 Passives

10.15.2026

Co-Packaged Optics Moves from Promise to Production Planning

10.14.2026

The roots of DSP technology predate the Speak & Spell by several years. In the early 1970s, scientists began using off-the-shelf TTL discrete logic chips to implement specialized signal-processing “engines.” The early systems were relatively slow and consumed a lot of space. TRW shipped the first practical parallel multiplier design in 1973 and added bit-slice ALUs two years later. But at several hundred dollars just for the multiplier chip, the only customers that could afford such a product were research laboratories, medical-scanning equipment makers, and the military.

In 1978, American Microsystems Inc announced the first single-chip IC designed specifically for DSP: the 12-bit S2811. AMI devised a truly innovative circuit design but implemented its chip in a radical “V groove” MOS technology that never yielded volume commercial products.

The following year, Intel Corp introduced the Intel 2920 16-bit “analog signal processor,” so called because Intel had designed the chip as a drop-in analog-circuit replacement, complete with on-board A/D and D/A converters. The 2920 processed analog signals digitally, but it lacked a parallel multiplier; what’s more, its 600-nsec cycle time made it too slow to perform useful work in the audio spectrum, where the first high-volume DSP chip market would eventually materialize.

The first “true” single-chip DSPs—which market-analysis firm Forward Concepts defines as having parallel MAC (multiplier-accumulator) circuits—emerged in early 1980 from Bell Labs and NEC. The Bell Labs chip, the DSP-1, was a captive device used in AT&T and Western Electric equipment. NEC’s µPD7720 was the first true single-chip DSP shipped in volume to the merchant market. Although hampered by primitive development tools, the NEC chip offered sufficient speed—a 122-nsec cycle time with a two-cycle MAC—to perform useful work in the audio spectrum.

In the late 1980s, Hiromitsu Yagi of Ricoh redesigned the original AMI S2811 chip for a conventional NMOS process. Yagi’s work resulted in the Ricoh RD28211 and the AMI S28211.

TI gets in the game

In 1980, TI’s Ed Caudel designed the initial architecture for what would become the company’s first digital signal processor. Surendar Magar was hired the same year to optimize the architecture around DSP algorithms. TI introduced the resulting design to the world in February 1982 in the classic International Solid-State Circuits Conference paper, “A Microcomputer with Digital Signal Processing Capability.” Caudel announced the final product, the TMS32010, in April 1982 in Paris at the International Conference on Acoustics, Speech, and Signal Processing.

After Speak & Spell launched, TI went on to develop DSP devices for a host of industries, but the key to the business, and ultimately to the growth of the market at large, was the ecosystem that emerged around the processors. “TI became the first company with a sophisticated signal-processing chip and also understood that the device [itself] was not the product; the product was the device plus support plus the development environment plus a device hotline,” says Frantz, one of the industry’s foremost DSP engineers. “We created a product for customers to use in their product.”

In the early years, TI’s DSP hotline was a great source of design help to customers, especially because in many cases the person who answered the phone was the architect of the device in question. “TI had some pretty large customers, and we were getting calls from six or seven different area codes from each of these big customers in different locations,” Frantz says. “We realized that we knew more about what each company was doing than they did. We did all we could to help them grow.”

There were also calls from many small start-ups asking the same questions, so TI began to see markets forming even before the players themselves picked up on the trends. The company spent the coming years inventing the next generation of signal processors to do the “crazy” things their customers wanted to do, as Frantz puts it.

Along the way, TI remained mindful of the “three P’s of value”: performance, price, and power dissipation. “Most people did not realize that power dissipation was that important,” says Frantz, “but we had been working on low-power device technology since the mid-’60s, when the calculator was invented.”

Early on, TI began its third-party program, marshaling small companies with DSP expertise to “fill in the holes” that TI could not address. Frantz describes the program as a “value Web,” through which all participants would make money while expanding the available customer-support network.

Fernando Mujica, director of TI’s System Architectures Lab and an expert in analytical embedded processing, is a member of the generation of engineers to whom DSP pioneers such as Frantz are passing the baton at TI. “Over the last 30 years, virtually every aspect of our lives has been influenced by DSP,” Mujica says. “Now, we are seeing the DSP take on embedded analytics tasks, a growing and evolving area demanding the highest degree of programmability. Signal-conditioning and -compression technologies are now implemented as hard-coded accelerators and integrated with DSPs in modern embedded processors.”

Current DSPs and other embedded processors tackle tasks that previously required human interaction. A case in point is the expanding range of automotive-safety features, including lane-departure warning and active cruise control, available in high-end vehicles. Such systems go beyond convenience features to warn the driver and even apply the brakes or steer the vehicle in an emergency.

“In the near future, embedded analytics solutions will make autonomous vehicles a reality,” Mujica says (Figure 2 ). “Robotics is another area that is about to be revolutionized by the increasing capabilities of embedded processors to take on complex analytics tasks.”

Figure 2: Future embedded automotive analytics will create autonomous vehicles.

To see how digital signal processing is integrated into many of TI’s offerings, take a look at TI’s high-performance, KeyStone-based multicore processors, single-core processors, and OMAP processors.

Low-power innovator

TI is not the only company to have driven DSP technology on the three P’s of value. Analog Devices Inc has consistently improved the power/performance ratios of both its fixed-point Blackfin processors, developed in 2001, and its floating-point Sharc processors, which emerged in the mid-’90s.

Designers are continually challenged to reconcile power-budget requirements with the need for greater processing precision. In response, ADI has focused on the efficient utilization of available power and has turned out progressively more compact designs, ensuring greater system portability, minimal real-estate consumption, and overall lower operating costs, according to Colin Duggan, ADI director of marketing for processors, and Richard Murphy, Blackfin product manager. The pair note that low power draw typically yields low heat dissipation, which can help ensure greater system reliability and minimize the need for both system‐ and room‐level cooling—with associated power, space, and cost savings.

For battery‐powered devices, low-power processors extend system battery life and time between charges, and help minimize system size and weight to ensure ease of portability. Reductions in processor power consumption also let designers use smaller batteries, maximizing power and space savings.

DPM (dynamic power management) in the just-announced BF60x high-performance family and previous Blackfin generations lets developers match the processor’s power consumption to processing requirements during program execution (Figure 3 ). ADI pioneered the application of DPM with the release of the first Blackfin processors in October 2001.

Figure 3: DPM in devices like this ADSP-BF609/8 lets developers match processor power consumption to processing requirements during program execution.

Other design techniques used in the Blackfin processors include programmable voltage and frequency scaling; clock-cycle-resolution dynamic clock gating; multiple power domains, to support deep-sleep and hibernate modes; high code density, to minimize bus-activation energy; mixed threshold-voltage transistor utilization, for optimal performance and power efficiency; a full-custom processor core, for maximum energy efficiency; judicious use of hardware accelerators; and support for metastable SDRAM, to minimize board-level power consumption.

On the floating-point side, ADI designed the recent Sharc 2147x with low-power consumption in mind. The processor’s 5-Mbit onboard memory lets designers conserve power that might otherwise be expended moving data across external memory and/or other processors. The series’ integrated memory and parallel-processing features enable performance gains that contribute to net power savings by ensuring that algorithms and programs execute faster.

Side-by-side comparisons, all showing typical power consumption at 25°C, help ADI make its case. In the Sharc family, the ADSP-21261, dissipating 900 mW at 150 MHz and 1.2W at 200 MHz, compares with the more recent ADSP-2147x family, dissipating 180 mW at 150 MHz and 363 mW at 266 MHz. In the Blackfin family, the BF527 draws 205 mW of core power at 600 MHz, with standby power in the 10-mW range and hibernate-mode power dissipation of ~40 μA; the more recent BF592 offers active power draw of 88 mW at 300 MHz, standby power of less than 1 mW, and hibernate power dissipation at 20 μA.

The company’s highest performance Blackfin BF609, with two 500-MHz cores, draws 400 mW at 1 GHz.

Duggan and Murphy note that ADI’s power-down features provide flexible user control and that newer process geometries are more efficient in power. They add that the company’s designers know the power envelopes for the applications its DSPs will need to meet. ADI’s goal is to enable the highest performance possible within a specific power envelope for the application. User-programmable PLLs, peripherals that can turn down their own system clocks, and the ability to turn off any clock domain in the absence of certain peripherals all save power. Other power-saving approaches include efficient busing architectures, maximizing the percentage of transistors in the design that are high-threshold-voltage transistors (93% is typical), and using the PVP (Pipeline Vision Processor) as an accelerator.

Microchip DSCs

Microchip Technology Inc takes an alternative approach to digital signal processing: the DSC (digital signal controller). The first step was to pair an 8-bit microcontroller with a DSP. Microchip engineers then integrated a DSP core with a PIC MCU to yield the 16-bit dsPIC in 2002 .

The scalable dsPIC solution offers patented MCU-like interrupt handling for real-time control, which otherwise is challenging to perform with a DSP, according to Microchip (Figure 4 ). The DSC core has a modified Harvard bus architecture, with a 16-bit-wide data path and 24-bit-wide instruction path; extensive addressing modes; a 16×16-bit general-purpose register set; a flexible software stack; single-cycle 16×16 multiply functionality; DMAC (direct memory-access control) with dual-port SRAM; and eight channels for peripherals.

Figure 4: The scalable dsPIC solution offers patented MCU-like interrupt handling for real-time control, which otherwise is challenging to perform with a DSP.

The DSCs run at speeds from 30 to 70 MIPS and serve markets such as digital power, lighting, motor control, speech, biometrics, sensor processing, and simple filters. The chips contain DACs for speech processing, motor-control PWMs, fast ADCs, and specialized ADCs for SMPS (switched-mode power supply) applications. Microchip says the parts leverage high op-amp integration and offer the “look and feel” of microcontrollers; designers do not have to learn DSP design or software to use them.

Microchip touts seamless migration from the dsPIC to the PIC24 microcontroller; the two are code- and pin-compatible. The same free MPLAB X integrated development environment is used for Microchip’s 8-, 16-, and 32-bit MCUs and its DSCs. The company says its strategy is to offer engineers simple solutions so that developers of applications such as digital power will be comfortable using the analog-friendly, highly integrated dsPICs.

Enter FPGAs

The transition to FPGA-based DSP hardware from conventional DSPs can involve a new set of design skills and a new understanding of hardware. For developers new to FPGAs or DSP, the shift can be a significant undertaking that adds risk to design schedules. A Xilinx white paper by senior manager Tom Hill, “Xilinx DSP design platforms: Simplifying the adoption of FPGAs for DSP,” shows how Xilinx’s DSP development kits are designed to ease FPGA adoption and let algorithm and hardware developers ramp up quickly when developing DSP applications on Xilinx devices.

In the 1990s, according to Hill, Xilinx designed the 4000 series FPGAs for DSP processing. Customers soon found they could build digital filters with FPGAs. Circa 1999, Bruce Newgard, at the time a field applications engineer at Xilinx, saw a great opportunity for the company, but management needed a bit of convincing before signing off on the formation of a DSP division within Xilinx.

By 2005, Xilinx had forged a DSP strategy that involved collaboration with TI and MathWorks to bring out FPGA/DSP coprocessing platforms and tightly integrated tool flows for algorithmic development and design implementation. The same year, Forward Concepts estimated that $2 billion of the high-performance DSP market could be addressed by the performance and flexibility of FPGA-based DSP solutions. Xilinx initially targeted high-growth digital communications, MVI (multimedia, video, and imaging); and defense systems. Combined, those areas account for more than 80% of the high-performance DSP market.

Xilinx teamed with MathWorks to develop System Generator, the industry’s first DSP plug-in for Xilinx FPGAs. Today, System Generator for DSP is a leading high-level tool for designing high-performance DSP systems using FPGAs.

With System Generator, according to Xilinx, developers with little FPGA design experience can quickly create production quality FPGA implementations of DSP algorithms in a fraction of traditional RTL development times. The tool provides system modeling and automatic code generation from MathWorks’ Simulink and integrates the RTL, embedded, IP, Matlab, and hardware components of a DSP system. System Generator for DSP is a key component of the Xilinx DSP Targeted Design Platform.

Xilinx changed its business model from horizontally based FPGA supplier to vertical applications and now operates specific market-segment groups. The next phase is algorithm-oriented platforms comprising tools, IP, silicon, and kits.

Xilinx FPGA-based DSP platforms now interface with real-world signals and have interfaces to high-speed data converters. Data is sampled at very high rates and then downconverted to simplify DSP hardware implementations. Hill noted that FPGAs had often been used in systems to handle interfaces and downconversion, but 40% of the time they were used with a DSP device.

Doubts about the technique’s ease of use and questions about the design flow have been stumbling blocks to adoption of FPGA-based DSP, so in January 2011, Xilinx bought AutoESL. The pairing yielded Xilinx AutoESL 2012.1, which made it easier for designers to get up to speed when implementing DSP systems with FPGAs and provided a smooth transition to the next generation of AutoESL technology: Vivado High-Level Synthesis 2012.2

With the introduction of the Vivado Design Suite, Vivado High Level Synthesis accelerates design implementation by letting developers target C, C++, and System C specifications directly into FPGAs without manually creating RTL.

Today, Hill notes, if you can do the design with a DSP, a customer will use a DSP; if the design calls for two or three DSPs, then FPGAs compete well. For heavy-duty filtering, FPGAs win. FPGAs perform up/downconversion and digital predistortion in wireless and radar and sonar countermeasures for the military. Medical imaging is another key area, with some CT scanning and ultrasound equipment having 256 or more sensors.

In March, Xilinx launched the Zynq-7000, touting “all programmable” SOC integration in a device that offers ASIC-like performance and power consumption, the flexibility of an FPGA, and the ease of programming of a microprocessor (Figure 5 ). The Zynq-7000 ecosystem includes hardware and software development tools and operating systems.

Figure 5: Zynq-7000 family includes hardware and software development tools, operating systems, and other elements.

In the future, Hill predicts, FPGAs will be the foundation for programmable ASSPs that offer an alternative to devices such as TI’s DaVinci digital media processors in select market segments.

Matlab’s role

Ken Karnofsky, senior strategist for signal-processing applications at MathWorks, notesthat “the DSP acronym stands for two different things: digital signal-processor hardware devices and digital signal-processing algorithms that operate on digital data. They have evolved alongside each other synergistically.”

Hardware designers are advancing the DSP IC and making it more efficient; algorithm designers are coming up with new algorithms that make new hardware possible and make applications possible for the jobs that need to be done. That is where Matlab comes into play.

“I was at a TI developers conference in the late ’90s/early 2000, and [pioneering DSP developer] Ron Schafer gave a keynote talk about the history and evolution of DSP. A milestone he cited was the invention of Matlab as a seminal point in the development of DSP technology,” Karnofsky says.

Matlab became commercially available in 1984, a few years after TI’s Speak & Spell and the first DSP devices. As the various developments opened the floodgates on research, the engineers who were working on DSP algorithms had a big influence on Matlab and vice versa. The fertile environment let to the addition of two Matlab toolboxes: Signal Processing and Control System. Writing DSP algorithms using Matlab was much easier than writing Fortran at the time, and Matlab thus became critical to the development of the DSP engineers’ concepts.

Over time, as DSP technology became more practical and the ICs became more capable, algorithm research became algorithm design and implementation—and engineers increasingly used MathWorks’ products in the design phase. As MathWorks started to introduce code-generation technology, the ability to get C code and ultimately HDL for FPGAs and ASICs bridged the traditional divide between hardware designers and embedded-software developers.

As the hardware became more pervasive and capable of running software applications that performed signal processing, there was more of a need to use Matlab (Figure 6 ) and Simulink in the design phase for real-time prototyping and, ultimately, for generating code that could be used in the device, according to Karnofsky. FPGAs have become important in signal processing as well, he notes; indeed, today’s powerful FPGA hardware can perform very high-speed processing, such as data conversion and modulation in a wireless base station. The challenge is that FPGAs are harder to program than DSPs. Thus, early on, the FPGA camp realized the need for a graphical approach and adopted Simulink as the design-entry mechanism, Karnofsky says.

Figure 6: Matlab supports specialized filter designs, such as an LMS adaptive filter applied to a noisy music signal (upper left), arbitrary magnitude filter (upper right), direct-form FIR-filter responses for fixed-point data types (lower left), and octave filter (lower right).

Engineers now can do design at a high level, experimentally optimize the algorithms, and then formulate them into hardware in an FPGA or software running on a DSP or general-purpose CPU. The original signal-processing toolbox essentially was a collection of fundamental algorithms, so engineers did not have to write their own filter algorithms or FFTs, Karnofsky says. MathWorks has added many more algorithms over time, with options that can be used later in the development process. “You can’t separate hardware from software,” says Karnofsky.

Much of the value-added content in SOC, and how you design the architectures for that, is becoming standardized. Thus, the differentiator for SOC providers is in coming up with DSP algorithms or better control algorithms that make their device a little bit smarter or power efficient, says Karnofsky. “One of my favorite examples of that is in wireless base stations, where they are trying to reduce the heat and power consumption, so they are looking at different types of power amplifiers in the transmitter that have undesirable linearity. You can use DSP techniques to compensate for that, such as filtering, predistortion, and envelope-tracking algorithms. What used to be analog signal processing has now gone digital, but there is still analog in that part of the design at the ‘apple pie’ center. So coming up with an environment where you can optimize across the analog and digital boundaries is crucial to customers.”

The bottom line, he says is that you can actually simulate and prototype the design now, instead of saying, “Well, it worked on paper, but it didn’t work in the lab.”

Synopsys and the virtual prototype

Dec 18, 2011, marked the 25th anniversary of EDA provider Synopsys Inc, which has been both witness to and participant in the evolution of signal processing. “DSPs are faster nowadays, but there are still some things they can’t do in software, because they are too power hungry or the function just will not work properly,” says Johannes Stahl, director of product marketing for system-level solutions at Synopsys.

Going forward, Stahl predicts, application processors will integrate a growing number of specialized DSP cores for specific applications such as embedded vision, even as the generic processing performance of microcontrollers and graphics processors continues to advance. Processors for gesture recognition in home-entertainment systems and image recognition used in automated driver assistance in vehicles are examples of the highly specialized DSPs that will be embedded into application processors serving specific markets. The overall goal of optimizing the user experience while keeping silicon cost and power as low as possible will continue to require interdisciplinary work for algorithm optimization, architecture design, and software development.

Stahl notes that the cell phone has been a key driver of signal-processing markets. The dominant architecture has shifted from a DSP with a small ARM controller on the side to an entire ARM processing subsystem, such as the recently introduced big.Little ARM architecture, supported by a few DSPs. The pairing of a large ARM processing subsystem and embedded DSP is an architecture that is now seen across the industry, and the integrated signal processing has been a differentiator for designs, Stahl says.

Signal processing used to program a single processor, whereas now multiprocessors need to be programmed, he adds. Years ago, chip vendors offered tools that allowed programming both the ARM core and the DSP, but the tools were crude. DSPs, being deeply embedded by nature, now require the vendor to supply a unified tool for debugging that is used in combination with a debugging solution for the ARM processing system.  

Synopsys’ Virtualizer addresses the increasing development challenges associated with software-rich semiconductor and electronic products by letting companies accelerate both the development and the deployment of virtual prototypes. The Virtualizer tool set targets (Figure 7 ) software developers as well as the hardware developers who use the VDK (Virtualizer Development Kit) for simulation.

Figure 7: The Virtualizer tool set targets software developers as well as hardware developers using the VDK (Virtualizer Development Kit) for simulation. The VDK prototype analyzer tool is shown.

Virtualizer is part of Synopsys’ next-generation virtual prototyping solution, which enables:

• Fast time to virtual prototype availability, via its large portfolio of transaction-level models and  designs, intuitive graphical prototype assembly and debug, and standard-based (SystemC/TLM) support and publishing capabilities;
• Virtual prototypes adapted to multiple end-user design tasks for optimal accuracy with support for multiple levels of abstraction;
• High debug and analysis efficiency through system-level software debug and analysis, hardware/software combined analysis, and synchronized integration with third-party software debuggers and embedded software development tools;
• Integration with adjacent flows, including SOC integration, hardware verification, and system validation and testing; and
• Services to accelerate modeling and virtual prototype creation, as well as prototype deployment, leveraging decades of experience.

Engineers can accelerate the design of specialized DSP cores by using specialized tools such as Synopsys’ Processor Designer, a set of automated software development tools for RTL and ISS (instruction set simulator) generation from a single, high-level specification (Figure 8 ). Processor Designer speeds the design of both custom processors and programmable accelerators, including the application-specific instruction-set processors that are increasingly essential to convergent SOC functionality, such as architectures with DSP-specific and RISC-specific features.

Figure 8: Processor Designer lets engineers generate SystemC models, software tools, and RTL code with one mouse click.

Synopsys supports multicore processors via its Multicore Optimization technology, which lets Platform Architect users create task-driven workload models of the end-product application. The models, known as task graphs, enable analysis and optimization of hardware/software partitioning and system performance. After finalizing hardware/software partitioning, architects reuse the same task graphs and task-driven traffic for SOC-level architecture exploration and IP selection, as well as interconnect- and memory-subsystem-performance optimization. Benefits reportedly include optimized multicore system performance, shorter evaluation times, and faster time to market.

The Multicore Optimization technology in Synopsys' Platform Architect enables the modeling of an application as a SystemC task graph and uses a VPU (virtual processing unit) to represent a processing element for the execution of a task graph (Figure 9 ).

Figure 9: Platform Architect enables application task analysis for early optimization of multicore systems.

An independent analysis

Jeff Bier, founder and president of Berkeley Design Technology Inc, offers an independent analyst’s view of the competitive landscape for processors used in digital signal processing. BDTI has been evaluating chips for DSP applications for 20 years.

According to Bier, the fundamental challenge in embedded digital signal processing is balancing the requirements of high performance, low cost and power, and programmability. High performance is needed to apply sophisticated algorithms to real-time streaming data. Low cost and low power are needed to build systems that can be deployed widely. Programmability is critical because algorithms are constantly evolving.

When they came on the scene in the early 1980s, DSPs provided precisely that combination, Bier notes. The devices delivered higher performance, with lower cost/performance and better energy efficiency than standard microprocessors—and, of course, they were programmable.

In the 1990s, DSPs began to see competition from general-purpose CPUs. As CPUs increased in performance, they became increasingly capable of tackling digital signal-processing tasks. And, in many cases, CPU architects added DSP-oriented features (such as single-instruction, multiple-data operations) to their processors to boost performance and efficiency on signal processing tasks. A key advantage of CPUs is that virtually every system needs one for overall control. If the CPU can be co-opted to handle the signal-processing tasks, the engineer might be tempted to dispense with a DSP entirely. When maximum energy efficiency or cost efficiency is required, however, DSPs typically are still widely used to offload signal-processing tasks from the CPU.

In the early 2000s, FPGAs began to be widely used for digital signal processing. Although they’re not “processors” in the usual sense of the word, Bier notes, FPGAs can be used to design custom data paths for digital signal processing, or even to create custom programmable processors. As FPGAs have grown to incorporate millions of logic gates, they’ve gained the ability to implement massively parallel processing, which can make them a good match for highly demanding digital signal-processing tasks. And in addition to higher capacity, modern FPGAs, like CPUs, have incorporated DSP-specific architectural features to boost performance and efficiency. Initially these were hardwired multipliers interspersed among the programmable logic fabric; more recently, they have become powerful datapath units, bearing a strong resemblance to the datapaths found in DSPs. 

When it comes to programmability, there’s good news and bad news for FPGA users, says Bier. On the positive side, FPGAs provide a very high degree of flexibility to implement hardware structures that are well matched to the needs of specific algorithms—much more flexible, in fact, than CPUs or DSPs, with their fixed instruction sets, addressing modes, and data types. Designing an FPGA, however, is nothing like programming a processor. Indeed, FPGA design is custom hardware design. It’s typically done at a fairly low level of abstraction—the register-transfer level—and requires skills that are less common among DSP engineers.

Lately, FPGA suppliers have been investing in new kinds of tools, such as high-level synthesis, to enable FPGA design (especially for algorithmic tasks like digital signal processing) to be done at a higher level of abstraction. That bodes well for the future of FPGAs in digital signal processing, Bier believes. Read excerpts from BDTI’s report here.

More recently, graphics processing units have begun to compete for the starring role in high-performance digital signal-processing applications. Originally developed for rendering 3-D graphics, GPUs have evolved into massively parallel processors that can be applied to many data-parallel problems, such as image filtering. And thanks to programming languages like CUDA and OpenCL, programming GPUs no longer requires the mind-bending task of figuring out how to express your algorithm in terms of 3-D-shader primitive operations.

So, which type of processor is best for digital signal processing today? “There really is no global answer,” says Bier. “Often, different types of processors are best for different parts of the application.”

To support that view, Bier points to mobile application processors—the brains of smartphones. “These processors deliver incredible performance at very modest cost and power consumption. They do this by carefully applying a heterogeneous mix of processors, including CPUs, DSPs, GPUs, and more specialized engines, such as the image signal processors used for image acquisition tasks.” 

“It’s analogous to building a house,” says Bier. “When you build a house, you don’t go to the lumberyard and order a truckload of 2×4s. House builders over the years have figured out that different materials are optimal for different functions within the house—2×4s for this, plywood for that, and so on. Similarly, different types of processors are optimal for different tasks within an application. If you have to choose just one, there are usually some tough compromises involved.”

You can find benchmark results for DSPs, CPUs, and FPGAs, along with other free resources, on BDTI’s Web site.

For data sheets on the latest DSPs and other processors, go to DataSheets.com.