We should be careful here, lest we be accused of inferring that if a computer
has a nand gate, then a nand gate is a computer.
A computer is likely to have several state machines. Defining the computer as
being a state machine is like saying a '747 is a light bulb.
more below ...
Dick
----- Original Message -----
From: "Tony Duell" <ard_at_p850ug1.demon.co.uk>
To: <classiccmp_at_classiccmp.org>
Sent: Wednesday, April 10, 2002 3:50 PM
Subject: Re: TTL computing
> >
> > > 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.
>
> And electronically there's little, if any, difference.
>
Actually, there's a mathematical difference between them, since the microcode
is just to ROM or fuse array content, while the state machine is the
combination of that with the combo-logic and registers that comprise the 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.
>
> Yes, that's what I'd come to accept as well. So basically, if I look at a
> PCB or a schematic I can't tell if it's microcoded or 'just a state
> machine'. I have to know how it was designed. Brilliant!
>
If it's microcoded, there's a complete execution unit the purpose of which is
to execute content of the microcode ROMs. If it's a hand-wired set of
transitors and diodes, or whatever, functioning as a state machine, it's not
microcoded, since there's no distinct microcode. Now if you want to redefine
the logic design as being microcode, that's up to you, but it reduces the
number of folks who'll understand what you mean, not that there won't be quite
a few who're confused no matter what your nomenclature is. I did say it was
a semantic quagmire ...
>
> >
> > 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.
>
> 2 points....
>
> First;y, the second system is also just a state machine. Let's use a
> synchronous counter, which itself is a state machine (look at the
> schematics sometine). Then move the 'counter' ff's into the 'state
> register' (i.e. make it a bit longer) and combine the mux and the counter
> feedback logc into the 'ROM' (more strictly, an arbitrary combinatorial
> logic circuit). It's now of the same form as the first system.
>
> Secondly, and more importantly, many microcoded processors (for example
> the PPD11/45) do NOT have a counter used in that way. Rather, every word
> in the microcode contains a field that gives the address of the next word
> to execute. This field is fed through some combinatorial logic (to allow
> for conditional branches, 'forks', etc) and then fed back to the address
> lines of the ROM. Which means the circuit is exactly that of your first
> example -- the state machine.
>
> >
> > The first design is smaller and faster and the second can be changed more
> > easily...
>
> Why? As far as I can see either can be changed easily.
>
> -tony
>
>
Received on Thu Apr 11 2002 - 00:53:42 BST