System-Level Design Tackles Tough Soft Radio Framework Challenges

System-Level Design Tackles Tough Soft Radio Framework Challenges

Louis Bélanger, LYRtech Signal Processing
Jun 01, 2004 (10:00 AM)
URL: http://www.commsdesign.com/showArticle.jhtml?articleID=21400583

Recent design trends tends to add layers and virtualization even to high-rate and hard real-time systems such as wireless receivers. System-level design tools and high-level frameworks, such as the software communication architecture (SCA) developed within the Software Defined Radio (SDR) Forum, are serious threats to the "good old days" of "classical" C and VHDL programming approaches for DSP and/or FPGA/ASIC wireless systems.

But when looking at new frameworks, designers must be concerned whether silicon advances be sufficient to offset the loss of performance spread in the virtualization layers. Additionally, they must try to understand what level of performance will actually be lost through virtualization.

To answer to these questions, designers need to turn to high-level design tools that solve the performance and complexity issues created by frameworks like SDR Forum's SCA architecture. This article will discuss the challenges that the modularized architecture defined by the SDR Forum has on the system design process and how system-level design tools can help solve these problems. The article will also provide an example single-sideband (SSB) SDR radio design that is developed using system-level design approaches.

Getting More Complex
There's no doubt the design of wireless infrastructure systems is not getting any easier. For example, cellular systems are already packing voice, video and data services on the same link. At the same time, wireless designers are looking for ways to implement advanced technologies, such as voice-over-IP (VoIP) and multiple-input, multiple-output (MIMO) antennas in their system designs—all significantly increasing the complexity of a wireless design.

To illustrate this point, let's look Figure 1 to see the amount of code required to develop a wireless system, as compared to other complex systems like the Space Shuttle. Note: In Figure 1, KLOC refers to thousands of lines of code.

Figure 1: Diagram comparing the amount of code required to develop a 3G UMTS design against te amount of code required for the Space shuttle and a jet fighter.
In 2002, a typical wireless design required 50 thousands KLOCs. Assuming an engineer can write about 350 lines of code per month, hand coding these lines of code would theoretically take an average of 146 man months or 3 man years of engineering time. In contrast, today's 3G wireless systems will require better than 300,000 lines of code, thus increasing hand coding development time to 300 man years.
Time to Automate
At some point along the increasing code size of wireless systems it becomes evident that manual coding will create brick wall. The complexity of these designs makes it vital for designers to automate the code generation process.
In conjunction with this automation process, the SDR Forum has crafted a set of specifications that bring modularity and standardization to the radio portion of a wireless design. The benefits of this modularized architecture include:

Segmentation of the "problems"

Multi-vendor offering

Decoupling of technology advances on specific functions (RF, IF, baseband)

The SDR architecture, shown in Figure 2, consists of functions connected through open interfaces, and procedures for adding software specific tasks to each of the functional areas. The software necessary to operate is referred to as a software application.

Figure 2: Typical implementation of SDR Forum software and hardware open architecture.
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.

Click here for figure 3
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