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 5:45 PM
Subject: Re: TTL computing
> > > The point is, I can't see a real difference between a ROM chip and a
> > > decoder + gates. Electronically they're much the same thing. Physically,
> > > to change the program, I have to use a soldering iron. It is _not_ clear
> > > to me why one is called firmware and the other called hardware.
> > >
> > A ROM chip doesn' have firmware, since it's hard-wired at the factory. A
>
> Are you saying that a program in a mask programmed ROM is not firmware?
> Because everybody else that I know would call it that.
>
There are many who would disagree with them, Tony. One characteristic common
to all definitions I've run into in firmware is that it's FIELD-Programmable.
Another is that it's non-volatile, i.e. persists between power cycles.
>
> > PROM/EPROM/EEPROM, PAL/GAL, CPLD, FPGA or whatever, that you can program
to
> > suit your own definition, falls in a different class. A RAM, which
doesn't
> > retain that definition between power-on cycles, falls into a different
> > category.
>
> And where do you put core memory? Or core-on-a-rope? :-)
>
I do believe the obsolescence of core and plated-wire memory predates EPROMS
and certainly EEPROMS, but although cores and PW were capable of persisting
from one power cycle to another, there were other issues with it. As for
where to put it, if you don't need the stuff, I'd put it in the junk bin I
keep in a remote corner of the basement. That's where my core boards are.
>
> > The distinction between hardware and firmware is in that you can't tell
from
> > looking at the part as you buy it, what it's going to be. If you buy a
7474,
>
> That's a dubious definition at best....
>
> If I buy a 7474, then I know it's going to be 2 d-type ff's. But I can
> choose to use those as 2 bits of an register on a CPU I want to build, or
> as a /4 clock divider, or to do the handshake for a centronics input
> port, or...
>
No matter how you apply it, it's still a 7474, which, since you can touch it,
is clearly hardware, and nothing you do will change that. If you buy a
74S287, it's a 256-nybble tristate PROM, which is, and always will be,
hardware. What you put in it is firmware, and it remains firmware whether you
use it in a state machine or as part of the code in a computer system. If you
buy a CPLD, it's hardware too, and the code you program into it is firmware.
As I've already said, there's opportunity for confusion when you look at an
FPGA, with an external PROM of some sort, the contents of which has to be
loaded up into the FPGA each time the power comes up. Moreover, there's
certainly room for confusion when you consider that what's functionally in the
FPGA when it's loaded up is a CPU (microcontroller) and several peripherals,
including ROM and RAM. It could be considered quite ambiguous in its
character, though the FPGA and PROM are still hardware.
>
> If I buy a PROM, then again I know it's going to store (say) 256 4 bit
> words. But I can use those as a tiny bit of microcode, or as the feedback
> logic for a state machine, or whatever...
>
In either case, it's hardware and what you put in it is firmware.
You need to consider moving forward into the '80's, Tony, since PROMs with
external registers and feedback went out when PALs came down to <$8 each. For
performance reasons, (the PROMs back then being slower than PALs, and costing
nearly as much) building a small state machine using discrete proms,
registers, and steering logic was pretty inefficient and, frankly, quite
silly, since it saved nothing, using more components, more space, more time,
more labor, and more budget. All this stuff is just semantics. You
understand how it all works, and that's what really matters. Whether you call
'em "tomaytoes" or "tomahtoes" isn't that big a deal.
As you undoubtedly can see, how you view the world greatly influences how you
define the terms you use. If you don't see the difference between state
machines and microcode, it's because you don't think of them as blocks in an
executive summary. I'm convinced that the shape and size of components is
heavily influenced by the ways in which they're incorporated in designs. One
thing that makes one see state machines differently than microcode is that
microcode normally took up several PROMs, while a state machine normally lives
in a single PAL. Clearly, if you view things from a perspective of the '70's
you wouldn't be prone to view things using the concept of a state machine as a
single component, which is how it is likely to evolve in a design wherein the
state machine lives in a single block on a diagram.
Received on Fri Apr 12 2002 - 00:18:07 BST