Motorola working on a VLIW processor............
Motorola recharges the VLIW DSP debate
By Stephan Ohr
with additional reporting by Ron Wilson
AUSTIN, Texas - Add Motorola Inc. to the list
of companies that plan to leverage a
very-long-instruction-word (VLIW) architecture in
a digital signal processor. News that Motorola is
betting on VLIW for at least one future DSP may
trigger a new round of debate within a growing
circle of companies that have tapped, or tripped
over, this contentious approach for using software
to extend processor performance.
Fred Shlapak, senior vice president and general
manager of mixed-signal technology, tipped
Motorola's plans to use VLIW during a
conversation about StarCore, a joint-development
project with Lucent Technologies Inc. (Murray
Hill, N.J.). VLIW is a central component of one of
three or four separate DSP projects currently in the
works as Motorola looks at ways to implement
third-generation cellular, said Shlapak. PowerPC
cores, low-voltage RF and flash memory are
among the other technologies being considered.
But any conjecture about another VLIW entry is
bound to cause a stir. DSP leader Texas
Instruments Inc. (Houston) has taken hits for the
VLIW architecture embodied in its groundbreaking
C6X, which critics call power hungry and difficult
to use. Others using VLIW, like Philips
Semiconductors' TriMedia Group (Sunnyvale,
Calif.), have scaled down the number of
applications they are prepared to support.
Media-chip maker Chromatic Research (Mountain
View, Calif.) has abandoned the technique, while
startup Equator Technologies Inc. (Seattle) vows
to use it.
Motorola was quick to assert that VLIW would
not be part of the joint-development deal with
Lucent. "There is VLIW effort, but it's only in a
laboratory stage," said wireless product marketing
director Rhonda Dirvin. "VLIW has its down sides,
and there's other ways to get DSP performance."
Neither Dirvin nor Shlapak would offer more
details. But Moto and Lucent are jointly slated to
present a paper at the Microprocessor Forum in
October on "a highly parallel fixed-point DSP that
promises to expand the envelope of DSP
performance."
Motorola DSP architect Kevin Kloker, soon to be
named a co-leader of the StarCore development
team, was unavailable for comment. But James
Boddie, who heads Lucent's side of the StarCore
effort, gave this assessment: "VLSI technology
allows us to put many resources on one chip. The
question is, how do we control those resources?
VLIW? Superscalar? Multiprocessor? For
StarCore, we will look at all of these."
VLIW depends on compiler technology, Boddie
said. The architecture alleviates the need to
program in assembly, but it is not code-efficient
without what Boddie calls "instruction-level
parallelism. Without [it], you'll have sparse use of
[program] memory with many 'no ops.' "
Lacking high code density, you need more memory
and that increases system costs, said Boddie. In
cellular handsets, very high code density reduces
the amount of memory required. It also cuts the
number of cycles needed to access memory -
and that conserves power.
Indications that VLIW is slipping from its pedestal
even among adherents came in Philips
Semiconductors' unveiling of the next TriMedia at
the Hot Chips conference in Palo Alto, Calif. While
the next-generation design inherits a pure VLIW
base from its predecessor, the TriMedia 1000, the
new chip overlays that base with a very un-VLIW
construct: purpose-built, fixed-function execution
units.
"We found that there were certain operations that
were quite difficult to code in the existing VLIW
instruction set," said Joss van Eijndhoven of Philips
Research Labs. Consequently, the architects
outfitted the next-gen architecture with "SuperOps"
- operations that can have up to four arguments
and two results, and that are better suited to some
media-processing needs. Examples offered by van
Eijndhoven are vector-mixing, half-pixel averaging
and vector-rotate operations.
Such operations break up the conventional flow of
VLIW instructions and force those writing
compilers and assembly code to break a sweat.
But they can have a remarkable impact on
throughput, van Eijndhoven said. For example, he
said the presence of only two SuperOps - an
application-specific shift and a 2-D average -
could reduce an MPEG block
motion-compensation task from 82 machine cycles
to 31.
More.............
eet.com |
