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.

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.

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.