In-depth algorithmic evaluation at the fixed-point level helps avoid expensive surprises in the final implementation.

Transcription

1 In-depth algorithmic evaluation at the fixed-point level helps avoid expensive surprises in the final implementation. Evaluating Fixed-Point Algorithms in the MATLAB Domain By Marc Barberis Exploring and developing algorithms such as those used in digital signal processing applications requires that the algorithmic concept be rigorously verified in the floating-point domain. This task is followed by quantization converting the floatingpoint representations of the algorithms into their fixed-point counterparts. The ensuing fixed-point representations then require their own extensive verification to ensure that they implement the original algorithms with sufficient accuracy and performance. In order to explore and develop such algorithms efficiently, developers ideally require a concise language for modeling, fast simulation speeds for both floatingpoint and fixed-point representations, and a consistent environment in which to explore and analyze the algorithms in both the floating-point and fixed-point domains. The de facto standard for initial algorithmic exploration and development is to use MATLAB, from The MathWorks. MATLAB is extremely fast and powerful in terms of exploration, visualization, and analysis in the floating-point domain, but it s not well-suited to fixed-point evaluations. To overcome that drawback, Catalytic has developed a suite of tools and utilities, called Fixed- Point DSP Studio, comprising fixedpoint constructs, an interactive quantization and analysis tool, and a MATLAB simulation accelerator. The simulation acceleration engine offers significant run-time improvements over the native MATLAB engine, both with implementationready floating-point representations and with their detailed fixed-point counterparts. The use of the fixed-point constructs in conjunction with the interactive quantization and analysis tool significantly improves the speed and ease of performing the quantization process. And the combination of all these tools enables developers to remain in the familiar MATLAB environment, with its sophisticated analysis and display capabilities. The overall result is to significantly reduce the overall implementation time associated with a DSP design, thereby reducing costs and resources and improving time to market. 18 Winter 2005 Embedded Edge

2 Currently, in a common design flow when using offthe-shelf DSPs, the initial algorithmic verification in the floating-point domain is performed in MATLAB (Figure 1a). Once the algorithms have been proven, they re recoded by hand in floating-point C and then must be reverified. Next, quantization is performed and the algorithms are manually translated into fixed-point C. Following final reverification and analysis, the fixed-point C is compiled into fixed-point assembly code (or directly into machine code). The most significant problem associated with this conventional flow is that MATLAB s sophisticated visualization and analysis facilities like plotting and statistics aren t available when they re most needed: to evaluate the quality of the conversion from floating-point to fixed-point. MATLAB development environment MATLAB floating-point C floating-point C fixed-point* Assembly fixed-point Manual translation Manual quantization Compilation Outside the MATLAB environment MATLAB development environment MATLAB floating-point MATLAB fixed-point C fixed-point* SW-assisted quantization Assembly fixed-point Manual translation Compilation Outside the MATLAB environment A NEW FLOW The solution is to streamline the flow by moving the fixed-point conversion back into the MATLAB environment (Figure 1b). The new tool suite makes that possible. The suite s fixed-point constructs, which support signed and unsigned operands, complex and real numbers, and commonly used saturation and rounding modes, provides bit-accurate fixed-point modeling in the MATLAB environment. The results from these functions are bit-identical to the results from operations executed on typical fixed-point DSP hardware. The interactive quantization and analysis tool enables developers to browse through hierarchical MATLAB source code, to assign fixed-point values to signals and have those values automatically propagate throughout the design (insofar as such propagation can be meaningfully inferred), and to easily view and modify the fixed-point characteristics of every variable within a function. MATLAB s native simulation engine is optimized for vector computations and floating-point mathematical operations. However, MATLAB s interpreted language slows down significantly in the case of fixed-point representations, in which each operation is wrapped with checks for overflow, underflow, rounding, and other features that emulate processor-specific characteristics. Fixed-Point DSP Studio s simulation accelerator dramatically speeds up both floating-point and fixedpoint simulation. Using the new flow, developers can analyze the current state of quantization and identify any bottlenecks at each step during the conversion from floating-point to *May include hand-crafted assembly code and manufacturer-supplied routines (a) Figure 1: In the traditional DSP algorithm implementation flow (a), developers must leave the MATLAB environment early in the process, losing valuable exploration and analysis capabilities. In the new flow (b), the quantization and fixed-point exploration and analysis are performed in the MATLAB environment, significantly reducing the overall implementation time. fixed-point. Throughout the quantization process, they can take full advantage of the familiar environment, the analysis capabilities, and their existing testbenches in the MATLAB domain. Furthermore, the speed provided by the simulation accelerator enables developers to test the quantized algorithms extensively while remaining in the MATLAB domain. DIRECTLY TO FIXED-POINT With this flow, developers can go directly from floatingpoint MATLAB representations to their fixed-point C counterparts with a high level of confidence that the fixed-point implementation is correct. Thus the flow significantly reduces the overall implementation time associated with a design, thereby reducing costs and engineering resources and improving time to market. To demonstrate the power of this streamlined flow, Catalytic created a simplified representation of an (b) Embedded Edge Winter

3 801.11a wireless LAN system (Figure 2). (The example focuses on the highlighted blocks.) In the transmitter, the data to be transmitted is grouped into blocks. When each block is transmitted, it is prepended with a physical layer convergence procedure (PLCP) preamble and header. Following convolutional encoding, the data is padded, interleaved, segmented, and modulated. Pilot symbols are now added to each block, which is subsequently converted from frequency into time using an inverse FFT. Finally, a cyclic extension is performed and the signal undergoes windowing and pulse shaping before being transmitted. In the receiver, the incoming signal first undergoes matched filtering, after which the cyclic extension is removed. The channel is equalized and an FFT is performed to yield the estimated data. Following demodulation, concatenation, and de-interleaving, Viterbi decoding is performed and the original bits retrieved. MATLAB s source code (M-code) is extremely power- MAC data Transmitter Padding and trellis termination Pilot insertion IFFT Receiver Channel estimation Channel equalization FFT Viterbi decoder Convolutional encoder Modulation Cyclic extension Long preamble Transmission noise Cyclic extension removal Pilot seperation De-interleaving Interleaving Segmentation OFDM symbols Windowing pulse shaping Matched filter Demodulation Concatenation OFDM symbols Padding and tail removal Figure 2: A WLAN system has a familiar architecture with forward error correction, modulation, and the corresponding inner and outer receivers. The floating-point algorithms for the IFFT, FFT, convolutional encoder, and Viterbi decoder were implemented and verified, then quantized and their fixed-point representations evaluated, all within the MAT- LAB environment. 20 Winter 2005 Embedded Edge ful and concise. A signal transformation such as an FFT, for example, can be represented using a single line of code. Thus the simplified WLAN system could be captured using fewer than 200 lines of M-code. To ensure high-quality data, WLAN systems use higher-layer protocols, such as retransmission. Rather than operating the system with a high level of protection (coding), it is therefore more efficient to use the minimum amount of coding needed to achieve, say, a 10% block error rate (BLER) and to subsequently rely on retransmitting unacknowledged packets to achieve near-perfect to perfect transmission quality. When it comes to implementation, design teams are increasingly moving away from hard-coded ASIC realizations of DSP algorithms. They re doing so largely because of the high costs and long development times associated with designing an ASIC and also because

4 the ensuing algorithms are effectively frozen in silicon, making it difficult to accommodate evolving standards and protocols. When the decision has been made to use an off-the-shelf fixed-point DSP, like Texas Instruments TMS320C55x or the 64x DSP generation, developers must verify the behavior of the algorithms with limited bit widths generally 8, 16, or 32. At this point, in order to accurately predict future behavior on the tar-get device, it s essential to have full control over the internals of the algorithms. That requires replacing MATLAB s generic functions with custom-designed equivalents in the implementation language. As a first step, it makes sense to implement and verify some of those functions in plain MATLAB M-code, the procedure we used for the IFFT, FFT, convolutional encoder, and Viterbi decoder. These routines were initially coded in floating-point to ensure that they re functionally equivalent to the original MATLAB functions. Unfortunately, this approach reduces the simulation speed tremendously because the optimizations that are embedded in MATLAB library functions are no longer available. Thus, even though we were still working in the floating-point domain, the simulation that originally took about nine minutes now took almost 17 hours. We were able, however, to continue to work within MATLAB, thanks to the simulation accelerator, which is used to compile the code and create DLL objects that can circumvent the lack of performance inherent in MATLAB s JIT compiler. Once the data types of the input ports were specified, we invoked the simulation accelerator simply by executing the following commands: Certain values having a dynamic range that exceeds the selected fixed-point representation capability. This problem can be solved by changing the algorithm or by using an intermediate solution like block floating-point, which involves changing the fixed-point scaling dynamically on a block-by-block basis These effects aren t visible in MATLAB when the algorithm is modeled in floating-point. It is very important, however, to capture and analyze them before proceeding with the actual implementation. We first considered the effects of quantization on the receiver, starting with its FFT. As a first pass, we quantized the input signal with 8 bits (2 bits for the sign and integer component and 6 bits for the fractional component). The twiddle factors for the FFT were quantized separately using 16-bit values (1 sign bit and 15 fractional bits). With our fixed-point constructs, quantizing a variable an array, in this case required only one statement: >> mlxlr8 wlan_tx >> mlxlr8 wlan_rx When we re-invoked the simulation, MATLAB automatically called the DLLs, and the simulation took less than 13 minutes similar to the time taken for the original MATLAB simulation using its optimized library functions. We were now in a position to begin quantizing the MATLAB code and investigating the effects of the quantization on the quality and performance associated with the reduced dynamic range of the signals. The types of effects in which we re particularly interested are: Overflow or underflow due to improper scaling Residual offsets due to truncation or improper rounding Instability of algorithms with feedback Embedded Edge Winter

5 % Quantize the twiddle factors WTable = [complex(wcostable,- WCosTable(N4+1:-1:1))... complex(wcostable,- WCosTable(N/4:-1:2)) ]; WTable = cfxp(wtable, 1,15); y = zeros(1,n); % === Handle the first stage % separately L = 2; NrCells = N/2; for nc = 11:NrCells % BUTTERFLY ii = 2*nc-1; y(ii) = x(ii) + (xii+1); y(ii+1) = x(ii) (xii-1); Of particular interest is the fact that by quantizing the input signal and the twiddle factors, we also automatically quantized many internal variables using type propagation. In practice, typically it s sufficient to explicitly quantize only 10% of the variables or less to obtain a fully quantized design, saving considerable time and effort. If this fixed-point simulation were run using the native MATLAB engine, the result would take one to two days because of the checks for saturation, overflow, rounding problems, and so forth. In comparison, simulating the representation using our simulation acceleration engine decreases the run time by several orders of magnitude to less than 15 minutes. More importantly, we were still able to take advantage of MATLAB s superb analysis and display capabilities. For example, we simulated our first-pass fixed-point representation of a perfect receiver and compared the bit error rate and frame error rate with the results for the original floating-point design (Figure 3). It s immediately apparent that the degradation produced by our quantization is too high. (The original floating-point simulation took less than nine BER/FER FER float BER float BER 8-bit BER 16-bit SNR Figure 3: For the floating-point representation of a perfect receiver as a function of the signal energy, for frames of 196 bits for a 24-MB/s system, a MATLAB analysis of the bit error rate and frame error rate shows that quantizing the input signal using an 8-bit field results in unacceptable degradation compared with the performance of the original floating-point representation of the algorithm. Using a 16-bit input field yields sufficiently accurate results for the WLAN system. 22 Winter 2005 Embedded Edge

6 minutes using the native MATLAB simulation engine on 10,000 MAC frames.) Next, we tried quantizing the input signal using 16 bits: 2 for the integer portion and 14 for the fractional part. A new analysis (Figure 3 again) shows that the results are significantly better and are close enough to the original floating-point results for our purposes. We then turned our attention to the Viterbi decoder. In this case, the input for each of the bits is a soft decision. The typical practice is to use 3 bits. However, quantizing the Viterbi decoder using 8 bits generated the following warning when running the simulation: Warning: Negative overflow detected in file ctlc_viterbidec.m line 69: SaveCumMetric=fxp (NewCumMetric,8,0); Graphical Programming for DSP This message points to the line where the cumulative metric inside the Viterbi decoder is quantized. We immediately knew that the cumulative metric requires more than 8 bits. We can quickly and easily extended it to 16 bits by changing the line to: SaveCumMetric=fxp (NewCumMetric,16,0); RIDE software is DSP made easy. Complete graphical programming environment with rich library of built-in functions Scalable integration to Texas Instruments Code Composer Studio and other software for advanced designers Open-platform ANSI C source code generation for any C IDE Real-world integration to test with National Instruments virtual instrumentation Direct support for many development hardware platforms and DSP chips Download the graphical programming for DSP white paper or request your FREE evaluation kit by visiting Tel: (214) Fax: (214) info@hyperception.com hyperception.com 2004 National Instruments Corporation. All rights reserved. Product and company names listed are trademarks or trade names of their respective companies. This time there was no warning, and the simulation results were identical to those with no quantization in the Viterbi decoder. As shown, the tool suite significantly improves the speed and ease of quantization and offers orders of magnitude run-time improvements over the native MATLAB engine, both with the implementationready floating-point representations and their detailed fixed-point counterparts. Marc Barberis (marc@catalyticinc.com) is the senior staff applications engineer at Catalytic Inc. in Palo Alto, Calif. He is currently working on products that facilitate the fast implementation of MATLAB algorithms on hardware components. His background includes wireless algorithms and other intellectual property, as well as simulation platforms for digital communications. Embedded Edge Winter