Consult

with

an expert

By Ray Andraka, Andraka Consulting Group

Designing digital-signal-processing hardware is quite different from designing for software-based systems. In addition to the obvious considerations for hardware, such as clocking, timing and so on, a hardware digital-signal-processing designer also has to consider how an algorithm will map to hardware, as well as the availability of design resources.

Before beginning the digital-signal-processing design, a designer should determine the appropriateness of the approach. Generally, if a single DSP or microprocessor provides enough horsepower to accomplish the task at hand, the designer should use it instead of an FPGA-based option. The tools are more mature, talent is cheaper and easier to find, and most of the algorithms currently in use were developed for software platforms.

If, however, the required performance is greater than a single DSP or a microprocessor can achieve, the performance gains that an FPGA presents outweigh the costs. Typical FPGA performance gains over a single DSP are around 100times, and gains of more than 1000times are possible under some circumstances. Other considerations can also tip the balance in favor of an FPGA. Power dissipation of a well-executed FPGA design, for example, is typically about 20% of the power consumption of a software-based system operating at the same sample rate.

Programmatic issues, such as the cost of software validation in certain systems, can also tip the scale toward FPGAs. Most systems include both an FPGA and a DSP. In these cases, it is usually best to delegate the "inner loop" to the FPGA and leave the housekeeping and other odds and ends to the microprocessor.

Not all devices are equal for digital-signal processing. The FPGA needs to have robust arithmetic capabilities, which, until the introduction of Altera's Stratix, heavily favored the Xilinx architectures. Newer devices have fast multipliers that ease the transition to hardware for those of you unfamiliar with hardware digital-signal. A multiplier may not be a panacea, though, because, in most cases, a design lacks sufficient multipliers for you to use them indiscriminately.

The key to designing digital-signal processing in FPGAs is thinking in terms of what the hardware that performs the function must look like. Al-gorithms for software implementations tend to be heavy on multiplication as well as floating-point operations. Often, small changes in the algorithm or use of alternative approaches can lead to greatly simplified hardware. You can significantly reduce area just by switching from floating-point to fixed-point arithmetic or to a modified floating-point format that uses only minimal bits to represent the signal at given points in the algorithm.

Vendors are offering high-level digital-signal-processing-design tools that make the entry into FPGA-based digital-signal processing easier for newcomers. These tools include plug-ins for scientific packages, such as Matlab. These plug-ins include the Xilinx System Generator, as well as high-level-synthesis tools, such as those from Celoxica. Although these tools sufficiently lower the bar for putting algorithms into hardware for systems designers who are not hardware-savvy, the occupied-area and performance results are bound to be disappointing. A seasoned hardware designer is likely to find the tools frustrating because it is difficult to use them with intellectual property in the tool's rather limited library.

A designer should simulate the algorithm at the system level before executing the detailed hardware design to verify the selected precision at each point in the design and to iron out any bugs in the algorithm. It is far easier and faster to sort out these issues in a high-level model than at a gate-level simulation. Doing a bit-true system-level simulation in C or The MathWorks' Matlab also has the advantage of providing high-fidelity test vectors that you can later use to verify the proper operation of the digital design, once you complete the detailed design. System-level simulations also allow you to explore alternative algorithms in search of one that better maps into hardware.

Digital-signal processing in hardware was around long before the advent of the microprocessor. It dates to the late 1950s, and, for nearly 30 years, you could do digital-signal processing only with custom hardware. Because of the high cost of digital logic in those days, developers created algorithms and techniques to handle the processing with a minimum of hardware. These algorithms are just as good today as when they were developed, and they're appropriate for a hardware-digital-signal-processing design because they can offer significant system savings and power-dissipation advantages over designs that you base on an algorithm developed for software. Technical libraries are loaded with these hardware gems, which are buried deep in 20 years' worth of dust, waiting for an astute hardware engineer to resurrect them. Even if you can't find a suitable algorithm, the knowledge that early work embodies can serve as a useful guide for making your algorithm more hardware-friendly.

After selecting the algorithm and data precisions, the designer should look at the clock cycles available per sample to determine the architecture of the hardware. To get the most bang for the buck, strive for as many clock cycles per sample as possible. Current FPGAs can run at clock rates well beyond 150 MHz, yet most digital-signal-processing applications are still running at sample rates of less than 20 MHz. In these cases, running a faster master clock provides the capability for bit- or digit-serial processing at a considerable savings in logic area and, subsequently, in device cost.

Faster clocks also open the door for implementing certain algorithms with repetitive operations in iterative hardware. A good example of this technique is using a scaling accumulator over several clock cycles in place of a full parallel multiplier. The block diagram that falls out of this step is the blueprint for the rest of the design effort, which is essentially the same as any other digital-hardware-design effort.

Author's biography

FPGA guru Ray Andraka, founder of Andraka Consulting (North Kingstown, RI) has been designing digital-signal-processing functions into programmable logic since 1988, even before the days when carry chains were considered a state-of-the-art arithmetic innovation. He's an enthusiastic participant on comp.arch.fpga, comp.dsp, and other relevant Internet newsgroups, as well as at industry events such as the ACM (Adaptive Computing Machine) FPGA conference, and his Web site offers lots of free and useful information.

Evaluating performance:

FPGAs

versus DSPs

By Jeff Bier, Berkeley Design Technology Inc

The latest digital-signal-processing-enhanced FPGAs boast huge gate counts, ample amounts of hard-wired SRAM, and an abundance of hard-wired multipliers. These attributes hint at the potential for phenomenal performance in digital-signal-processing applications. But experienced engineers know that the difference between potential performance and actual performance can be huge.

Simple metrics don’t cut it

Experienced engineers also know to view the performance claims of chip vendors with skepticism. This cynicism definitely holds true when evaluating the digital-signal-processing performance of FPGAs. For example, FPGA vendors sometimes quote the digital-signal-processing performance of their chips in terms of MACs (multiply-accumulates) per second. On the surface, this approach seems reasonable; after all, many digital-signal-processing algorithms make heavy use of MACs, and DSP vendors are also fond of quoting processor performance in terms of MACs per second.

But, like other oversimplified performance metrics, such as MIPS, the MACs-per-second measurement suffers from several serious flaws, not the least of which is that no universal definition exists for exactly what a MAC operation comprises. When FPGA vendors quote MACs-per-second numbers for their devices, they often base their figures on distributed-arithmetic implementations of FIR (nonrecursive) filters. Distributed arithmetic is a natural way to implement a FIR filter on an FPGA. The problem is that in a distributed-arithmetic FIR, the MAC operators rely on the fact that the coefficients of the filter are constants. If the MAC operations in your algorithm don’t use constant coefficients (for example, if you’re building an adaptive filter or a correlator), the FPGA will deliver lower MACs-per-second performance.

How, then, should you go about determining the true digital-signal-processing application performance of these new FPGAs? This question is the one that BDTI (Berkeley Design Technology) recently began considering. For years, the company has been benchmarking the signal-processing performance of DSPs and general-purpose processors using the BDTI Benchmarks—a suite of digital-signal-processing algorithm kernels (for example, an FFT and a Viterbi decoder)—coupled with a methodology designed to ensure fair comparisons. The company has evaluated more than 50 processors with the BDTI Benchmarks, so using the same benchmarks for FPGAs seemed to be an attractive approach that would allow the company to quickly compare FPGAs with those and other processors. Unfortunately, BDTI found that this approach was the wrong way to go.

Holistic optimization

Although a handful of algorithms dominates the computation requirements of a digital-signal-processing application, individual algorithm kernels are unsuitable as benchmarks for high-capacity FPGAs, for several reasons. With a processor, digital-signal-processing-application developers aggressively optimize each of the key performance-hungry algorithms for speed. When an algorithm is running, it has exclusive use of all of the processor’s execution units. But with an FPGA, designers have the flexibility to trade off parallelism (and hence performance) against resources used (logic blocks and multipliers, for example). Unlike with a processor, with an FPGA, it makes no sense to use all of the available resources for a single algorithm, because doing so would leave no resources for the rest of the application. Instead, a designer must optimize the application as a whole, allocating the available hardware amid each of the constituent algorithms (Table A).

This observation led the company to the conclusion that, to evaluate the digital-signal-processing performance of FPGAs, it needed a benchmark that looked more like a complete application and less like a single-algorithm kernel. The next question facing BDTI was what kind of application to use as the basis of the benchmark. Informal market research indicated that the new digital-signal-processing-enhanced FPGAs were of strong interest to developers of communications systems, leading us to develop a benchmark based on a communications receiver.

Cost versus performance

Although they are powerful, the latest digital-signal-processing-enhanced FGPAs are also expensive. The lowest priced members of Xilinx’s Virtex-II and Altera’s Stratix devices cost hundreds of dollars, and the most expensive family members cost thousands of dollars per chip. Such prices render these chips unsuitable for highly cost-constrained products, such as cable-TV set-top boxes or DSL modems. But in communications-infrastructure equipment, a several-hundred-dollar price tag does not automatically disqualify a chip—especially if that chip can handle the processing for many communications channels. Therefore, for the initial benchmarking of digital-signal-processing-enhanced FPGAs, the company evaluated how many channels of a communications receiver each of the benchmarked chips could support.

The benchmark comprises a simplified OFDM (orthogonal-frequency-division-multiplexing) receiver (Figure A). OFDM is a complex technique that is finding increasing use in a variety of high-speed data-communications applications, such as fixed wireless systems. A detailed benchmark specification spells out all of the key parameters of the benchmark receiver, such as sample rates, filter lengths, and channel-code constraint lengths. Benchmark coders implement as many channels of the receiver as they can cram into a single chip.

The benchmark

BDTI invited Altera and Xilinx to implement the BDTI Communications Benchmark on their digital-signal-processing-enhanced FPGAs. Xilinx initially agreed but later withdrew from the project. If you’d like to see Xilinx results for the benchmark, e-mail BDTI at xilinx-benchmark@BDTI.com; BDTI will send Xilinx a summary of your requests. BDTI also invited Motorola and Texas Instruments to implement the benchmarks on their high-end DSPs, which target communications-infrastructure equipment. Altera and Motorola took our challenge, and each delivered a highly optimized implementation of the benchmark.

Because Altera was not yet shipping its recently announced Stratix family of digital-signal-processing-enhanced FPGAs at the time of the benchmarking effort, BDTI projected Altera’s results based on simulations. In contrast, Motorola has been shipping its MSC8101DSP, which it based on the StarCore SC140 core, in volume for a while. BDTI scrutinized both Altera’s and Motorola’s benchmark implementations for correct operation and conformance to specifications.

Surprising results

It’s clear that the new digital-signal-processing-enhanced FPGAs, with dozens of hard-wired multipliers and RAMs and tens of thousands of configurable-logic blocks, are capable of vast parallelism in applications that are amenable to parallelization. As with a processor, though, an FPGA’s throughput in an application depends not only on how much work it can perform in one cycle but also on the clock speed it can attain. For processors, the maximum clock speed is easy to ascertain. But for a given FPGA, the clock speed attainable depends in part on what you’re doing with it. Altera used simulations to project the clock speed attainable on its Stratix FPGAs with its implementation of BDTI’s Communications Benchmark. BDTI will verify these projections when silicon becomes available.

Although BDTI expected the digital-signal-processing-enhanced FPGAs to perform well, the company was surprised by just how well they did. For example, the Altera Stratix 1S20-6 chip (scheduled to begin to be available for sampling this month, according to Altera) is projected to support more than a dozen channels of BDTI’s Communications Benchmark. In contrast, the 300-MHz Motorola MSC8101 can support only about one-fifth of one channel.

The 1S20-6 has a projected price of $325 (1000). The MSC8101 current sells for $140 in similar quantities, which is fairly typical of high-end DSPs. As a result, on a cost/performance basis, the advantage of the 1S20-6 over the MSC8101 is somewhat smaller when you compare it with its throughput advantage, but FPGAs retain a significant lead.

Full details on the results of the FPGA-versus-DSP-benchmarking work appear in BDTI’s just-published report, FPGAs for DSP.

Other factors

BDTI’s initial benchmarking work suggests that the new digital-signal-processing-enhanced FPGAs can indeed achieve impressive performance in certain types of DSP applications. But experience with these new devices and discussions with users indicate that factors other than performance often greatly influence decisions regarding FPGA use. For example, one key challenge facing digital-signal-processing developers using FPGAs is the relative complexity of the design process and the lack of digital-signal-processing-specific features in the development tools, compared with the tools available for the best supported DSPs.

Clearly, as with most technology-selection choices, deciding whether to use an FPGA for a digital-signal-processing application requires a sophisticated, multidimensional evaluation—one that depends on many specifics of the target application. In researching BDTI’s recently completed report, the company developed a framework to guide developers in this challenging process. BDTI plans to continue its benchmarking and analysis, tracking the new generations of digital-signal-processing-enhanced FPGAs, processors, and other emerging alternatives.

Author’s biography

Jeff Bier is general manager and co-founder of BDTI (Berkeley, CA), a well-known digital-signal-processing technology-analysis and software-development company. BDTI’s Web site contains a wealth of free information of interest to developers of digital-signal-processing systems. The company recently expanded its focus beyond traditional DSPs and microprocessors to include FPGAs.

Theme and variation

General-purpose processors and DSPs...ASICs...FPGAs...
hardware/software blends...Enough options to make your head spin? Well, hold onto your hat, because a few more alternatives are coming your way.

One criticism of conventional DSPs is their lack of instruction-set flexibility. Rarely do you find, with apologies to Goldilocks, an architecture that’s not “too generic” or “too specific” but, instead, “just right” for your application. As a result, you have to either buy a faster, more expensive, and more power-hungry processor to compensate for missing functions or pay for functions you’ll never use. User-customizable DSPs from companies such as 3DSP and Improv Systems and custom CPUs from folks such as Tensilica, aim to address your needs with tailored chips. Be careful, though; you’re taking a long-term availability risk by buying a sole-sourced device from a small supplier, and you won’t be able to benefit from the high-volume economies of scale of generic DSPs.

Are you looking for hardware that’s flexible like a FPGA but doesn’t require you to tediously stitch together fine-grained logic primitives, such as LUTs (look-up tables) and registers? Well, instead consider QuickSilver Technology’s ACM (Adaptive Computing Machine), which interconnects higher level memory and processing primitives in a user-programmable fashion tailored for high-speed dynamic reconfiguration. QuickSilver has a test chip in hand, and the company plans both to develop its own application-tailored ACM variants through subsidiaries and spin-offs and to license the technology to other companies as an embedded core.

Finally, what if you’re convinced that a hardware-centric signal-processing approach is the way to go, but a pure FPGA won’t meet your performance, power, or per-unit-price goals, and a pure ASIC is too inflexible? In such cases, embed one or multiple FPGA cores within your ASIC to provide the best of both worlds. Today’s embedded FPGA suppliers include Actel (VariCore), Atmel (AT40K), and Leopard Logic (HyperBlox), and IBM and partner Xilinx are scheduled to begin shipping their first hybrid ASICs by mid-decade. The following design example from Leopard Logic illustrates the technique:

“The DCT (discrete-cosine-transform) algorithm is a common application kernel used in the image-processing graphics domain. This example implements an 8×8 DCT, typically used in video encoders with 8-bit data inputs and 16-bit data outputs. Figure A defines the 8×8 DCT algorithm.

DSP mapping

“This algorithm can run in software on a processor, even on a generic 16-bit DSP, but it will incur a large latency and require many DSP clock cycles for execution. The relative inefficiency of logic activity per clock cycle versus a direct-parallel-hardware implementation also incurs a significant power penalty. In general, it is advisable in digital-signal-processing computation to calculate at the highest possible throughput for the least amount of time.

Traditional mapping to discrete FPGAs

“Another design alternative is to map the 8×8 DCT into hardware using a conventional FPGA technology. The design challenge in this case is to maximally use the preselected generic tiled resources. This challenge manifests itself as an issue when tables need to match available memory-segment sizing, or when arithmetic processing needs to match to available multiplier units and their associated bit widths. Independent of the mapping process, the final design realization in a commercial FPGA will likely consume a substantial amount of power and have a significant cost premium compared with a full custom, standard-cell, or gate-array ASIC version.

“This example maps the 8×8 DCT into the Xilinx Virtex-II XC2V250-5-FG456 FPGA. The design uses the hardwired multipliers distributed through the FPGA logic array. The resultant design runs at a maximum operating frequency of 103 MHz under worst-case commercial conditions.

Mapping to HyperBlox FP

“To present the closest comparison of the HyperBlox FP to the Virtex-II architecture, this mapping uses hardwired multipliers implemented in standard-cell ASICs, and the remainder of the logic maps to the Leopard Logic HyperBlox FP embedded FPGA.

“The FPGA portion of the design requires 975 HyperBlox Core Cells, representing more than 95% of the 1024 available Core Cells. Whereas speed degradation is common in highly used discrete FPGAs, the patented hierarchical interconnect of the HyperBlox array allows this design to operate at a maximum operating frequency of 288 MHz under worst-case commercial conditions on a 0.13-micron CMOS process.

“Although the traditional mapping shows impressive performance gains and is useful for comparison purposes, it is not the best method to implement designs with the HyperBlox FP.

“Best-of-breed” mapping to the HyperBlox FP

“The final implementation of the 8×8 DCT illustrates the Leopard Logic design approach that encompasses the best technology from the ASIC and FPGA worlds. ASIC designers are no longer forced to accept a specific configured platform option.

“You can decompose the DCT algorithm into three columns, each of which contains two Radix-4 DCT Butterfly operations. The six Butterfly components each take on a slightly different form, but you can design a single Butterfly that encompasses all of the required modes (Figure B).

“Note that Figure B shows shifters added to the basic structure to control bit growth. Six of the Butterfly nodes combine into the structure required for the 8×8 DCT as shown in Figure C. Place the Radix-4 Butterfly of Figure B in low-power, area-efficient standard-cell ASIC circuitry, because the Butterfly contains well-defined arithmetic blocks that have fixed functions.

“Note, too, the control lines in Figure B. Although the ASIC components are fixed in function, the control lines allow external selection of the desired mode of operation, in this case, by the FPGA circuitry.

“The HyperBlox FP embedded FPGA provides flexible, reprogrammable control to the ASIC datapath components. Two of the Radix-4 Butterfly nodes combine to form one of the three columns of the 8×8 DCT. If you allow three cycles for data processing, you can use a single column and circulate the data through the pair of Radix-4 Butterfly nodes three times. On each pass, the controller implemented in the HyperBlox FP embedded FPGA selects the proper mode of operation for each of the Butterfly nodes.

“The resultant architecture, shown in Figure D, reveals the partitioning between ASIC and FPGA circuitry. The circuit has a maximum operating frequency of 900 MHz under worst-case commercial conditions on a 0.13-micron CMOS process. Because this architecture requires three passes through the circuit, the net processing rate of this circuit is 300 MHz. If the design requires the full 900 MHz, you must instantiate all three DCT columns.

“Note that this partitioning of the 8×8 DCT, with a simple reprogramming of the HyperBlox FP embedded FPGA, can also implement a 32-point DCT used in audio compression.”

Clearly, Xilinx, not Leopard Logic, is the expert at implementing designs in Xilinx architectures. Leopard Logic might also have, intentionally or not, chosen a signal-processing function that is simultaneously optimum for its HyperBlox technology and not optimum for Xilinx FPGAs. If Xilinx responds to Leopard Logic’s claims, you’ll find the company’s response here.