Rodger H. Hosking
Pentek
TechOnline

	ABOUT THE AUTHOR Rodger H. Hosking is vice president and co-founder of Pentek where he is responsible for new product definition, technical marketing, and strategic alliances. With over 25 years in the electronics industry, he has served as engineering manager at Wavetek/Rockland, and holds patents in frequency synthesis and spectrum analysis techniques. He received a BS degree in Physics from Allegheny College and BSEE and MSEE degrees from Columbia University.

During the last decade, designers have used ASICs and DSPs to handle nearly all of the signal-processing functions associated with radio communications. Even though programmable logic has been around for decades, the latest generation of FPGAs is so powerful that they're now displacing both ASICs and DSPs in the latest software-radio applications.

With Moore's law at work, these FPGA devices sport incredibly small silicon geometries, capable of operating at very low core voltages and very high clock speeds. Most of these new devices take advantage of ball-grid-array (BGA) packaging to deliver thousands of I/O pins while keeping the packaged device's footprint very small.

In the early days, only hardware engineers were capable of creating designs for programmable logic. Today, an entire new class of design tools is appearing that now opens up FPGAs for both hardware and software engineers. Instead of just accepting logic equations and schematics, these new tools accept entire block diagrams as well as VHDL and Verilog descriptions. Excellent modeling and analysis tools have greatly simplified the task of debugging these new devices.

Perhaps the most exciting new twist in design tools is the growing libraries of silicon-IP (SIP) cores available from FPGA vendors as well as a whole new industry of third-party companies that offer application-specific SIP cores.

Figure 1:  DSP functions for software radio

The local oscillator or NCO consists of a phase accumulator, which is just a register, and an adder, both available as standard library blocks for virtually all FPGAs. The phase value in the accumulator drives a sine/cosine lookup table, which you can implement in a simple ROM. The mixer is nothing more than a pair of digital multipliers, now available as dedicated hardware resources in the latest generation FPGAs.

Programmable DSPs are often used to implement some common demodulation, decoding, and analysis functions. However, FPGA and third-party vendors now offer a good selection of SIP libraries to handle Viterbi, Reed-Solomon, convolutional, and trellis decoders; data encryption standard engines; and various noisy-channel models.

Both FFT and discrete-cosine transform cores are also available with several different block lengths. Several vendors are offering scalable FFT engines ranging in size from 16 to 1024 points and higher using complex radix-4 algorithms. Since an FFT operates on blocks of data, the block-memory RAM available with the newer FPGA devices allows some design tradeoffs. You can save memory by doing an in-place FFT with a single block, or move up to a swinging buffer arrangement to provide continuous real-time calculations. Some of the SIP cores support several different memory modes.

To help with control functions, a long list of SIP cores is available for popular processors. The benefit with this technique is that by using a well-supported core processor you can take advantage of existing code and the software-development tools already in place for these engines"this helps speed development and improve maintainability.

For speech and video signals, you can take advantage of a wide range of cores including ADPCM, JPEG, and color-space converters. The decimating low-pass filter usually comprises several CIC filter stages followed by a FIR filter. SIP cores for all of these basic functions are available from multiple sources. If some or all of these signal-processing functions are handled by an FPGA, the programmable DSP is now able to concentrate on the analysis and control functions, much more appropriate tasks for the DSP's capabilities.

The ASIC digital receiver usually is designed with a full set of standard operating modes and features, and has been more thoroughly tested and characterized than a custom combination of FGPA-based SIP cores. This gap will obviously shrink as the cores add more functionality and more cores become available. Since the ASIC hardware is optimized for dedicated functions, the latest ASIC devices are usually the better choice for extremely high-performance receiver applications.

The ASIC normally benefits from a longer user history, bug fixes, and a much more complete characterization and testing effort. Standard ASICs usually have extra bells and whistles you may not need today, but they've already been tested and will be ready to use for future requirements.

However, if you can't buy a standard digital-receiver ASIC with just the right phase and frequency characteristics, or if the local oscillator just doesn't meet your switching requirements, an FPGA's flexibility might get the job done. Also, for proof-of-concept systems or when time-to-market is critical, FPGAs are often the right choice.

In other applications, where the required signal-to-noise ratios, filter skirts, or frequency templates are beyond the complexity of the standard filter inside a commercial ASIC, the flexibility of SIP filter designs for FPGAs can provide just about any characteristic.

Another shortcoming of some digital-receiver ASICs is the ability to provide output sampling that is decoupled from the input sampling rate and, instead, is synchronous with the output symbol rate. Although interpolation or re-sampling filters and synchronizers are now appearing on some new ASIC devices, they may not meet the needs of some of the new wireless protocols.

While you can reconfigure FPGA code for new modes of operation and feature enhancements, it's usually much easier to make the more significant changes on a programmable DSP instead. Sometimes, a very small change can have a profound impact on the gate and logic-cell topology inside your device. In some cases, these changes can also mandate a new pinout, requiring a new printed-circuit-board design.

The receiver module has four 14-bit 80-MHz A/D converters for digitizing IF or HF analog inputs entering through front-panel SMA connectors. All four A/Ds feed a bank of eight quad digital down-converter ASICs with four channels of local oscillator, mixer, and filter in each chip.

On board are two Xilinx Virtex-E FPGAs, each receiving the 16 baseband signals from four quad-receiver chips. These FPGAs handle data formatting and channel selection for delivery down through the VIM interface to the 32-bit mezzanine FIFOs on the processor board. Since the receiver signals flow through the FPGAs, they can also perform demodulation and decoding functions to offload these tasks from the DSP.

Note that all four A/Ds are connected to all eight quad-receiver chips. Inside the front end of each receiver chip is a programmable crossbar switch that allows each of the four narrowband-channels inside to independently select any one of the four A/D inputs. This means all 32 receiver channels on-board can independently select which A/D or antenna they are looking at. This provides a very dynamic antenna-to-channel assignment scheme for systems that need to adapt to changing traffic patterns.

Also notice that the digital outputs of two A/D converters are delivered directly into each FPGA. This allows wideband A/D data to stream directly through the FPGA to the DSP. The high bandwidth of the VIM interface supports clock rates up to 100 MHz.

Even more important, it also allows the FPGA to handle signal-processing algorithms on the raw A/D data before it goes to the DSP, again, to offload some of its processing tasks. After handling the factory-standard functions of data formatting and control, nearly 70% of these resources are still available for custom applications.

The factory-default code takes care of all of the basic functions for most applications, including channel selection for delivery to the DSP board, selection of real or complex data modes, selection of receiver data or raw A/D data, and data-packing-mode selection. For custom signal-processing tasks, the optional design kit for each product includes the VHDL source code for all of these standard factory-default modes.

Customers can extend the factory code by adding their own algorithms at appropriate points in the signal flow path. You can develop and simulated FPGA algorithms by drawing on the wealth of SIP cores and design tools available for these devices. Once compiled, you can download the custom code through utility loaders into a non-volatile user memory on the board.

Many of the SIP cores are parameterizable"designers can specify the number of bits of calculation to tradeoff space for accuracy, if necessary. Be sure that the cores have enough precision to meet system requirements.

Algorithms run faster when they don't include exception handling"this can make benchmarks look deceptively fast. Designers may be able to guarantee, through system design, that certain exceptions simply cannot occur, but mysterious problems can appear in deployed systems if you overlook this aspect of the design.

To help check out new designs, take full advantage of simulation tools. Many of the advanced simulators are now bit-true, meaning they perform the operations with exactly the same number of bits that are in the FPGA algorithm. Be sure to allow enough time to thoroughly test a new FPGA design under all modes of operation to make sure it will act as reliably as the high-volume standard ASIC you're replacing.

Your best source for more information on devices and cores is the Internet. New announcements are appearing daily and a good springboard for information is the third-party section of FPGA vendors' Web sites. Certain third parties are true experts in niche application areas and many of them offer consulting or custom design services as well.