see below, plz.
Dick
----- Original Message -----
From: "Tony Duell" <ard_at_p850ug1.demon.co.uk>
To: <classiccmp_at_classiccmp.org>
Sent: Saturday, April 13, 2002 5:18 PM
Subject: Re: TTL computing
> > > > That's a lookup table, however, and not a multiplier, and terribly
> > >
> > > Of course it's a multiplier. You give it 2 numbers, it gives you back
the
> > > product. I'd love to see a definition of 'multiplier' that excludes
> > > look-up tables.
> > >
> > There surely isn't one, but wait a minute, now ... can you have it both
ways?
>
> You were the one who claimed it wasn't a multiplier...
>
> And yes, I think you can have it both ways. A 'multiplier' is a device
> (in this case a digital electronic circuit) that takes in 2 numbers (in
> this case expressed in binary notation) and returns the product. A
> 'lookup table' is a way of implementing combinatorial functions (I am
> not going to attempt to define it, because I am sure you know what it
> means). There is no reason at all that a circuit based on a lookup table
> can't be a multiplier.
>
> ['284 and '285]
>
> > Now that I've looked the sheets over, I see that the parts are no more
> > expandable than a PROM would be, but the parts are only 16-pin types.
That's
> > pretty small. The PROMs (256x8) that I've got are in 20-pin packages.
(I
>
> They're 256*4 PROMs, which is why there are 2 of them...
>
> Look at the pinout as well. The 2 active low enables (which are _never_
> used in the multiplier circuit) are one oddity. So is the fact it has
> open-collector outputs.
>
> The reason for both, of course, is that these devices are really
> programmed 256*4 PROMs (it's one of the standard ones, but I don't feel
> like getting the databook out now to look up which one).
>
> > They don't show the logic diagrams (you've forced me to look) of the '284
and
> > '285 but it appears that a 256x8 PROM would do the job, so I suspect
you're
> > right. However, the PROM would have twice the number of bits really
necessary
> > since 3*5 = 5*3, and I'm convinced the TTL parts have gotten around that
bit
>
> Well, OK, suppose we elimiate some of the entries in the lookup table
> (it's less than half, because the terms 'on the diagonal' -- the perfect
> squares like 2*2 and 5*5 -- have to appear in the table). We then have to
> add some external logic to swap over the input numbers so that the
> smaller one is on one set of inputs always. That sounds as much work as
> just having the complete table in the first place.
>
> > One thing you've got to consider yet, however, is combinatorial loops.
PROMs
> > don't allow for internal feedback, so you can't generate a
combinatorial-loop
>
> As soon as you allow feedback, the circuit is no longer combinatorial.
> It's sequential. The definition of a combinatorial circuit is that the
> output depends on the inputs _now_ only, and not on some internal 'state'.
>
> Yes, you can make a sequential circuit from combinatorial parts, but
> none-the-less the result is truely a sequential circuit. The simplest
> example I can think of is the SR flip-flop made from 2 NAND gates.
>
> > latch with the prom without reducing the number of external inputs. BTW,
> > you've limited the selection of PALs to combinatorial parts, while the
>
> That's because I was comparing PALs to PROMs (the latter being strictly
> combinatorial)
>
> > registered PALs are the ones normally used in state machines. How do
PROMs
>
> True, but irrelevant IMHO.
>
> The whole point of a state machine in electronics is that it allows you
> to represent a large class of sequential circuits as a row of D-type
> flip-flops (the _only_ sequential part of the cirucit) and a block of
> combinatorial logic (the 'feedback logic'). Then you can use all the
> methods you know for designing and simplifying combinatorial logic to
> handle state machines (and thus a large group of sequential circuits) as
> well.
>
> A Registered PAL is the standard PAL array with D-types on the outputs,
> the outputs of which are fed back as inputs to the logic array. Yes, it's
> ideal for making state machines, but it's not the only way to make state
> machines. You could equally well take a non-registered PAL or a normal
> PROM, connect the outputs to the D inputs on some flip-flops (say a '574,
> since you like real, physical, devices), and link the Q inputs of that
> back to inputs on the PROM or PAL.
>
> Of course nobody would do it that way if they had registered PALs
> available, but that's not the point at all. You _could_ do it that way,
> you'd still be making the same state machine.
>
>
> > work for you there? There are registered PROMs that will hold the present
> > state for you, but how does that work for you toward your FSM? The PAL
allows
> > you to specify the transitions explicitly from this state to the next
based on
> > inputs, and outputs based on this state. The latter two don't have to be
the
>
> OK, I'll take a PROM (say 256 * 4). I'll link the outputs to 4 D type
> flip-flops (a '175, OK). I'll link the outputs of those flip-flops to 4 > of
the address inputs (say A4..A7) of the PROM. And connect my external
> inputs to the other 4 address lines.
>
> That's a state machine. Each address in the PROM corresponds to one
> combination of current state (the 4 bits from the flip-flops) and the
> external inputs. I program into each address the number of the state I
> want to go into based on the current state and the inputs. Nothing more
> complex than that.
>
You might want to consider a second PROM to generate outuputs to cover the
cases wherein the state bits don't correspond with the desired outputs ...
Clearly, however, you must see the advantages of being able to combine that
into a single device. The function you've described certainly will fit into a
small PAL without any external interconnection. So you've got 4 state
registers and 4 external inputs. That would probably fit a 16V8, and leave
you 4 more bits which you might choose to use for output.
Received on Sun Apr 14 2002 - 04:39:18 BST