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

> > 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

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.

> pretty small. The PROMs (256x8) that I've got are in 20-pin packages.

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

> '285 but it appears that a 256x8 PROM would do the job, so I suspect

> right. However, the PROM would have twice the number of bits really

> since 3*5 = 5*3, and I'm convinced the TTL parts have gotten around that

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.

> don't allow for internal feedback, so you can't generate a

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. 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

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

> you to specify the transitions explicitly from this state to the next

> inputs, and outputs based on this state. The latter two don't have to be

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

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.