The new shape of SDR.

As DSPs and FPGAs be come ever more capable and general-purpose microprocessors sprout multiple and specialized cores, software defined radio (SDR) implementations are benefiting. In addition to greatly improved standard hardware components, large advances also have occurred in the processes underlying development and production of custom SOCs. All these opportunities are adding to the diversity of SDR approaches being pursued worldwide.

An FPGA can be programmed to execute a variety of algorithms at high speed. A DSP may be almost as flexible and fit better into a company's product development flow. And, general-purpose microprocessors have the depth of compiler availability across multiple platforms that enables highly efficient program development.

On the other hand, a custom SOC can be tailored to address communications processing much more effectively than any of the other solutions. Of course, tools for programming and verifying the performance of a completely new SOC are themselves both new and proprietary.

These are just a few of the contradictions and trade-offs that characterize SDR development today. Additional factors include the specific environment in which the radio will be used;the importance of power consumption, portability, and cost; and whether the design is to replace one or more legacy systems.

A Base-Station SDR Solution

Today's general-purpose microprocessors are fast enough to handle many types of communications algorithms as well as control functions. Vanu has taken advantage of this high-speed microprocessor technology in its Any wave[TM] Base Station Subsystem (Figure 1). Power is not a major issue in most fixed-location installations, and shifting a large portion of signal processing from hardware to software has major benefits.

[FIGURE 1 OMITTED]

From a cellular-network operator's point of view, only one equipment rack is needed regardless of the number and types of standards supported. This compares with a typical installation requiring separate hardware for each standard. And, within the Any wave rack,the only special-purpose hardware is the RF head that performs digital channelization and down -conversion in receive mode and digital up-conversion and summing in transmit mode.

Data communications with the RF head are via Gigabit Ethernet and direct fiber links. All further signal processing is done in software running on industry-standard servers. This means that the network operator can select the most appropriate computer, allowing cost savings for less stringent applications as well as the opportunity to use multiple blade servers where the highest performance is required.

For Vanu, building a totally software product involved a major testing challenge. The communications standards that have been implemented continue to change, and there are new standards periodically introduced, In addition, algorithms are continuously upgraded. All these factors are addressed by ongoing software development, but the testing implications are daunting.

To deal with the problem and improve quality by avoiding human error, a fully automated 24/7 test system was developed. As described in a paper presented at the SDR Forum Technical Conference 2006," The continuous automated testing system ... called Tinderbox, is built on the tinderbox system originally developed by the Mozilla open-source project ....In an environment of networked hosts, independent build servers check out a project's source code from the central repository; compile, measure, and test it; then e-mail the results to a central database server and Web display." (1)

Testing with this kind of system is much more thorough than can be accomplished by any manual approach. In addition to testing code across several platforms, a variety of compiles and compiler diagnostic settings can be used. The end result is that compilation-specific bugs are avoided as well as code that is incompatible with certain development tools.

In Vanu's case, implementing SDR entirely in software makes a continuous automated test system particularly effective. The role played by specialpurpose hardware is much larger in portable SDR implementations, and the test challenges are different. For example, algorithms executing within a specific type of FPGAor DSP do not need to be ported to many other types of devices in the way that Vanu software is ported to many platforms.

Facilitating Portable SDR

The hardware emphasis in portable radio applications is largely a consequence of power, size, and cost restrictions. The flexibility of a programmable SDR approach is desirable but has been compromised in the past by lack of suitable components.

The Sandblaster[R] SB3000 DSP Series developed by Sandbridge Technologies is a special-purpose communications platform that can be programmed in C and dynamically reconfigured in nanoseconds. The device has been designed for parallel, real-time communications system processing. Low power consumption has been achieved by design optimization. The instruction set supports simplified decoding for vector and compound operations as well as sleep, nap, and doze reduced-power modes. Multithreading optimizes efficiency by turning off threads and allowing the use of slower latency memories. Finally, the circuitry runs at 0.9 V, and its organization minimizes the number of areas that are active at any time.

The Sandblaster SB 3011 SOC was included in a paper presented at the SDR Forum Technical Conference 2006.(2) In addition, a much more comprehensive discussion of the SB3000 device and its programming environment is available in a separate paper on the company's website.(3)

Sandbridge Technologies has focused on baseband processing, leaving the RF front end and digitization to others. These areas are not trivial, largely because of power limitations and the range of protocols to be covered, each with its own mix of noise figure, bandwidth, sampling rate, and precision requirements.

The Sandblaster DSP

DSP technology provides several benefits. Fast signal-processing computations require the multiply-accumulate units that DSPs typically provide, and historically, DSPs have supported real-time parallel execution. But they aren't programmed in a high-level language. The new architecture combines DSP performance with the advantages of high-level programming.

The current SB3000 features a 64-b compound instruction set in which specific 21-b fields may issue multiple suboperations including data parallel vector operations. Each instruction is completely interlocked and defined so that it has no visible pipeline effects. This means that fast interrupt response is possible.

Four instances of the Sandblaster core are provided in the SB3000 along with an ARM microcontroller that functions as an applications processor. In addition, the chip contains numerous digital interfaces. Connectivity to external systems is via the USB port, and RF and front-end chips are controlled from the JTAG, SPI, and [I.sup.2]C buses (Figure 2).

[FIGURE 2 OMITTED]

Chip performance is reported to be equivalent to greater than 12 Gigabit Ethernet media access controls (GMACs) at a maximum 800-MHz clock speed.

Internally, the microarchitecture uses token triggered multithreading to allow memory access at a slower rate and in a predetermined order. The chip supports 2-Mb/s WCDMA 3G transmission in real time and separately can execute the digital base band processing for GPRS, 802. 11b, Bluetooth, or GPS.

The latest SOC in the series, the SB3500, currently is under development using an enhanced instruction set and extended Sandblaster 2.0 architecture. Chip performance is expected to be 30 GMACs peak. The SB 3500 will support systems up to long-term evolution (LTE) at 50 Mb/s and separately, broadband multiple-input multiple-output-orthogonal frequency division multiplexing (MTMO-OFDM) systems such as 802.1 In and 802.16e including multimedia standards H264 and MPEG4. The new chip is expected to be available in Q3 2008.

On the software side, Sandbridge has developed a vectorizing compiler as well as a simulator based on the same tech- niques. The benefit of such a compiler is in bridging the gap between what a group of C statements means and how that can best be implemented on the target DSP platform.

In the past, this difficult complier problem was approached in a variety of ways. Early DSP architectures were designed for fast operation but not necessarily with compilability in mind. Architectures with very long instruction words (VLIW) improved instruction orthogonality, which helped the complier problem but greatly expanded program size.

Libraries of functions coded in assembly language also can be used to overcome DSP programming problems. Control code can be written in C and the dense signal processing algorithms called from a library. Of course, somebody has to write and test the library functions, but if they are used often, this can be a viable approach.

Finally, you could use intrinsic functions. In this method, the compiler writer provides a list of low-level instructions equivalent to what looks like a C code function call. During preprocessing, the C function is replaced by the list of low-level DSP instructions. This works but has shifted what was an assembly language programming job to the compiler writer.