see below, plz.
Dick
----- Original Message -----
From: "Tony Duell" <ard_at_p850ug1.demon.co.uk>
To: <classiccmp_at_classiccmp.org>
Sent: Thursday, April 11, 2002 6:48 PM
Subject: Re: TTL computing
> >
> > On Wed, Apr 10, 2002 at 10:50:56PM +0100, Tony Duell wrote:
> > > 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!
> > No, as you pointed out below it is possible to implement a microcoded
> > design as a state-machine. You have to seperate the design and the
>
> So given a processor we can't tell if it's microcoded or not by looking
> at the scehamtic. This seems to make the term 'microcoded' fairly useless
:-)
>
> > > Firstly, 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.
>
> > No, now you don't have a separate ROM (or PROM or any other kind of
> > linear addressable memory) any more. The main reason to use a microcoded
>
> Of course I do. It's just a somewhat larger ROM. You do realise that
> _any_ combinatorial logic circuit can be implemented using a sufficiently
> large ROM, right. So all I need to do is pick a large enough ROM to
> contain the original microcode + the logic for the counter, etc. That's
> now all in one ROM. I connect it to the state latch. It's now a state
> machine. It's also, IMHO, the same microcoded system as the original design.
>
You're starting to mix questions of logic with questions of implementation. A
state machine is a logical construct, while a ROM, registers, muxes, etc, are
physical constructs. It's similar to asking yourself whether running a
program under a simulator is equivalent to running the same software on the
native hardware. The effect is the same so they're logical equivalents. They
may be quite different in their implementation.
>
The term "microcoded" in the context in which I've seen it used for the past
three decades has always meant that there's a small primitive computer running
a small primitive instruction set, and it's used to implement, physically, the
more complex structures of a larger system with a larger, more complex,
instruction set and resources. This was a distinction between "microcode" and
"micro code" which refers to what we wrote for our microcomputers in various
applications.
>
> > machine instead of a "pure" state machine is that you can change it
> > quite easily by putting another "program" in the ROM. If you
>
> And why can't I change the functionality of a state machine by changing
> the contents of the 'feedback' ROM? (Hint : I most certainly can do this).
>
> > > > 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.
> > If you implemented the thing in discrete logic it's probably
> > possible to change it by soldering wires all over the board,
>
> Well, I thought the combinatorial part of the state machine was also
> implemented using a ROM. It's certainly possible to do this (and at one
> time it was very common).
>
Using a PROM to implement a combinatorial path has always been the most costly
way to do it. I don't think it was as common as you suggest. Such an
application is likely to lead to very sparse ROM utilization. The ROM has a
fixed Or and fixed AND array, hence has to have many more registers in it than
a programmable logic device capable of the same logic, and, likewise, many
more than the equivalent logic implemented discretely in SSI/MSI logic.
You can convince yourself of this by simply examining some old PAL designs for
various encoder/decoder schemes using PALs (just as easily understandable as
discrete logic) as posted on the LATTICE web site, as examples of SPLD (PAL)
applications from the '80's, and then considering the amount of ROM space that
they'd require if simply implemented in a ROM with registered feedback. You'd
need a single 22V10 for an MFM encoder/decoder while a ROM would have to be
prohibitively wide and deep.
Received on Fri Apr 12 2002 - 00:34:13 BST