[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss-gnuradio] EETimes: Va. Tech finds soft radio's missing link
[Discuss-gnuradio] EETimes: Va. Tech finds soft radio's missing link
Mon, 16 Aug 2004 10:16:06 -0700
Internet Messaging Program (IMP) 3.2.1
Va. Tech finds soft radio's missing link
Aug 16, 2004 (9:00 AM)
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
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
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
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.
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.
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
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.
- [Discuss-gnuradio] EETimes: Va. Tech finds soft radio's missing link,
Paul Hartke <=