Building Soft Radio Channelizers Using Top-Down Design
Tom Hill, AccelChip Inc.
May 04, 2004 (12:00 PM)
Figure 1: Diagram of an SDR architecture implementing a polyphase FFT filter bank.
Software-defined radios (SDRs) are adaptable transceiver systems that learn and adapt to transmission and channel environments with software. A key element of an SDR architecture is the channelizer, which is used to isolate independent communication channels within a wideband signal. A channelizer needs to support multiple channel processing elements, wherein the channels of interest can be extracted and then forwarded on for demodulation and decoding.
There are three predominant channelization architectures used in SDR designs. These include digital down conversion (DDC), frequency domain filtering, and polyphase Fast Fourier transform (FFT) filter banks.
The polyphase FFT filter bank is the most efficient choice because it assumes redundancy within the frequency of the wideband channel. This structure makes use of a polyphase filter to isolate and decimate the various channels and then employs an FFT to efficiently convert each channel to baseband. Although this technique is limited to channel structures consisting of equally spaced channels, it requires only a single fast impulse response (FIR) filtering structure and an FFT, which increases its efficiency (Figure 1 below).
The channelizer's operations are performed prior to frequency decimation and would most likely be implemented in an FPGA, ASIC, or structured ASIC to meet performance requirements. The entire structure for the channelizer supporting hundreds of channels could be implemented in a single FPGA with a 64-channel architecture, easily fitting into an Altera Stratix II or Xilinx Virtex II device.
A MATLAB-based design flow is inimitably suited for targeting the channelizer's unique architecture to an FPGA. However, Matlab-based design flows have typically been relegated to digital signal processor (DSP) architectures. Fortunately, through new tools, top-down MATLAB flows can now also be implemented on FPGA architectures, thus easing the design of an SDR channelizer. Let's see how.
The first step in the design process is to select a DSP modeling environment best suited for the channelizer block. A wide variety of options exists for modeling the channelizer algorithms, including block-level environments such as Simulink, general-purpose programming languages such as C / C++, hardware-specific modeling languages such as VHDL or Verilog, and mathematical programming languages such as MATLAB.
Graphical DSP design tools provide a complete environment for DSP design by offering the advantage of a pre-defined library of signal processing functions and signal processing specific input stimulus and waveform display utilities. Graphical design entry, however, can prove cumbersome for highly replicated structures such as an SDR channelizer. Additionally, the perceived strengths of these tools for modeling real-time and multi-rate systems do not offer the developer of a channelizer any advantages.
General-purpose programming languages provide a higher degree of efficiency and flexibility for modeling the parallel structures of a channelizer using loop statements and arrays. A general-purpose environment suffers, however, from a lack of built-in support for the DSP-specific functions necessary to model a wideband receiver channelizer efficiently.
The ideal environment for modeling an SDR channelizer combines the DSP-specific capabilities of a graphical DSP modeling environment with a general-purpose programming language for modeling parallel multi-channel systems. This set of capabilities is uniquely available in the MATLAB environment. MATLAB offers an extensive set of DSP-specific built-in and toolbox functions, the coding efficiency of loops and multi-dimensional arrays, and DSP-specific input stimulus and analysis capabilities.
The FPGA Move
Performance requirements drive the hardware requirements for the channelizer block. DSP and general-purpose processors employ a serial processing architecture that does not provide sufficient performance for the processing demands of wideband signals. Placing an even greater demand on performance is the fact that the channelizer operation is performed prior to frequency decimation. For these reasons, front-end channelization processing is generally implemented in FPGAs or ASICs.
The leading FPGA vendors, such as Altera and Xilinx, have introduced DSP-enhanced devices that deliver high performance for the multiply-accumulate (MAC) operations inherent to the filter and FFT functions used in a channelizer block. The Altera Stratix II devices include up to 22 dedicated DSP blocks that each consist of a dedicated hardware multiplier, adder, subtractor, and accumulator. Likewise, the Xilinx Virtex II device includes up to 192 dedicated 18x18 synchronous multipliers and 192 block RAMs.
Selection of an FPGA enables the channelizer to be right-sized to the task. Bit widths can be tailored to a level of precision that provides enough dynamic range to express the results and enough precision to avoid excessive error, with little or no wasted area.
Both FPGAs and ASICs can deliver the required performance. Often the final decision is determined by cost, time-to-market pressures, and reconfigureability requirements.
MATLAB Coding Considerations
The power of MATLAB should be fully exploited to create a model for the channelizer that provides both efficiency and flexibility. Accomplishing this will require the use of MATLAB built-in functions, loops, and 2D arrays. Consider the following MATLAB coding example for a channelizer block shown in Figure 2:
Figure 2: MATLAB example of channelizer.
In this example, the function "channelizer" is called from a MATLAB script file in a loop that iterates once for each processing cycle. This effectively models the behavior for a real-time hardware implementation. The use of persistent data for the 2D array "tap_delay_line" and "X" allows the memory storage characteristics of the hardware to be modeled in MATLAB.
The MATLAB loop "i" is used in conjunction with the MATLAB vector array variable "z" to implement the parallel channelized filter structure. Use of the loop construct results in a MATLAB model that is both concise and reusable. The number of channels can be easily reconfigured by changing the value of the input constant "Num_of_Chan." This model can be used for multiple applications with minimal or no code changes.
The final operation is performed by the inverse FFT. This function will take the vector "z" created through the filtering function and return a vector of the same length. Excluding comments, this channelizer function required only nine lines of MATLAB.
Using a Top-Down Flow
DSP design has traditionally been divided into two types of activitiessystems/algorithm development and hardware/software implementation. Two very distinct groups of engineers, which often have little connection or interaction, are responsible for these tasks. Algorithm developers create, analyze, and refine the required DSP algorithms using mathematical analysis tools at the behavior level, without regard to the underlying system architecture or hardware/software implementation details.
The system designer is concerned with defining the functionality and architecture of the design and must adhere to the product specification and interface standards. Systems designers and algorithm developers interact efficiently with each other because they work in a common design environment based on a high-level programming language such as MATLAB, which has proven to provide the most productive and accurate DSP development environment. These high-level models are then used as an "executable spec" for hardware development.
The implementation team must begin by first gaining a thorough understanding of this DSP function. The hardware engineer is required to know signal-processing theory to be able to interpret the MATLAB specification and develop a functionally correct RTL model and testbench, which is a process that can take months.
Once an initial RTL model has been developed, the hardware engineer must then interact with the algorithm developer to analyze and refine the area and performance of the realized hardware. Modifications to the original algorithm may be necessary to accommodate hardware limitations because systems designers had no visibility into the physical design domain during their algorithm development.
Systems engineers rely on experience, intuition, luck, and iterations when developing the system specification. Perhaps an even bigger concern is that the physical design of the DSP algorithm relies on interpretation of the executable MATLAB specification by the hardware development team. Both these factors exacerbate the complexity and development time for an FPGA or ASIC.
The process for designing an FPGA or ASIC of DSP algorithms can be improved dramatically by moving to a true top-down methodology (Figure 3). When the implementation model is disconnected from the executable specification, functional errors are easily introduced into the design. Additionally, the lack of a single "golden" source for DSP design requires disparate design teams to keep their MATLAB models synchronized with the manually created RTL models and testbenches.
Figure 3: Diagram showing a true top-down design flow.
A MATLAB-based, top-down design flow eliminates the need for hardware engineers to manually create RTL models and test benches, shaving months off the development cycle and reducing the number of engineers required to implement the design in hardware.
Critical to the success of an automated top-down DSP design flow is the quality of results that are achieved. This process cannot be a simple translation of MATLAB to VHDL or Verilog. If an automated top-down design flow cannot achieve the necessary results, a manual process will eventually be required.
Synthesis of MATLAB into hardware must be architecturally aware and be able to take advantage of dedicated resources provided by an FPGA device such as an Altera Stratix II MAC block or a Xilinx Virtex II block RAM. Providing an easy-to-use, automated path directly from MATLAB to hardware implementation enables DSP systems engineers and algorithm developers to refine their algorithms early in the development cycle based on architectural exploration. Algorithm developers can quickly convert their MATLAB designs into a gate-level netlist for a target FPGA device and assess algorithm tradeoffs in performance, area, cost, and power. Having the feedback from the development cycle means fewer iterations are made later in the design process, saving significant time and labor.
Channelizer Design Exploration
Using a top-down MATLAB design flow enables the rapid evaluation in hardware of the high-level architecture choices. Using the channelizer as an example, designers can quickly evaluate the overall effects of top-level architecture decisions such as serial or concurrent channelizer filters, pipelining, and bit widths.
Figure 4 highlights the effects that one hardware implementation decisionthe number of concurrent channel filterscan have on the overall design area and performance.
Figure 4: Area vs. performance tradeoffs of concurrent filter channels.
Table 1 contrasts the design exploration tradeoffs that can be achieved through top-down DSP design.
Table 1: Architecture Tradeoffs
Hardware tradeoffs should not require modification to the golden MATLAB source since these modifications are a downstream implementation decision. In doing so, the benefits of a top-down DSP design flow can be fully realized.
MATLAB provides an optimal design environment for the channelizer function of an SDR wideband receiver. The richness of the available MATLAB DSP functions, combined with the power of a high-level language construct such as "loop," allow for concise modeling of the channelizer function.
Companies are now providing a top-down DSP design flow that uses behavioral MATLAB as a golden source to quickly target an ASIC or FPGA. MATLAB offers both the easiest modeling environment and the fastest and most flexible path to hardware for channelized receivers.
About the Author
Tom Hill is a technical manager at AccelChip Inc. He holds a BSEE from Cleveland State University and can be reached at firstname.lastname@example.org.
Copyright © 2003 CMP Media, LLC | Privacy Statement