TTL computing

From: Richard Erlacher <>
Date: Sat Apr 13 03:25:31 2002

see below, plz.


----- Original Message -----
From: "Tony Duell" <>
To: <>
Sent: Friday, April 12, 2002 7:53 PM
Subject: Re: TTL computing

> > > One conculsion you can draw from this is that there are therefore
> > > combinatorial functions you can implement in the PROM that you can't
> > > implement in the PAL. One trivial example : It's not hard to program a
> > > 4*4 (giving 8 bit product) multiplication table into a 256 byte PROM. It
> > > is (I believe) impossible to do the same using a 10L8 PAL.
> > >
> > 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?
This is about semantics, after all. Problem is, we're addressing different
parts of the issue.
> > inefficient. By way of contrast, it is straightforward enough to build a
> > 32x32 multiplier into a sincle CPLD/FPGA of reasonable proportions. I
> > that it's easy to build a ROM lookup table capable of accomplishing the
> > thing into a ROM. As for the small multiplier, I think the TTL part that
> > that is a 74S274 or thereabouts. It's a wallace tree multiplier, and the
> > basic unit was, I think, 4x4. There's also a '284 and '285. None of
> > are as small as the 256x8 PROM, but they're expandable, which the PROM is
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
just used a 32x8 a couple of days back and that's what I was tinking about.)
> You do realise that the '284 and '285 are pre-programmed 256*4 ROMs (or
> maybe PROMs, I don't know), I take it. They're programmed to provide the
> high nybble and low nybble of the 8 bit product.
> And yes, they're expandable _as is any other PROM-based implementation_.
> You use the well-known bit of algebra to combine 4 4*4 multipliers and
> some adders (probably Wallace tree, but any adder can be used in theory)
> to make an 8*8 or larger multiplier.
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
of waste. I don't suppose it matters, though, at least from the user's
standpoint. The '275 requires only one adder between four devices to generate
an 8x8 multiplier, and, having been forced to look at the multipliers' ('274,
'275, '284, '285) datasheets, which I hadn't done in a decade or so, I see
they're not really any more expandable than a PROM would be. There may be
some later versions which help a little more with the expansion.

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
latch with the prom without reducing the number of external inputs. BTW,
you've limited the selection of PALs to combinatorial parts, while the
registered PALs are the ones normally used in state machines. How do PROMs
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
same, though that requires extra registers.
Received on Sat Apr 13 2002 - 03:25:31 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:34:30 BST