10 Apr
2002
10 Apr
'02
8:32 a.m.
Actually, it's all done with software. You simply specify what you want and
tell the software tools to generate it. Part will be implemented in firmware,
and par in software to execute on the uniquely generated CPU. The trick is in
knowing what you want before you start. If you don't you can't design
ANYTHING. Unfortunately, that's how we get to CPU's like what Intel turns
out, and software like Windows.
more below ...
Dick
----- Original Message -----
From: "Thilo Schmidt" <Thilo.Schmidt(a)unix-ag.org
To: <classiccmp(a)classiccmp.org
Cc: <cthilo(a)unix-ag.org Sent: Wednesday,
April 10, 2002 1:29 AM
Subject: Re: TTL computing
I think the distinction lies within the design
methodology. What's commonly
referred to as a "state machine" is designed knowing all the states that will
be used. That certainly can't be said of a microcoded CPU, which is normally
designed as a superset of all the required states. The microcoded CPU does
offer a solution which, ultimately, can be realized. Since the combination of
engineering and management seldom can fully specify their requirements, more
> On a high level design view it's called
state-machine if you draw a graph
> and "microcoded" if you write a program.
Today's tools require that you write a
program. Whether you do it in C++ or
VHDL is up to you, but it's a program either way.
> On hardware-level you use a ROM for outputs
and some logic to
> compute the next state for a microcoded design. In a state-machine-design
> both the outputs and the next state are computed by a single logic block.
> State Machine:
> ---->|------|--- > IN ---->|State |---> OUT
> ---->|Mach. |--- > |
|
> |-->|______|--| next state
> | |
> --[StateReg]<-|
> Microcoded Machine:
> ---->|---|--- > IN ---->| R |--- > ---->| O |---> |--[Counter]
> | M |----| |
> |-->|___| \MUX/<--- IN
> | |
> |-[StateReg]<--
> The MUX selects if next state is the next
ROM-Address (counter) or
> an Address supplied in the ROM.
> The first design is smaller and faster and
the second can be changed more
> easily...
While this may have been true a decade or more
ago, it's no longer the case.
The "next-generation" tools will take a program in a high-level language and
specify both the hardware and the software from a single source file,
including the architecture and instruction set of the CPU if there is one.
The software tools will determine which part goes in the FPGA and which goes
on the hard disk.
> bye
> Thilo
On Wed, Apr 10, 2002 at 01:21:30AM +0100, Tony Duell
wrote:
[...]
machine.
Tony,
you're wandering into the semantic quagmire of distinction between
hardware and firmware and software.
Yes, I know... The point is that many of these terms ('hardware',
'software', 'firmware', 'microcode', 'state machine',
etc) don't have
absolutely rigorous definitions. OK, we all know what, say 'firmware' is,
but then if I wire up a pile of gates to replace a ROM containing a
program (which is what we'd call 'firmware'), is the result
'firmware',
'hardware', both, or neither :-) Perhaps you can give me a defintion of state
machine which excludes a
(microcoded) processor. I will accept that not all state machines are
microcoded processors, but I'll have difficulty accepting any form of
processor that's not a state machine.
Here we have a fine example of what happens when computer-science meets
electro-engineering...
Mathematically there is no difference between a state-machine and
microcode. Both are just different methods to describe a finite state from lack of discipline than lack of ability, supersets
are what one normally
sees. That's why there are so many "bugs" that
crop up. If engineers were
allowed to design and build what's required instead of leaving unterminated
"stubs" for future enhancements (which will never be implemented anyway) they
could devise something more closely approaching bug-free products.