[Discuss-gnuradio] EETimes: Va. Tech finds soft radio's missing link

[Paul Hartke]

Va. Tech finds soft radio's missing link
Patrick Mannion 
Aug 16, 2004 (9:00 AM)
URL: http://www.commsdesign.com/showArticle.jhtml?articleID=29100148 

Manhasset, N.Y. — Riding a wave of innovation, software-defined radio may 
finally be on track to deliver on its promise as the future of wireless 
communications. But even as software breakthroughs ignite fresh hopes for 
SDR, the hardware side is still a hard case.

There are three traditional barriers to SDR: a low-cost, low-power, 
frequency-agile front end; portable software that can be implemented on any 
platform; and low-power processors on which to perform that processing. 
While the last requirement remains elusive, help is on the way for software 
portability. Researchers at Virginia Tech say they have developed a 
software framework that will be the foundation for all future military 
radios — and could serve as the missing link for commercial SDR.

Called the Software Communication Architecture, or SCA, the framework 
derives from the U.S. government's need to have a common SDR definition 
that would allow any company to write any waveform onto any radio. "This 
would free it from expensive and complex proprietary SDR implementations 
and open the door to outsourcing and competitive bids," said Alan Gatherer, 
CTO of wireless infrastructure at Texas Instruments Inc. 

The lack of such a framework has proven to be the biggest barrier to entry 
into software-radio research in general and the Joint Tactical Radio System 
(JTRS) community in particular, said Jeff Reed, a professor in Virginia 
Tech's engineering department, part of the Mobile and Portable Radio 
Research Group (Blacksburg, Va.) that released the SCA. The key to the 
architecture, he said, is that it is free, easy to use and written in a 
language — C++ — that is common to most wireless developers.

"Basically [SCA] is middleware glue for assembling SDR from components, and 
it is the required framework for all U.S. military radios below 2 GHz — and 
eventually all radios," said Reed. "We're releasing this now as an 
educational tool." 

The military, which is a driving force behind software-defined radio, has 
mandated that any radio developed for JTRS must be implemented in the SCA 
environment. The JTRS has been allocated more than $25 billion to develop 
SDR capability for the military. In addition, efforts are under way to make 
SCA a global framework for radio development. 

One day, Reed said, commercial radios will be designed this way too, "using 
modern software practices — and we need to start teaching communications 
engineers how to do this." Work is already under way, he added, "to go 
beyond 2 GHz."

As a concept, SCA is not new. What is new is an open-source version that 
distilled SCA down to its essential elements and then ported the 
architecture to C++ so that any engineer can get up and running quickly for 
development purposes. 

Reed is convinced that commercial organizations will soon start adopting 
the SCA — or something similar. And he is not alone. "All my customers want 
a middle layer, a framework and to abstract hardware — essentially SDR," 
said TI's Gatherer. However, this is proving impossible given the many 
proprietary implementations, he said. "If we could get all the big 
communications companies to agree to adopting SCA 3.5 or 4.0, it will 
become the de facto standard as to how you put together a middleware 
framework." 

The open-source version of SCA is called Ossie, for Open-Source SCA 
Implementation::Embedded. Its underlying philosophy, according to Reed, is 
simplicity. The idea was to establish a framework for entry-level graduate 
students to familiarize themselves with the specifications and quickly get 
to the point where they can perform meaningful research. The initial 
release, version 2.2, leverages ACE/TAO, an open-source implementation of 
Corba; Xerces XML, an open-source XML parser; and Windows 2000/XP. Ossie is 
available for download from www.mprg.org/research/ossie. 

While the goal is to bring SCA to the commercial market quickly, the 
current iteration is too processing-intensive for that, said TI's Gatherer. 
However, Reed said that plans are afoot to get rid of the common object-
request broker architecture altogether, since Corba is the main source of 
the processing overhead. "Corba also limits your ability to do I/O, as it's 
very microprocessor-centric," Reed said. He said Ossie version 3.0, which 
is due soon, will have those modifications. 

Processing foundation 
Things are far less rosy on the hardware side, which has sustained repeated 
blows over the last three years as reconfigurable architectures failed to 
meet expectations in the classic trade-off between programmability and 
performance. While code portability makes progress through efforts such as 
SCA, the processing hardware underneath faces changing, multiplying and 
ever-higher-rate wireless interfaces. In particular, Release 5 of the 3GPP 
specification — known as High-Speed Downlink Packet Access (HSDPA) — is 
proving exceptionally onerous, with theoretical aggregate data rates of up 
to 14 Mbits/second.

Found wanting 
Carriers are demanding full implementation of HSDPA in the 2005-06 time 
frame, said Ron Craig, 3G chip set architect at Freescale Semiconductor 
Inc. Add to that the rise of WiMax, the need to support converged Wi-
Fi/cellular access with seamless mobility, digital TV reception (DVB-H) and 
other standards, and many architectures, both reconfigurable and 
conventional, are found wanting. 

"All these new standards are just so much harder," said Rupert Baines, vice 
president of marketing for picoChip Designs Ltd. (Bath, England). Third-
generation cellular "up to Release 4 was difficult, but HSDPA and MUD 
[multiuser detection] just break a lot of architectures." PicoChip is one 
of many startups pushing a reconfigurable processor, but while it claims 
ongoing success with design wins for indoor applications — with others 
pending — the reconfigurable landscape is littered with failures. 

Most recently, Quicksilver Technology Inc., the reconfigurable trumpeter 
with its Adaptive Computing Machines technology, has hit the skids. 
According to a spokeswoman, Quicksilver is now licensing its intellectual 
property (IP) to companies such as Chips and Systems (www.chipsag.com) and 
is positioning itself for a sale or to partner with others in the industry. 
The Seattle company has a solely engineering staff of 20 and is currently 
focused on developing the software with an eye to ease of use. 

While Quicksilver attributes its descent to the reluctance of designers to 
move from ASICs to a software platform, observers point to more fundamental 
flaws. Some say that Quicksilver couldn't decide whether it was an IP 
company or a chip company, that it failed to offer a full solution and 
neglected to take customers by the hand to full product realization — a 
particularly egregious mistake given the complexity of the ACM architecture 
and software. 

Also, according to sources, the company made the mistake of partnering with 
a company (AOI in Japan) on an implementation that it couldn't show off as 
a working example. The Quicksilver spokeswoman conceded that the company 
has made some "management changes" but said that "different people have 
different takes" on the business model.

But Quicksilver is not alone in its troubles. Sandbridge Technologies Inc., 
which is embracing the concept of SDR for handsets with a low-power, 
efficient architecture, has suffered delays in its delivery cycle and, 
according to multiple sources, is not delivering on its performance claims 
for 3G handsets. However, CEO Guenter Weinberger said the delays were 
caused by a faulty piece of third-party IP for Sandbridge's 0.13-micron 
implementation, which is still due for completion by year's end, with 
volume production by late 2005 or early 2006. Refuting the performance 
claims, Guenter said the company can do 3G at 384 kbits/s now and has a DVB-
H platform already in place. As for HSDPA, "we can scale to it, but right 
now we're maintaining our current platform and concurrently thinking about 
our position on how to operate it for that."

The hardware hassle is more fundamental than just improving upon current 
reconfigurable architectures to meet SDR and high-rate demands, said Mark 
Cummings, managing director of enVia II (Atherton, Calif.) and chairman of 
the board of directors of the SDR Forum. Owner of early SDR patents, 
Cummings said that the current "first-generation" reconfigurable processors 
still trade off processing power with programmability and ease of 
implementation, in terms of development, debug and verification. 

On to second generation 
"I thought these first-generation companies would find a compromise that 
would meet the market requirements, but what's becoming clear is that it is 
difficult or impossible, and that is what leads me to the conclusion that a 
second-generation processor is necessary." Cummings is adamant that a 
second-generation architecture that eliminates this trade-off is possible, 
although he would not provide details.

Though the market is fraught with difficulties, the startups keep coming. 
And the need is there, said Martin Gibson, a partner in Atlas Ventures, 
which funded picoChip and Sandbridge as well as Icera Inc., a Bristol, 
England-based fabless IC startup. "We believe it's possible to do the 
processing on a reconfigurable architecture," he said, "and as standards 
evolve and we move to 3G it's more important." 

Stan Boland, president and CEO of Icera, said that the task wasn't so much 
about making a software-defined radio that can handle all interfaces, but 
about improving the system performance — and the economic model for 
carriers — through more efficient designs that can be tweaked on the fly to 
adapt to channel characteristics. Still in stealth mode, Icera was formed 
just over two years ago and has received $33 million to date. Silicon is 
expected "soon," Boland said.