January 23, 2008 -- Use of Software Defined Radios (SDRs) has been steadily increasing due to the rapid improvements in embedded DSP horsepower and the high levels of integration possible in state-of-the-art FPGA devices. These improvements, coupled with those in cost/ power efficiencies of the respective embedded DSP and FPGA engines, are enabling SDR implementations to be embraced by multiple industries. This article describes, using examples, the use of electronic system level (ESL) design tools to develop an SDR, from block diagram concept to a finished hardware and software design.

A typical SDR

A typical block diagram of a complete SDR is shown in Figure 1.

Figure 1. Typical Software Defined Radio.

Beginning from the left, the first major subsystem of the SDR is a general-purpose processor or a GPP. The purpose of the GPP is to manage the control interface between the operator of the radio and the SDR. Typically, the GPP provides a user interface, the digital interface to the microphone and speaker along with a serial communication for networking and programming (typically a USB port).

The next major block of the SDR is the DSP. Its primary role is to serve as a modem, to modulate and demodulate digitized baseband IQ data. The DSP may also compute the received signal strength, control squelch and execute other algorithms such as voice compression, error correction, and various RF control functions.

In some applications, the conversion speed of A-to-D converters may exceed the capability of a DSP, so it's common to find an FPGA used as a high-performance signal-processing interface to the DSP. Typical FPGA algorithms are IQ up and down-conversion, digital filtering, FFTs, and correlators used in CDMA communications.

DSP software development strategy

While the primary focus of this article is the rapid development of the DSP modem software, it' important to note that the same tools and concepts discussed here can be used for digital hardware development in an FPGA.

The specific tool used in this paper is Agilent’s SystemVue® Comms ESL development SW. SystemVue has a powerful set of mathematical, functional and signal processing tokens, or models, that can be used to construct the block diagram of the desired radio architecture. Once constructed, an engineer can simulate performance of the architecture in both floating point and fixed point representations, debugging performance and fixed-point precision issues along the way. SystemVue then directly generates ANSI-C or VHDL source code. This lets the engineer download and test the radio software in a variety of Texas Instruments' digital signal processors or FPGA platforms.

SystemVue is not the only tool on the market with these capabilities. The Mathworks offers Link to Code Composer Studio and Real Time Workshop that work with MATLAB and Simulink to support similar types of development. National Instruments also provides a similar solution with their LabVIEW product.

Designing an FM Receiver using SystemVue

The specific example described in this paper is the design and implementation of a software defined narrow-band FM radio receiver. Other demodulation algorithms are also possible, such AM, single-sideband and more sophisticated waveforms such as GMSK, and OFDM technologies. This ability to reprogram the SDR to support different waveforms makes it quite appealing.

The steps involved in designing the radio are:

Design and test the FM Radio Block Diagram in SystemVue, initially using floating-point arithmetic. Convert the block diagram simulation to integer fixed-point arithmetic. Automatically generate C code and porting the algorithm to the TI DSP device or simulator. Debug and optimize the DSP program.

Step 1: Design and test the FM radio block diagram in SystemVue, initially using floating-point arithmetic

Figure 2 illustrates the initial high-level floating-point SystemVue design created to validate the basic concept.

Figure 2. SystemVue FM receiver block diagram.

The first block in the radio consists of a 12-kHz center frequency FM-modulator block which is modulated by a 1-kHz sinewave. The modulator is used to test the receiver and will not be included the final receiver software generated by SystemVue.

The FM signal drives an IQ down-converter, whose local oscillator frequency is also set to 12KHz. To process the baseband signal, the down-converter’s sum terms are removed from the IQ channels by two half-band decimating low-pass filters that were designed using SystemVue’s Filter Design Tool. This tool’s dialog is shown in Figure 3 illustrating the frequency response of the designed filter.

Figure 3. Filter design tool dialog showing half-band filter frequency response.

Demodulation is accomplished by a complex differential FM demodulator. In order to simplify the diagram shown in Figure 3, the demodulator block is combined into a “meta-system” token which hierarchically organizes the design. The expanded demodulator meta-system is shown in Figure 4.

Figure 4. Quadrature FM demodulator “meta-system.”

The modulator operates by multiplying the filtered baseband FM components with the complex conjugate of the same components delayed by one sample. The result is equivalent to differentiating the phase of the incoming signal which corresponds to the modulating signal — the 1-KHz tone in this example The output signal is then recovered by computing the arc-tangent of the complex product of the FM components. The final step is to decimate to the sample rate of the audio output stream to 8ksps, which is a typical output sample rate for narrow-band voice communication systems.

Step 2: Convert the floating-point block diagram simulation to integer-fixed-point arithmetic

At this point in the design, it's possible to convert the block diagram in Figure 2 into a floating-point C code program which can be executed on a TI floating point DSP such as the TMS320C6713. Because of cost, size and power considerations, however, many SDRs use integer DSP processors such as the TI TMS320C5510 or ADI’s Blackfin DSP. The next step of the FM receiver development, therefore, is to convert the blocks shown in Figure 2 and Figure 4 into their integer equivalents.

Figure 5 shows the modification of the IQ down-converter and the half-band FIR low-pass filters. The IQ down-converter utilizes the DSP tokens supplied with SystemVue. These tokens consist of 16x16-bit multipliers and a 16-bit extractor token that extracts the upper 16bits of the 32-bit multiplier product.

Figure 5. FM receiver IQ down converter transformed to 16 bit Integer equivalent.

The 12-kHz complex LO is generated by means of a Lookup Table Token whose address values are generated by a Linear Ramp Token (token 53). The system sample clock is 48kHz, therefore, it is only necessary to store four samples of the Sine in the LUT to generate the 12-kHz LO signal. Since four samples of a single cycle equals a phase shift of 90° per sample, the Cosine output is computed by delaying the Sine output by one sample. This relationship is shown in Figure 6..

Figure 6. Sine and Cosine lookup table outputs.

Converting the half-band filters from floating point to integer is easily accomplished by the Filter Design Tool shown previously in Figure 3. All that is necessary is to enable the DSP Mode, and check the Autoscale check-box. The Autoscale feature automatically ensures that the since the filter inputs signal is 16-bit signed integer, the filter output is also a16-bit signed integer.

Both the Complex Conjugate Multiplier and ArcTangent blocks in the FM demodulator can be constructed using the DSP Block Tokens used for the IQ Down-converter. But the resulting DSP C code is unnecessarily complex. For example, the Complex Conjugate Multiplier would require four multiplier tokens, four bit-extractor tokens and two adder tokens. The C Code Generator (described in the next section) generates a separate function call for each token. Six function calls are generated, whereas a hand-coded C function only requires a few lines of code to perform this operation.

The engineer can use the SystemVue gererated floating-point function of the IQ down-converter token in Figure 2 as a template for a manually modified 16-bit integer version of the code. The C code required to perform the Complex Conjugate Multiplication is trivial, so the file is hand modified to perform 16-bit integer arithmetic. The engineer can also take advantage of the DSP Intrinsics that are a standard part of the TI DSP C Library. The intrinsic _smpy() calls optimized assembly code that multiplies two 16-bit signed integers and produces a saturated 16-bit signed product in four DSP clock cycles. The Arctangent computation is treated in a similar fashion.

The 16-bit Integer version of the code substitutes atan2_16(), an integer arctangent function in the TI DSP Library that is a standard component of the TI C development environment. This function is written in optimized assembly code and requires 60 CPU clock cycles per complex sample point. Note that the atan2_16 internally performs the zero-checking required to avoid division by zero. As a result , the zero checking code can be eliminated in the hand coded version.

In all of this, it is important to change the name of the function calls. Otherwise, if for any reason it is necessary to regenerate the code associated with the block diagram, the C code generator will over-write the hand coded changes.

Step 3: Automatically generate C code and port the algorithm to the TI DSP device or simulator

Automatic generation of the C source code begins from the block diagram shown in Figure 5. To generate the code, an engineer simply needs to select all of the desired tokens (models) from the block diagram . In SystemVue this is done by holding down the left mouse button while drawing a select box on the block diagram. In this example, all of the blocks except the FM Signal Generator tokens and the FM Output Display tokens are captured. Clicking the right mouse button inside the selected area brings up the C-Code Generator Dialog shown in Figure 7 below.

Figure 7. Automatic code generation dialog.

When the dialog is open, the numbered steps are followed to generate the code:

Step 1. Select the target processor (the TI C5x in this example). Note that SystemVue also allows custom register mapping to virtually any embedded DSP engine, not only TI DSP processors.

Step 2. Select the shell type. In this example, the TI CCS shell was selected and will shortly be discussed in greater detail. The dialog also provides the option of generating C-code that is compatible with the TI XDAIS DSP Algorithm Standard.

Step 3. Set the input buffer size. For this example, we would like to accumulate and process a one millisecond block of data for each FM receiver DSP code iteration. Therefore, the buffer size is set to 8, which will provide buffer space for 8x6=48 words of data.

Step 4. Provide a project name (e.g., FM_RecieverInt16).

Step 5. Enter a path to the folder where the source file should be stored. Note: the path must be explicitly specified. The indirect path shown in Figure 7 is for illustration only.

To generate the code, click OK in the Code Generator dialog and all of the necessary C files and header files will be automatically generated and placed in the selected project folder.

With the TI CCS shell selected, SystemVue creates all of the necessary C files along with a main shell program called SVURTDA.c. The file initializes the arrays and parameters required for the RTDX interface between SystemVue and the DSP (or DSP Simulator) via TI’s Code Composer Studio development environment and executes the the DSP program for the number of loops set by the developer in the SystemVue Timing Dialog window.

Step 4: Debug and Optimize the DSP program

Texas Instrument’s Code Composer Studio development environment is used to test and optimize the DSP program. The procedure for creating a DSP Code Composer project that can be used to test the generated C code is straight-forward. First, Code Composer is configured for either a C55xx JTAG emulator tool or a C55x Cycle Accurate Simulator. Once configured, Code Composer Studio is opened and the steps followed to create a new project and the automatically generated files are added into the project.

The compiled DSP program is loaded and executed by SystemVue by using an RTDA (Real-Time DSP Architect) token library. The library offers three types of RTDA tokens:

Source Token - Used for a DSP program that internally generates a signal and sends it to SystemVue. Sink Token - Accepts a signal from SystemVue and processes without returning a result. General Token - Accepts inputs from SystemVue and returns the result for further analysis or display.

The FM receiver example uses a General Token since it accepts an FM signal and returns the demodulated audio. To setup up the token, set the mouse cursor on top of the token and right-click to bring up a pop-up window. Next left-click on Edit Properties to bring up the RTDA Dialog shown in Figure 8.

Figure 8. RTDA General Token dialog window.

Enter the path to the FM_ReceiverInt16.out file that was created by the Code Composer Studio Compiler. Again, the example shows a relative path for purposes of illustration in this article. In practice, the path must be entered explicitly.

The number of DSP input and output channels can be selected by the Input Channel and Output Channel List Boxes. The parameters for each channel (e.g. name, transfer type and buffer size) can be adjusted by high-lighting the desired channel entry and clicking the Edit button on the RTDA Dialog Window.

Note that for this example, only one input and one output channel is defined. The buffer size for the input channel is set to forty-eight samples and the output of the FM demodulator is decimated the output buffer size is set to sixteen samples. The final step is to specify the size and total number of RTDX buffers in the RTDX Configuration windows. (RTDX is a TI specific protocol that allows data to be transferred from the Windows application directly to the DSP via the JTAG emulator port). In this example, the buffer sizes are left at their default value of 1024 words and the total number of buffers is set to four (i.e., command, status, input and output buffers).

The RTDA token always implements the Command and Status channels by default. The user can edit the channel names, by simply high-lighting the entry with the mouse cursor and entering the new name. The command and status data word sizes are set by the Transfer Data Type pull-down window.

Executing and debugging the DSP program from SystemVue

After the RTDA token parameters have been set, the program is executed by clicking the green Run arrow button on the SystemVue GUI tool bar. SystemVue will automatically open Code Composer Studio, load the DSP file and begin code execution. If everything is working properly, the desired output will appear in the Real-Time Graphic Display Window (token 67) in Figure 5 (Green Blocks). Pressing the red Stop square on the SystemVue GUI tool bar, will cause execution to halt but will not close Code Composer Studio.

If the DSP program does not execute properly, it can be debugged by loading the project file into Code Composer Studio. The DSP program can then be debugged, using the debugging tools that come with Code Composer Studio.

Once the program is working properly, the execution time can be optimized by using the Optimization Tools and metrics that are also included with Code Composer Studio.

Conclusion

This article demonstrates a methodology for developing, debugging, and implementing communications algorithm DSP code for use in SDR architectures. Using standard COTS tools and DSP engines a flow was described whereby various MODEM (Modulator / De-Modulator) algorithms could be implemented in readily available digital signal processors. A simple example of an FM receiver was used to illustrate the concepts.

Demodulation algorithms for FM were developed and tested graphically using the Agilent SystemVue communications oriented ESL platform. TI DSP specific ANSI-C code was generated automatically from the algorithmic block diagram using facility built directly into SystemVue. The subsequent code was hand modified to simplify compute intensive calculations. Then is was compiled and implemented using the standard TI integer embedded DSP.

Code debugging was facilitated through the TI RTDX interface which allows a seamless interface between SystemVue and the native TI CCS development environment. Using this interface samples of a real modulated signal (potentially with impairments) were passed to the DSP engine (either in hardware or software via instruction set simulation ISS) for processing in the implemented demodulation algorithms. With this capability performance and code integrity issues can be wrung out using real-world test vectors.

By Bob Davenport and Frank Ditore.

Bob Davenport and Frank Ditore are with Agilent Technologies, Inc.