System-Level Design Tackles Tough Soft Radio Framework Challenges

Figure 2 above shows the SDR Forum open architecture of seven independent subsystems interconnected by open interfaces. In this view, the generalized SDR Forum functional architecture has been particularized by equating a subsystem definition to each functional area.

Each subsystem shown in Figure 2 contains hardware, firmware, an OS, and software modules that may be common to more than one application. The application layer is modular, flexible, and software specific. The common software API layer, inferred from Figure 2, is standardized with common functions having open and published interfaces. Peer-to-peer interfaces are neither required nor proscribed by the SDR Forum.

Of course, the approach pitched by the SDR Forum does have it drawbacks. The biggest is the addition of additional abstraction layers to the system design. Adding layers to high-speed latency and timing sensitive systems is definitely a delicate matter because these additional layers can lead to additional complexity, a move that all designers want to avoid.

Solving the complexity issue
To help solve the potential complexity problem posed by the SDR Forum SCA architecture, designers can help automate the code development process by turning to system-level design tools that are tightly integrated to development platforms. To illustrate the importance of system-level design tools, let's look at a real-life design example. In this example, a prototype of a typical SSB radio was developed.

Essentially, the system-level approach resides in automatically generating execution code from a simulation model that is targeted at a programmable hardware architecture, speeding up the development process and providing a validation prototype early in the design process. Another key benefit is to keep the same environment used in the early design process in latter phases, such as in-circuit testing and verification of real-time hardware, thus improving the overall quality of the design process.

The case study discussed below will show all the different steps involved in the design process. The first step in the process is to create a hardware-independent model. This can be accomplished using the Simulink DSP Blockset.

Figure 3 shows the general signal flow in the radio. The local oscillators are shared by both receive and transmit processing chains. The receiver consists of a digital down converter (DDC) followed by a final filter-demodulator stage. The transmitter is simply the receiver blocks turned around with interpolating rather than decimating filters. Once satisfactory simulation results have been obtained, indicating the general signal flow and filtering are correct, it is time to split the model between the FPGA and the DSP. For this design, partitioning the functions is straightforward.

Figure 3: Top-level model of the five main subsystems needed to create the SSB radio.

A tendency in "system-level development", in order to compensate for the inefficiency of generic automatic code generation with respect to manually coded applications (either at the C or assembly levels), is to combine the use of C-code based simulation with optimized libraries or cores substituted when building the target application. Such an approach is best exemplified in the Xilinx System Generator extension to Simulink (Figure 4). In this case, target-specific structural VHDL is generated, as a compromise to pure system-level code.

Click here for Figure 4
Figure 4: Diagram illustrating the development of the SSB radio using Xilinx's System Generator tool.

The System Generator design, specific to the FPGA implementation, can be dissected into very distinct sections. Obviously there is the hardware realizable section which is in blue. This will be the section that will go into the FPGA.

The yellow blocks represent the gateways into and out of the Xilinx blockset as they must be implemented in fixed-point arithmetic. The gateways will also illustrate the inputs and outputs of your VHDL top level entity (the pins of the device).

All Simulink blocks do not have color and most designs will utilize the Simulink/DSP sources and sinks, which will drive and test the design. Any Simulink block (although not hardware realizable unless hand-created in VHDL) can be interfaced to the Xilinx blockset with the aid of the gateway blocks to convert between "doubles" and "fixed point numbers."

A similar approach is done even with DSP targeted code, where a set of TI DSP optimized libraries blocksets are available at the Simulink level (Figure 5).

Click here for Figure 5
Figure 5: Simulink-optimized libraries blocksets for TI C62xx and C64xx DSP families.

The blocksets shown in Figure 5, while allowing full floating-point simulation, presume that a fixed-point library is substituted when building the executable target. A reciprocal approach is to combine high-level functions with off-the-shelf optimized code, which will be used when building the executable. Another variant would be off-the-shelf legacy code, which is combined with manually optimized code when the target is builded.

It is interesting to note the commonality between system-level simulation and frameworks such as SDR Forum's SCA. Both work on a block-diagram basis, and virtualize the underneath hardware. Concerns on critical performance aspects such as clock distribution and interprocess over-buffering are also common and have to be addressed. "Under-the-hood" accesses have to be provided to have acceptable level of performance.

In the SSB design, clock control was a key issue and was addressed; multiplication of buffers (which will add latency) was not specifically addressed, but could have been by hand optimizing the code generated. One further interesting step would be to provide SCA-compliant gateways at the Simulink level, to bridge both approaches.

Level of Performance
Now that the simulation is established, designers should wonder what level of performance and implementation optimization they can expect from the high-level approaches discussed above. Those with grey hair will be among the "to-be-convinced" crowd (I have to admit I was part of it).

In fact, the results are surprisingly good. First, the use of optimized cores and libraries at the system level makes that optimized code for the critical processing components (where 80% of the processing will be done) is quite efficient. Table 1 shows results in terms of DSP efficiency at the DSP level and gates/cost efficiency at the FPGA level. Considering that FPGA prices are aggressively declining, the FPGA vs. ASIC will continue to heat up, even for volume end-user products.

Table 1: FPGA and DSP Implementation Results

Wrap Up
Higher-level development approaches such as frameworks and system-level design tools are becoming mainstream even in the high performance domain of wireless designs. Even though these approaches bring many benefits, they add computing burden to the target architecture. However, a number of tool improvements and techniques are available to offset these drawbacks. Keep in mind, however that at the end of the day, skilled engineers (and good development platforms) will always be needed to further optimize the implementation and make the whole thing work.

About the Author
Louis Bélanger is a founder of LYRtech Signal Processing Inc. He graduated in 1979 from Laval University's Electrical Engineering Department, and earned his MSEE in 1985 in signal processing. Louis can be reached at louis.belanger@lyrtech.com.

Copyright © 2003 CMP Media, LLC | Privacy Statement