Rapid FPGA Modem Design Techniques For SDRs Using Altera DSP Builder

Rapid FPGA Modem Design Techniques For SDRs Using Altera DSP Builder Steven W. Cox Joel A. Seely General Dynamics C4 Systems Altera Corporation 820 E. McDowell Road, MDR25 0 Innovation Dr Scottsdale, Arizona 85257 San Jose, CA 954 (480) 44-76 (408) 544-822 steve.cox@gdds.com jseely@altera.com ABSTRACT FPGA modem design techniques using Altera DSP Builder are presented for waveforms on software-defined radios (SDRs). The benefits of using these techniquies will be highlighted. This paper assumes that FPGAs will be the target processor for most modem real-time signal processing of waveforms. The techniques presented in this paper are the result of internal research and development for a general dynamics engineering-sponsored project (ESP). In this paper, we show how the typical FPGA-based waveform design flow can be streamlined to yield maximum efficiency. Time savings in the form of development, debug, and testing will be shown in addition to a reduction in engineering resources needed to accomplish a given cycle time. The streamlined approach includes: architecture definition, subsystem design, simulation, subsystem integration, FPGA code generation, and design verification. The design flow has major advantages compared to traditional waveform development processes and provides a common environment for multi-disciplined personnel to work and communicate effectively. Some areas of tool enhancement are identified to serve as a guide for future revisions and to encourage feedback of ideas for overall design flow maturity.. INTRODUCTION Software-defined radios (SDRs) are becoming ubiquitous as more systems require interoperability across multiple standards. Part of this trend is due to the heavy reliance on configurable hardware (e.g., FPGAs) used to implement the waveforms. To quickly develop these waveforms, some of which are extremely complex, tools with a higher level of abstraction are required. Altera s DSP Builder provides an integrated environment that can be used to develop hardware implementations of waveforms. This method streamlines the FPGA design flow using: Mathwork s Simulink capabilities, a fixed point blockset with Altera FPGA objects, and interfaces to third-party tools to generate a synthesizable FPGA hardware description language (HDL). DSP Builder allows multidisciplined users to work at higher levels of abstraction in a common workspace. All aspects of waveform development, including design, simulation, and verification, can be addressed at the Simulink level prior to hardware implementation. 2. TRADITIONAL FPGA WAVEFORM DESIGN METHOD The traditional ways to develop SDR waveforms have typically been fraught with inefficiency. In the past, designers had the system-level specifications and simulations thrown over the wall and they fired up their HDL editor of choice and started coding. There are, of course, some challenges with this approach. Firstly, the system designer has no insight into the implementation details of the FPGA and, therefore, could not best optimize the system design without lengthy communications with the engineers who are implementing the design. Secondly, the designer needs to be an expert in HDL, which typically isn t the sort of expertise an engineer is likely to pick up overnight. Thirdly, this approach involves manual code generation, which is timeconsuming and tedious, as well as likely to require extensive debugging all of which increases development time and cost. This approach also contains some inherent tendencies towards inefficiency, because the system must be created twice first on the system-level tool and then on the implementation tool further increasing the time and cost of system development. Figure provides an example flowchart for this traditional waveform development flow. CF-RAP0505-.0

Waveform Requirements Waveform Matlab/Simulink Floating Point Model Simulate to Validate system development such as waveform design. With this tool, a new design flow consists of five segments: defining architecture, implementing/designing modules, integration of modules, translating the design to physical FPGA, and verifying the part in the lab. See Figure 2. Waveform Detailed Design Documents Verify against Floating Point Model using ModelSim/Quartus Yes Waveform FPGA Design/Docs Hand Code in VHDL, Verilog, or Schematic Verify VHDL Timing using ModelSim Timing Verified? No Compile VHDL using Altera Quartus II Test Waveform Figure : Traditional Waveform Design Flow. ANOTHER TOOL, A NEW APPROACH Tools such as Altera s DSP Builder have been developed to address the issues found when performing complex 4. DEFINING ARCHITECTURE A floating point Simulink model of the MIL-STD 0A was the starting point for the SDR architecture. The,200 bits per second (bps) transmit mode of the specification was chosen for implementation. The floating-point model was used as a guideline and comparison tool, as well as for initial sizing and architecture mapping estimates for the FPGA implementation. The functionality implemented for this engineering-sponsored project (ESP) is shown in Figure. 5. IMPLEMENTATION/SIMULATION The design entry uses Altera DSP Builder block sets and Simulink toolbox block sets in the Simulink schematic capture environment. DSP Builder provides Simulink graphics conversion to VHDL for third-party VHDL simulators. ModelSim, an efficient and fast event-driven simulator, was used for timing analysis on the sub-blocks. The sub-block timing design flow is shown in Figure 4. As the designer verifies the timing and control in ModelSim, he or she updates the design in the Simulink environment. With the push of a button, conversion of the Simulink graphics to VHDL, stimulus for the sub-block design, and scripts to load and compile the updated design into ModelSim are all created. This automation streamlines the iterative process of simulating a design to assure a properly designed block and removes the onerous, but necessary task of organizing scripts for translation to other tools. Define Architecture Design & Implement modules Integrate modules Translate Design to Altera FPGA Verify Design in the -- Start with existing floating point Simulink model -- Design to 0A spec:,200 bps mode -- Protocol definition Sub-Blocks. Design in DSP Builder blocks. 2. Get data from Simulink model.. Timing/detail design uses ModelSim (.VHDL). 4. Run DSP Builder in Simulink when verifying data. All Blocks. Divide simulation in fast and slow clocks rates if possible. 2. Use sims to examine boundary conditions in design.. Use ModelSim for timing issues. 4. Run sims with DSP Builder to verify Data. 5. Use DSP Builder for initial sizing, then synthesize. Figure 2: Altera DSP Builder Design Flow FPGA Design. Remove stimulus from design for synthesis. 2. Generate Quartus II symbol with DSP Builder script.. Point Quartus II software to new design vhdl and symbol to insert into existing schematic. 4. Insert symbol and appropriate test points, then compile. 5. Check timing. Lab Verification. Check data with logic analyzer. 2. Store data from logic analyzer to file.. Analyze final data from logic analyzer in Simulink.

data clk Prom Data from Simulink clk FEC - Rate /2 - Output clock rate doubles 2.4kHz Interleaver - Format symbol to, 2, bits - Grey code data Grey Encode/ Symbol Formatter - Ping-pong memory - Input data rate = half of input clock rate - Syncs on interleaver frames,2, - Map symbol to constellation Constellation Mapper Preamble Generator - Generate preamble - mode dependent parameters - Long/short formats - Form packet - Timing Packet Formattor 6I, 6Q Modulator Scrambler - LUT for modulation - 8 psk Figure : - Randomize data according to sequence - data/sync random sequence Transmit 0A Top-Level Block Diagram Do schematic capture of design with DSP Builder in Simulink Reiterate to fix errors Simulink Models Reiterate to fix errors Run DSP Builder to generate VHDL Run DSP Builder blocks in Simulink and output data to workspace Run floating point Simulink model and output data to workspace Figure 4: Run Timing Analysis in ModelSim using tcl script generated by DSP Builder Analyze data DSP Builder Timing Design Flow Next, the floating point and DSP Builder models are compared and verified. The DSP Builder model and floating-point models are run separately in Simulink, and their data sets of interest are stored in the Simulink environment workspace. Commands in Simulink manipulate the DSP Builder fixed-point data by sub-setting the data sets to compare to the floating-point model. To correct errors, the designer updates the models in Simulink and reruns the simulations to verify. The data verification flow is shown in Figure 5:. Compare and analyze data in Simulink workspace Figure 5: DSP Builder Data Verification Flow 6. INTEGRATION/SIMULATION Data validation was accomplished in the Simulink environment because DSP Builder models are C Code, which run faster than VHDL interpretative simulators. Once the design was totally validated, an initial sizing and synthesis of the DSP Builder design was performed in Simulink. This provides early notification to determine if further work is needed on the design to compensate for sizing and timing constraints. This methodology provides a good technique to fix problems in the early stages of the design cycle instead of time-consuming and costly fixes at the end of the design cycle. During the integration phase, the large disparity between the base clock ( MHz) and the input data clock (,200 Hz)

was noted., which could cause the Simulink simulations to take a long time. This problem can be alleviated, however, by reducing the input data clock to be represented by 0.66 MHz instead of the full,200 Hz equivalent. To analyze boundary conditions between frames, the number of bits per frame was decreased from,440 to 20. To help with analyzing data during integration, the slow and fast clock dependencies were separated in the architecture. The slow clock dependences run from the beginning of the waveform chain to the input of the scrambler. The fast clock dependencies run from the scrambler to the output of the modulator. Due to the latency in the interleaver, the data at the output does not become valid until one frame has been written in. Only valid data at the output of the data formatter was captured to the workspace, and the fast dependencies were run as a separate simulation with only the valid data output from the formatter. This integration/simulation methodology significantly reduced simulation time for the high-speed portion of the circuit and allowed efficient design validation. 7. SYNTHESIS Before synthesis, the input stimulus from the Simulink model must be replaced with input pins. Input stimulus was stored in a programmable read-only memory (PROM) and DSP Builder automatically generated the PROM file for synthesis. DSP Builder also generates a Quartus II script to load the design into the tool to create a symbol. The user must anticipate the test points needed to observe the entire new design. These test points are included in the symbol block so they can be connected in the schematic. If additional test points are needed after the compile, the user must update the Simulink DSP Builder model. In order to embed the new design in an existing schematic, pointers to the new VHDL files and its symbol were included in the Quartus II project. Then the project was compiled and timing results were analyzed. Embedding the new DSP Builder design in the existing schematic capture design is easy and straightforward. In Phase 0.8 0.6 0.4 0.2 0-0.2-0.4-0.6-0.8 8-ary PSK Transmit Output - - -0.8-0.6-0.4-0.2 0 0.2 0.4 0.6 0.8 Quadrature Figure 6: Constellation Plot for Transmit Output The logic analyzer captured the final data (I and Q) to a file, and it was verified against the data in the floating point Simulink environment. This process only took a few days. 9. RECOMMENDATIONS AND CONCLUSIONS Figure 7 documents the different design stages and provides an estimate of the time required to complete each using both the traditional waveform design methodology and DSP Builder. Document Verify in Lab Days To Implement SDR DSP Builder Traditional Method Translate to FPGA 8. LAB VERIFICATION With a raw binary file in hand, the FPGA image was loaded into an SDR radio (with an Altera EP20K000 device) and each sub-block was checked with a logic analyzer. The design yielded an 8 psk constellation, as shown in Figure 6. Integrate Modules Design Modules Define Architecture 0 2 4 6 8 0 2 4 Figure 7: Comparison of Time to Complete Portions of SDR Using Traditional Method & DSP Builder The Simulink/DSP Builder flow allows the designer to allocate time in an appropriate manner for developing waveforms. With the traditional method, the FPGA designer spends an enormous amount of time in the lab (0 percent

and up) troubleshooting FPGA design/system issues. The DSP Builder/Simulink/ModelSim simulation flow allows the designer to rapidly identify problems and troubleshoot them by adding appropriate taps and re-simulating the model. Taking simulations to a system integration level significantly reduces risks, time, and lab resources. Altera s DSP Builder allows the hardware to be abstracted to a higher level so that the FPGA and system waveform developers can operate in a common environment or be onein-the-same person. The tools have a very short learning curve if the user is familiar with Matlab/Simulink and hardware design. As the tool matures, some enhancements may be added to help speed up simulation times. One novel improvement is the addition of frame-based capability in all DSP Builder/Simulink blocks. This technique has been proven to speed up simulation times by many orders of magnitude in standard Matlab/Simulink. Given this capability, the system designer could build the Matlab/Simulink floating-point model using DSP Builder blocks initially, instead of having to use generic Simulink blocks. This would bypass the design flow step that translates the floating-point model into a fixed-point model. Another possible tool enhancement is a method for handling large clock disparities between the FPGA base clock and the model sample clocks. This paper describes a workaround to this dilemma, but there may be automated ways of simplifying this for the common user. The flow described has major advantages of streamlining validation, lab check-out, and providing a common environment within which multi-disciplined personnel can work and communicate. With its existing and upcoming features, DSP Builder is a powerful tool for rapidly developing SDR waveforms on FPGAs.