Beyond Processors
Implementing high-performance DSP algorithms in FPGA

Did your last circuit board look like a college marching band of DSP processors? Could you use it to heat your basement? Maybe you’ve been using one discrete DSP processor paired with an FPGA or ASSP in your embedded system design? Maybe it’s time to consider implementing your next digital signal processing algorithm in programmable logic.

Before you start sending those comments about how DSP processors are cheaper, lower power, and easier to design than a typical FPGA, stop and re-do the math. Brian Jentz, DSP marketing manager for Altera, says that designers are switching to programmable logic for DSP applications and saving cost, power, and space on the circuit board compared with traditional DSP processors. “You have to look from a system design perspective,” says Xilinx’s Narinder Lall, Sr. Marketing Manager for DSP solutions. “Both cost and power per channel are dramatically lower with an FPGA implementation.”

Today’s newest PLD offerings such as Xilinx Virtex-II Pro and Altera Stratix have dedicated resources aimed directly at DSP applications. Typically, the most computationally expensive step in a DSP algorithm is multiplication. Both of these vendors have introduced devices with built-in dedicated multipliers as well as rich sets of other reconfigurable DSP features. Hundreds of embedded multipliers, accumulators, adders, subtractors and shift registers accelerate the biggest bottlenecks in the typical DSP datapath to ASIC speed, allowing massive parallelism with standard-cell efficiency. These improvements have increased the already substantial performance margin for FPGA compared with DSP processors, and considerably narrowed the gap between FPGA and ASIC.

For highly-parallelizable designs (such as those in some multi-channel communications systems), FPGAs can offer three key advantages when compared with DSP processor implementations. These include performance, integration, and customizability, as well as three resulting follow-on benefits including power consumption, cost, and board area.

Computational throughput is at least an order of magnitude higher with FPGA device-to-device. (Don’t fall into the trap of comparing operating frequencies - but you knew that, didn’t you?) Because FPGA offers the opportunity to parallelize computationally intense parts of the algorithm, huge gains in performance can be realized through micro-architecture optimization. What this means is that in communications applications, for example, a number of DSP processors each servicing a separate channel, can be replaced by a single FPGA to support the same number of channels.

Computing exactly what this performance difference is, however, is a complex and subtle problem. Berkeley Design Technology, Inc. has done an in-depth study of the performance of today’s FPGAs in DSP applications compared with mainstream DSP processors (see Jeff Bier’s article “Evaluating Performance: FPGAs vs DSPs”) and found that, for certain classes of high-bandwidth applications, FPGAs have a compelling advantage.

FPGA also offers the opportunity for greater integration. If your application has both DSP and non-DSP functions (as most do), you can often integrate both on a single device. Now that FPGA vendors are offering both hard and soft processor cores for their FPGAs (ARM and Nios for Altera and PowerPC and MicroBlaze for Xilinx), lower-demand functions can be executed in software while accelerator modules can be designed using the dedicated hardware resources available.

Another advantage of programmable logic is customizability. You can create an implementation of your design that has performance where you need it with a custom architecture for your DSP algorithm and economy where it helps for the rest of your application. You also have flexibility to reprogram on the fly for upgrading or migrating to keep up with changing standards.

Because of the performance, integration, and customization advantages, an FPGA-based solution of a high-performance DSP system will typically have far fewer devices than a processor-based one. This translates into less power consumption (sometimes dramatically less), lower overall cost, and of course, significantly less board area.

These remarkable benefits are pulling many, many high throughput applications such as communications and video processing from processor-based implementations to programmable logic. So why is 90+ percent of the market still using processors? First, if your design works and works well with a single processor, you probably are ahead to stay with that solution unless you can integrate the DSP with other functionality and reduce device count. A single FPGA will almost always cost more and use more power than a DSP processor. Second, and most importantly, the learning curve and design complexity is an order of magnitude worse in programmable logic (although FPGA and EDA vendors are working to address that deficit). The challenge of developing an FPGA-based DSP is daunting for the typical DSP designer, and the effort required is substantially higher. This problem is only beginning to be addressed by the industry.

The typical system designer developing a solution that includes DSP can create the algorithm in an application such as MATLAB or Simulink (from The MathWorks, Inc.) and quickly translate that into an application that can be run on a DSP processor – often in a week or less. The main requirement is some software skill.

Creating an FPGA design, however, is an entirely different undertaking. FPGA designs are typically done by hardware engineers with expertise in hardware architecture, using hardware description languages such as VHDL or Verilog with corresponding simulation, synthesis, layout and timing analysis tools. Design cycles for FPGAs, although much shorter than for Application Specific ICs (ASICs), are still measured in weeks instead of days. Usually, a system designer will complete the same steps required for a processor-based DSP design, then hand the algorithm off to a hardware design team to complete the FPGA (or ASIC) implementation.

Both FPGA and EDA companies are working to address that problem, but the solutions do not yet address many types of applications and have not yet been widely adopted for production use. Both Altera and Xilinx offer design flows that facilitate DSP designs created in Simulink moving quickly to FPGA implementations. These flows are based on libraries of pre-designed parameterized DSP functions such as FFTs, FIR filters, and sine/cosine which can be mapped directly into optimized FPGA implementations for their particular FPGA technology. These modules generate high-performance implementations of the critical parts of the datapath, while buffering the designer from architectural design of these low-level functions. The goal of these flows is to keep the DSP designer in a familiar environment avoiding the unfamiliar vagaries of the hardware world. If your algorithm can be constructed with a serial-datapath implementation of these structures, these tools can ease the transition from the software-based domain into hardware.

Accelchip, Inc. is an electronic design automation (EDA) company that offers libraries of high-performance functions that can be retargeted from one technology to another. “Creating your design with vendor-supplied IP locks you into their device” says Michael Bohm, Accelchip’s Chief Technical Officer. Bohm says that designers can typically expect to gain higher performance and vendor independence by using EDA supplied functions. Accelchip also has tools that facilitate the mapping from floating point software algorithm to fixed-point optimized for hardware implementations. This step (called “quantization”) is a process of trading off accuracy against bit-width, resulting in corresponding changes in performance, gate-count, and power consumption. In addition, their solution has algorithmic synthesis technology, which can create a custom micro-architecture directly from algorithms created in MATLAB.

The fundamental problem of mapping algorithmic design to hardware, however, is far from solved. Creating a truly parallel, pipelined, or optimized datapath-control-memory architecture for a complex algorithm is still a task that requires the expertise of an experienced hardware engineer. Although considerable research and development has been done in this area, there are as of yet no widely adopted technologies automating this process.

Today’s technology and design techniques have positioned programmable logic as a compelling solution for many high-end systems with DSP requirements. What’s coming next? As vendors roll 90nm technology and 300mm wafers into mainstream production use, expect a large jump in performance and a similarly large decrease in cost for the FPGA option. In addition, look for design tool advances to gradually close the gap between processor-based designs and FPGA on implementation schedule and required expertise.

Who shouldn’t look at FPGA yet? As we said before, if you have a single-chip DSP solution that’s meeting your needs, you probably don’t need to look any farther. Single-device price and power consumption are generally better with processors, plus the design and schedule cost of moving to an FPGA-based solution are prohibitive. More often, your design will use a combination of traditional DSP processors with FPGAs performing control or interface-related tasks. Also, if your application runs on batteries, even the relatively lower power-per-throughput of FPGAs may not be enough and you may be forced into an ASIC solution. Even in those cases, however, it pays to stay up with what’s happening as programmable logic becomes the preferred technology for more and more high-performance systems.

For designers of very-high performance DSP systems requiring multiple DSP processors however, FPGAs are a viable option today. For those applications, FPGAs offer throughput, cost, and power many times better than processor-based solutions, with design cost and schedule substantially less than an ASIC implementation.

Kevin Morris, FPGA and Programmable Logic Journal

October 7, 2003

[back to top]

Comments on this article? Send them to comments@fpgajournal.com