Issue
142 May2002
Design
Your Own Microprocessor
by
Jim Turley
SOFTWARE
IN, HARDWARE OUT
Celoxica
has a hardware-design tool called Handel-C (see Figure
4). It’s a language somewhat similar to Verilog and,
you guessed it, C. It’s more like C programming than
Verilog modeling. The idea is to let programmers define
hardware, even if they don’t really know what they’re
doing. In fact, Celoxica considers it an advantage if
you don’t have hardware design experience. "Let
Handel-C do the job, and you won’t be disappointed,"
they say.
|
|
Figure
4—Celoxica’s Handle-C is similar to C, but instead
of producing a program, it creates a circuit design. |
This concept is certainly appealing. Theoretically you
can throw source code written in Handel-C at Celoxica’s
compiler and what will emerge is not a program but a
hardware description of a circuit that executes that
program. It’s a kind of hard-coded processor tuned for
exactly the program you gave it. Don’t bother looking
under the hood because you don’t want to know what’s
there. Dyed-in-the-wool hardware designers might gag
at the circuits that Celoxica’s tools produce, but that’s
not the point. A hardware engineer didn’t produce it;
an automated tool did. A company could theoretically
dispense with its hardware engineers entirely and replace
them all with C programmers armed with a few copies
of Celoxica’s Handel-C compiler. That’s a scary thought.
In
a similar vein, Agilent and STMicroelectronics have
teamed up to produce a configurable processor with the
mellifluous name of ST210. (STMicroelectronics manufactures
the chip, so they got to name it.) The ST210 is the
first and, so far, the only example of a concept the
group called PICO (program in, code out). The idea is
to let automated tools make design decisions, rather
than relying on engineers or programmers. As embedded
systems get more complicated, the reasoning goes that
hardware design is no longer intuitive. Humans don’t
always know what they want or what’s best. The ST210
is a 250-MHz, eight-way, super-scalar VLIW beast, so
it’s a bit beyond the means of most embedded designers
for the time being.
Along
the same lines is Improv’s Jazz processor. Like ST210,
Jazz more or less defines itself based on the program
it’s asked to run. In Improv’s case, you define the
problem using a complex combination of Java programs
and a visual-editing tool. From these, Jazz extracts
what parallelism it can find and cobbles together the
ideal processor for what you’re trying to accomplish.
What
all three of these approaches have in common is that
the hardware is fixed. After the automated tool makes
up its mind about what the processor should look like,
that’s it. From that point on, it’s a fixed piece of
hardware just like any other chip.
CHANGING
RUN TIMES
Elixent
takes the concept one step further. Yes, it has an automated
tool that defines the circuitry from a source program,
but instead of creating a processor, it creates multiple
hardware implementations and switches among them on
the fly based on the workload (see Figure 5). Elixent
combines the "software in, hardware out" concept
of Celoxica with the real-time reconfigurability of
an FPGA. The result is a programmable chip that can
transmogrify itself for various tasks.
|
|
Figure
5—Elixent combines configurable processors with
field-programmable logic to create a constantly
changing processor. Elixent’s tool switches implementations
on the fly based on your workload. |
Elixent
enters the world of dynamic reconfigurability, or reconfigurable
computing (RC). RC seems like a completely reasonable
concept: change the hardware on the fly to suit the
application. After all, nearly all embedded systems
handle different tasks at different times. One moment
you’re decompressing audio streams, the next you’re
handling an interrupt, and the next you’re accepting
user input. It stands to reason that whenever one part
of the circuit is working the other parts must be idle.
This is often true, but there’s nothing you can do about
it. Hardware systems have always been created from a
superset of all the functions required over the life
of the product, rolled into one.
If
RC takes off, that might change. For example, future
generations of cell phones may use half the transistors
to do 10 times the work. Fewer transistors may be all
that’s needed, if none are wasted on functions that
aren’t required right now. Transistors would simply
be on call; available for whatever was required at the
moment.
Programming
such a beast would be a whole new challenge. How do
you write code for a moving target? According to RC
partisans, you don’t. In Elixent’s case, there is no
software as we know it. The original program was simply
the input function, a way to define what you wanted.
The output function was the hardware itself, which has
all the program information it needs. Cue Twilight Zone
music.
