TTL computing

From: Thilo Schmidt <Thilo.Schmidt_at_unix-ag.org>
Date: Fri Apr 12 04:35:48 2002

On Fri, Apr 12, 2002 at 01:48:12AM +0100, Tony Duell wrote:
> 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 :-)
I meant it it's always possible to transform a microcoded state machine
in a not microcoded state machine. So you can design a microcoded control
unit and decide later if you implement it microcoded or not.

> > No, now you don't have a seperate 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.
Your're right, but the ROM would become _large_ indeed.
If your function requires 16 external inputs and 4 inputs for the
current state you already need a 1MBit ROM. Now you need 4 outputs for
the next state and lets say 4 other outputs. So you would need
a 1MByte ROM to implement your machine...

> > 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).
I'm not sure what you mean by "feedback ROM", if you mean an additional
ROM between the outputs an the state latch you have and microcoded state
machine again... ;-)

bye

        Thilo
Received on Fri Apr 12 2002 - 04:35:48 BST