Multimode wireless devices: It's the software, stupid!

by Fanny Mlinarsky, octoScope Inc. , TechOnline India - October 13, 2009

The advent of parallel processing architectures is a big step toward realizing seamless, intelligent connectivity among 3G and 4G wireless standards, but the potential show stopper is the software. Thankfully, some companies are making progress when it comes to enabling hardware and software to work together in harmony.

Since the dawn of cellular communications in the mid-seventies, the industry has advanced through three generations of radio standards and is about to launch 4G. New wireless technologies continue to emerge while the old ones linger, forcing wireless equipment, both phones and base stations, to support multiple radio interfaces where interoperability is required.

But as the number of radios grows, implementing them all in hardware becomes increasingly challenging. Multimode radios today must support GSM, CDMA, WCDMA, HSPA+, LTE and other protocols.

Fig. 1: Wireless technology evolution " the 'G's

With the advent of parallel processor architectures, programmable radios are gaining on hardware implementations both in terms of throughput and power consumption. According to John Glossner, CTO and EVP of Sandbridge Technologies, "LTE and WiMAX, are completely different from WCDMA and GSM. When taking a hardware approach you have to replicate the hardware for all of these systems, so the chips get big, expensive and power hungry."

Software defined radio (SDR) has been touted since the early nineties to support the growing diversity of radio interfaces around the world. But, according to Willie Anderson, VP of engineering at Qualcomm, software has been evolving slower than hardware. Though studying programmable radio architectures, Qualcomm is taking a hybrid hardware/software approach with its new HSPA+/LTE MDM9000 silicon.

Many in the industry agree that SDR has been held back by the software. "Programming has been hard and compilers struggle to do a good job optimizing over multiple threads.", states Steve Muir, CTO of Vanu, the pioneer of commercial SDR base stations.

According to Phil Moorby, CTO of Sigmatix, a new entrant in the programmable radio space, "SDR implies a traditional software development approach, but this is completely inadequate for baseband applications. To take maximum advantage of the new baseband processors, we have to move away from the traditional C language semantics and from compilers, which are inherently sequential and limited. The focus needs to be on optimizing the 4G algorithms to the parallel machine operations and memory hierarchies."

Dissecting the radio
Despite its compact appearance, a new generation cell phone is a data communications terminal with a complex medium access control (MAC) and an even more complex physical layer (PHY). The MAC and the baseband component of the PHY are digital and inherently programmable. The MAC has already evolved from hardware to mostly software. The baseband is just starting its journey along the same route.

Fig. 2: Radio block diagram. The MAC and the baseband component of the PHY are digital and inherently programmable. The MAC has already evolved from hardware to mostly software. The baseband is just starting its journey along the same route.

The MAC layer, implementing the access protocol, has already evolved from hardware to software. When Ethernet first emerged, in the early 1980s, its MAC was implemented in dedicated hardware. General-purpose processors were too slow then to run a 10-Mbit/s MAC. Today's 100+ Mbit/s Wi-Fi, WiMAX and LTE MACs are >90% software based, taking advantage of high-speed CPU cores, such as those from ARM.

The PHY consists of a baseband, analog-to-digital (A/D) and digital-to-analog (D/A) converters and the RF front end connecting the device to the antenna(s). The baseband is where modulation and demodulation take place. Modern wireless baseband is a complex DSP-based system implementing multi-carrier FFT/IFFT, forward error correction (FEC) coding and a variety of transmit/receive diversity and beamforming algorithms.

Fig. 3: A single input, single output (SISO) generic OFDM baseband block diagram. For multiple input, multiple output (MIMO) systems, multiple transmit and receive chains are replicated.
{pagebreak}

Baseband processing requires highly parallel operation for some of its subsystems, such as MIMO FFT/IFFT. Convolutional turbo coding (CTC), a forward error correction scheme used in 3G and 4G devices, is particularly notorious for its computing needs and in some products has been relegated to run on hardware accelerators.

Programmable device vendors have solved the computational requirements of the baseband with different architectures (see Fig. 4) and the jury is still out on which architecture will dominate in the end.

Fig. 4: Representative multiprotocol radio devices

Icera took a single-core approach, minimizing the die size of its DXP device. And so did CEVA with their new core IP, CEVA-XC, claiming that programming a single core is easier than programming a multi-core device, supporting the notion that software plays an important role. On the opposite end of the spectrum, PicoChip uses hundreds of small cores (16 bit, 200 MHz DSP) " about 400 cores for the LTE baseband. Some vendors use a dedicated FEC accelerator, finding the implementation of CTC in software inefficient. The Sandbridge Sandblaster relies on three cores and no dedicated accelerators.

Regardless of the subtleties of the architecture, all of these devices require a new approach to software and until the industry converges on a single architecture, the scarce specialized baseband software experts will be spread thin supporting a variety of chipsets. All the vendors claim that they have optimized their hardware for the baseband algorithms that must run on it. In the end, it will be the caliber and efficiency of the software that will determine the winner.

Optimizing baseband software
Baseband software must strike a balance of maximizing throughput while minimizing power consumption " two seemingly contradictory goals. Without specialized compliers, the process requires intense concentration in order to keep hundreds of performance factors in mind at the same time. Though vendors offer compilers tailored to their solutions, there is evidence that most of the programming still involves tedious microcoding by extraordinary software developers. Computationally intensive blocks are made available as function calls and cannot be reprogrammed by the users.

According to Eran Briman, VP of corporate marketing at CEVA, while the users can compile FFT/IFFT operations and build filters, complex and computationally intensive subsystems, such as maximum likelihood decoder (MLD), come pre-coded.

As the inventor of the Verilog language and of the first high performance concurrent HDL simulator, Moorby certainly appreciates the 4G compiler challenges. His company, Sigmatix, is delivering highly optimized 4G soft-baseband platforms that allow engineers to plug in intellectual property blocks, while maintaining the high performance.

Power consumption and performance considerations
Although power management is getting sophisticated for all radios, software based devices have more leverage than their hardware counterparts. An example of this is the operation of CTC. If channel conditions are benign and the error rate is low, turbo decoding requires fewer iterations, which offers an opportunity to reduce computations, something a hardware device may not be able to do. Although it is often assumed that a hardware implementation is more power efficient, highly optimized programmable radios have recently demonstrated dramatic improvements in energy consumption. Combine performance coding with specialized processors and the dominance of hardware implementations in this area may soon be over.

According to Briman, the reduction from 65 nm to 45 nm to 32 nm also helps close the power consumption gap. Smaller CMOS geometries make the difference in dynamic power consumption between software and hardware implementations almost imperceptible.

Achieving specified throughput with reasonable power numbers for various applications is a different story. The LTE Category 3 specification requirement of 100 Mbits/s downlink and 50 Mbits/s uplink is a lofty goal for any handset implementation. However, an MPEG 4 (h.264) stream to a typical cell phone requires less than 1 Mbit/s of throughput and most users are happy with rates of 2 Mbits/s or higher, which feels like a cabled connection. A software-controlled system can vary throughput and power to target maximum speed when required, while coasting on low power when possible.

Concluding thoughts
The vision for a programmable radio is a device that can reload its software fast enough to roam from a GSM network to a WCDMA network to an LTE hotspot without dropping the call or losing an IP session. Several new companies, including Icera, Sandbridge and PicoChip, have introduced devices that can do just that. But, the market has been focusing on programmable silicon while the potential show stopper is the software. Companies like Sigmatix, optimizing the software of programmable radios, stand to make the biggest impact on the efficiency, cost, user experience and ultimately adoption of these devices by the market. Hardware and software must work together in harmony. They are inseparable partners in the quest for achieving optimum power efficiency and performance.

Fanny Mlinarsky (fm@octoscope.comis president of octoScope, a wireless communications consulting firm focusing on cellular, Wi-Fi and wireless broadband technologies. She has 26 years of experience developing data communication and test products. In 2001 she founded Azimuth Systems, the leading wireless test equipment vendor focusing on Wi-Fi, WiMAX and LTE. Fanny is an authority on wireless performance metrics for a variety of applications, including data, voice and video. Her expertise spans RF, PHY, MAC, transport and application layers. Fanny frequently publishes articles on wireless communications and participates in industry standards development.

Comments

blog comments powered by Disqus