On Wed, Apr 10, 2002 at 01:21:30AM +0100, Tony Duell wrote:
> > 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 stete 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 machine.
On a high level design view it's called state-machine if you draw a graph
and "microcoded" if you write a program.
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...
bye
Thilo
Received on Wed Apr 10 2002 - 02:29:25 BST
This archive was generated by hypermail 2.3.0
: Fri Oct 10 2014 - 23:34:30 BST