TTL computing

From: Richard Erlacher <edick_at_idcomm.com>
Date: Wed Apr 10 08:32:46 2002

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_at_unix-ag.org>
To: <classiccmp_at_classiccmp.org>
Cc: <cthilo_at_unix-ag.org>
Sent: Wednesday, April 10, 2002 1:29 AM
Subject: Re: TTL computing


> 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 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
machine.
>
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
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.
>
> 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
>
>
Received on Wed Apr 10 2002 - 08:32:46 BST