This argument is still over the same things about which we always end up
arguing, namely how things SHOULD or COULD be, vs. how they are. What's
possible clearly isn't as important in the world in which I live as what's
REAL.
I live and die on what's real. Engineers don't get paid for coming up with
things that SHOULD be. The things that exist only in the subjunctive don't
pay my bills.
see below, plz.
Dick
----- Original Message -----
From: "Tony Duell" <ard_at_p850ug1.demon.co.uk>
To: <classiccmp_at_classiccmp.org>
Sent: Sunday, April 14, 2002 2:46 PM
Subject: Re: TTL computing
> > > I've had semicondcutor RAM fail, albeit not DRAM in a PC. 2114s are
> > > particularly bad for this.
> > >
> > I don't think it's the parts, but, rather, the way in which they're used.
I
>
> Hmm.. I've had so many 2114s fail, in equipment from different
> manufacturers (examples : a Commodore 8050 disk drive, a TRS80 Model 3
> (video RAM) and an HP82163 video interface) that I really suspect the
> chips...
>
> > have noted that 2114's seem to have a problem. I also wonder at the
relative
> > freedom from memory problems in the PC environment. I did occasionally
have
> > memory problems back in the CP/M days, mostly due to poorly timed DRAM
> > circuits.
>
> I've had problems in PCs due to poorly designed memory boards (ground
> bounce and power line noise, for example), but that's not the fault of
> the memory chips
>
Verly likely, but not something I've run into, myself.
>
> > >
> > > > > > A PAL can generate any combinatorial function of its inputs. A
prom
> > can
> > >
> > viewing its inputs in terms of the fact that PALs generally have 8 or more
> > outputs, and in view of the fact that those separate outputs may not want
to
>
> For combinatorial circuits, having <m> outputs just means having <m>
> times the complexity. So for the purposes of discussion it's reasonable
> just to consider one output (this applies to both PROMs and PALs).
>
> > share product terms, there are limitations on the common small PALs.
However,
> > if you choose a device comparable to the PROM, they'll do it.
>
> You were the one who started off claiming a PAL was simpler than a PROM.
> Now you're claiming that 'if yuu pick a comparable device it'll do it'.
> I'll agree with that. If the device is sufficiently complex, it doesn't
> matter which matrix (AND or OR) is programmable. But the complexity of
> the device (and the number of bits taken to program it) will be
> comparable for a complete PROM with 2^n locations and a PAL capable of
> generating _any_ combinatorial function of n inputs.
>
It is MUCH simpler in its application. Most of the time, though a PAL has,
say, 16 inputs, you use three or four of them for a given output, and you use
a couple of the outputs in feedback. You use the internal registers because
that way you don't have to wire the feedback externally, nor do you have to
surrender PROM address inputs in order to use them, since they're already
connected. The reason they "get by" with a relatively small fuse array, is
because you generally want a couple or three inputs in various combinations,
which become your product terms, and you want the feedback applied to those
inputs as well, so you may end up with as many as 5 or 6 product terms per
sum, but seldom the entire 8 or more that are avaialble. If you do need
more, there are devices that provide them, and you use one of those devices.
In a PROM, regardless of how many imputs you want, you have to program them
all, and there's no software that does it for you. That in itself is already
less simple, since you now have to come up with a bitmap for the prom size
you're using. It's not difficult with a small prom, but with a bigger one it
quickly becomes a burden, so you write an application to do the bitmap
generation. Once you've done that for every size of memory that you intend to
use, you're done. I don't know where you'll get a PROM with 16 address lines
and address-access times on the order of what a PAL delivers, but that's
another issue.
The fact is that what people wanted when PALs were being developed as a
product concept was a small, self-contained unit that could be defined and
programmed separately from its PCB environment and externally modified, if
requires, just as a bipolar prom would be. The business of utilizing them
fully was easy to handle because each output was programmable as an entity
unto itself even though the final device was integrated together with several
unrelated functions. All that's quite straightforward to work out in either a
PAL or a PROM. You need a "fuse" to each product term in the entire array,
and whether the "fuse" is open or closed, each one has to be dealt with. SO,
if you have 7 product terms per sum term, and have 8 sum terms, and 16 inputs,
then you have to support a fuse array of 32 x 56 for the logic and 32 x 8 for
the control terms, if that's what it takes, as in a 16L8.
>
> > > Any real PAL has a limited number of OR terms for each output.
(typically
> > > around 8 or so).
> > >
> > What this suggests is that you've chosen the wrong device. You can't do
the
>
> Oh, for %deity's sake, this has got totally ridiculous...
>
> If you are claiming that _in principle_ a device with only a programmable
> AND matrix can genearate any combinatorial function then I'll agree with
> you -- provided the number of product terms is large enough. But most
> (all?) real PALs have a limited number of product terms. For many
> real-world applications there are enough product terms. But there are
> still functions you can't generate if you wanted to.
>
NO, what I'm saying is that there's a device to fit whatever your application.
If a PROM will do it, perhaps that's the right choice, but it's going to be a
bigger prom and it may require extra devices to finish the job. The PAL makes
it simpler because you can design your PCB knowing that your logic can be
designed as a separate task with complete confidence, since you do know what
your inputs and outputs will be and that your functions can be fit in that
device footprint.
Now, I've used, say, an ICT 7024 to correct a layout error, e.g. where the
layout of the part was upside down, with inputs where the outputs go, and
vice-versa. The 7024 has outputs on all the pins except the corner pins, and
they aren't outputs on a 22V10.
>
> > same things with ANY device. Take a look at the spec for the 16V8 and
compare
> > it with the 42VA12. Clearly, they have different size "fuse" arrays, and,
if
> > you want to program the device such that it produces functions of a size
that
> > consumes the entire "fuse" array, then you'll end up with a single output,
but
> > you can implement that function. With the 42VA12 you have 64 product
terms,
> > each of which can have any combination of the 42 inputs. On the 16V8 you
have
>
> OK, you have 42 inputs, and let's just consider having one output. Tell
> me, does it take 4 terabits (=2^42 bits) to specify the programming fuse map
> for that one output? Because if it takes less, it's clear to me there
> must be some functions you can't implement. If you don't understand this,
> then _please_ read some books on electronics and/or mathematics before
> going off on some other tangent.
>
You can program both the AND and OR arrays, Tony, so the functions you would
want to create are quite a bit more flexible. If you need all combinations of
the 42 inputs, you do, indeed need a PROM. If, however, you consider REAL
WORLD problems and their solution I've got some difficulty conceiving of a
logic function that would consume the entire resources of a 42VA12, in real
terms. I know, you could want to detect an access to a particular location
within a large address space, which would, of course, require a pretty large
gate. That's a single function of the input range, though, and it would take
only one product term.
I'm having some difficult getting my hands aroung what you're suggesting about
the apparent lack of ability of the PAL device type, Tony. Could you provide
an example of a logic function that couldn't be specified in a 42VA12? I'm
sure they exist, but, speaking in real-world terms, I don't see a need for
them. That's why the 42VA12 is no longer offered, having be replaced with
another device of a more flexible, yet efficient, architecture. If there's a
unique logic function, as you've said, a single product term should handle it,
and if there is some strange logic function that requires a multi-Tb PROM, I'd
be interested in just exactly how you're planning to specify it.
>
> > less flexibility. MANY functions will fit in a small device like the
16V8.
>
> I don't dispute this at all. Yes, PALs (and GALs) are useful. They will
> handle many real-world logic functions. So?
>
> > It has a relatively small fuse array, in general, smaller than what's in a
> > PROM, though it's larger than 32x8.
> > >
> > > So I take my function. I write it in SOP notation. I combine terms that
> > > differ by one containing a particular variable and the other containing
> > > its inverse when all other variables are the same (like
> > > A.B/.C.D/.E + A.B/.C/.D/.E -> A.B/.D/.E).
> > >
> > You can let the software deal with optimizing that process, and in
assigning
>
> Oh, not again!
>
> Of course you can use software to do logic minimisation. But software
> can't minimise an expression that can't be minimised. Will you please
> stop confusing the tools you use to help you do the work with what's
> actually possible.
>
Partly, the fact it's simple to do enters into the discussion, while what you
propose with a really large PROM requires devices that don't, AFAIK, exist,
nor is it likely they will, and a huge effort in programming the software tool
to create the bitmap you want. Now entering a bitmap manually for a 2^(42)
word PROM, even if such a device did exist, seems a mite extreme. How many
lifetimes would that take? A computer could do it, but you still would have
to generate the map and enter the equations.
What makes the PALs so useful is that they can exploit the programmable link
technology without the designer having to account for all the obvious "don't
care" terms, of which there are usually plenty.
>
> > the polarity of your outputs so the fewest product terms are used. This
one
> > is a single product (OR) term.
>
> Yes, of course. That's what the '->' symbol was trying to say. I was
> saying that the 2 terms on the left could be combined into a single term
> on the right...
>
> Now here's an expression that can't be further minimised : A.B + C.D .
> THat takes up _2_ product terms. And you can write a function of the 16
> inputs of (say) a 16V8 that needs more than 8 product terms to express
> it, even when fully minimised (whether by hand or by your beloved program!)
>
I do love the software, since it does what would take me a very long time in
just seconds. What's more, it's been tried and optimized for years, so it's
quite close to bug-free, which I'm not, even though I've been trying for a
longer time than it has.
If you read the fine print in the 16V8 spec, you'll see that you can feed the
outputs from one OR gate to the poduct term array, thereby allowing you to
incorporate that as a single product term into another sum. If you're using
the entire fuse array, you have nearly the equivalent of a 256x8 PROM, which
is what you should use if that's what you need. Of course, you get none of
the benefits of a PAL architecture. The guys who built PALs also built PROMs
and they certainly didn't intend to obsolete PROMs with their PALs.
Ultimately, they did, however, since field-programmable nonvolatile memories
are slower than the electronically reprogrammable logic devices they sell
nowadays, and the conventional usage of such devices has, over the years
defined devices that better suit some of the problems that were, in fact too
large to tackle with the old, small PALs. Of course it's always been a
combination of problems, with device resources at one end and the ability of
the designer to use the resources effectively at the other. I can assure you,
though, that if you can/will write the boolean expression, the software can
fit it in a device that has adequate resources to implement it. Current
generation software even will select a range of devices for you. There once
was a company not far from here that provided a programe called MINC that
would do that from a range of parts that you specified, trading off the costs,
performance, etc, against others that would do the job. XILINX bought them in
order to keep people from beneifitting from that multivendor approach. ISTR
you could even add standard TTL devices to the mix and have it trade off the
costs/performance with them included. That way you could trade off a design
using PALs against one using registers and a PROM. AFAIK, it was the only
such program that allowed the use of multiple vendor-specific devices in a
design. It was expensive software, but I miss knowing it's out there.
> > >
> > > I then end up with more than 8 (or however many OR terms I've got) terms
> > > ORed together in my equation. I can't minimise any more. And I can't put
> > > it into the PAL.
> > >
> > ALL that tells you is that you've picked too small a device, or one with
the
> > wrong architecture. All PLD's don't have to be small ones, just like
ROMs.
>
> Again, I have no problem with that statement. The problem is that the
> 'right ones' (large enough ones) are comparable in complexity to the PROMs.
>
> > > Otherwise, I'll propose the following lossless compression system :
> > >
> > > 1) Read <2^n> bits from a file.
> > >
> > > 2) Regard them as the 'truth table' for an arbitrary <n> input, one
output,
> > > logic function (this step is OK)
> > >
> > > 3) Turn that function into the equivalent 'PAL fuse map' (which you
claim is
> > > always possible, moreover, it takes fewer (than 2^n) bits to specify
this).
> > >
> > > 4) I now write out this smaller number of bits to the output file.
> > >
> > > If step (3) is always possible, then we have a compression system that
> > > reduces the size of all possible input files. Which is clearly
impossible!
> > >
> > > > > > that too, but the PAL does it with fewer fuses.
> > >
> > > > > And that should tell you something is 'wrong'.
> > >
> > Not exactly, since the PROM requires you to represent all the states of
the
> > inputs, while the PAL allows you to use only the ones that are relevant.
>
> Do you seriously believe that the compression scheme I've proposed can
> always work? Because if you do, I've got a bridge for sale!
>
You can implement functions that don't do what you want. I'd be surprised if
you haven't done that.
>
Actually, I haven't given this example a moment's thought.
> > >
> > > Of course I can!. I can implement any of the 2^(2^n) functions in a 2^n
> > > bit ROM (which has n address inputs). There are _exactly_ that many
> > > possible programming patterns of the PROM, each one corresponding to a
> > > different function.
> > >
>
... and what would that function be? It must be pretty unusual. What sort
of PROM would you use (be specific) if you need a function that complex in the
time that a PAL offers? (or doesn't because it can't, as you say) How long
would it take you to enter the logic equations for a function that had a 2^42
long array of ANDs on a 2^42 long array of ORs? I'd say the example is, once
again, restricted by the limits of reality. The guys who invented PALs didn't
want to replace PROMs. They just wanted to enable folks to replace
PROM+registers+logic with a single programmable device.
>
> > SO you use a PAL with a fuse array of comparable size.
>
> I have aggreed many times that if the fuse arrays are comparable then
> both devices can generate the same functions. You were the one who
> claimed the PAL was necessarily simpler.
>
> > > What I am saying is that (say) a 16 input _PROM_ takes 65536 bits to
> > > program it. A 16 input PAL (like a 16C2) takes many fewer bits. So there
> > > have to be logic functions you can fit into the PROM that you can't fit
> > > into the PAL.
> > >
> > Not all PALs are alike. The 16C2 is a decoder. It tells you when the
desired
> > address appears at the inputs. A 26CV12 is quite a different device.
>
> Actually, a 16C2 is not a decoder necessarily. It's just the simplest of
> the original classic PALs.
>
I remember it being described as a programmable decoder. ...
> > >
> > > Of course you can make a PAL (defined as a programable AND array
followed
> > > by a fixed OR array) that can implement any cominatiorial function of
the
> > > <n> inputs just like a PROM can. This is related to the fact that you
can
> > > write any function in SOP or POS notation I think. But the resulting PAL
> > > will be as complex as the PROM.
> > >
> > Nobody said the device is simpler than the PROM. The job of concocting
the
>
> You did!
>
I am thinking in terms of what it takes to implement the device. If you can
specify the logic to fit in a given device, it's certainly simpler to use than
if it's in three devices, particularly if you subsequently need to change
something.
>
> > PAL is made easier by the rather well-developed tools that we have,
though.
>
> And you sriously believe that similar tools cannot be written (and in
> fact do not already exist [1]) to turn logic equations (or truth tables,
> or state diagrams or...) into the bitmap for a PROM.
>
Software does exist to do more or less that very thing. First of all, FPGA's
are just RAMs with feedback.
>
> [1] Considering that the FPGAs I used about 5 years ago used 32 bit RAMs
> to implement all the combinatorial logic, there must be tools that turn
> logic equations into the 'bitmap' for such RAMs. And I have no reason to
> believe that such tools can only exist for 32 bit RAMs.
>
Yep! Sounds like the 3000-series Xilinx devices. They had more than a
32-bit RAM, but that's what you saw. Believe me, their software won't support
your 32-bit RAM. It only supports their unique architecture.
>
> > Generating the fuse map for the PROM when you have 22 inputs is a big job
and
> > requires a big PROM, even though the functions are mostly simple.
consider
> > what happens if you have 16 inputs, 6 outputs, of which four are inverters
> > with tristate outputs and the other two are strobes decoded from the
> > addresses, with totem pole outputs that remain enabled. That would be a
> > problem in a PROM in any event.
>
> True. But why do you insist of overcomplicating things. We are
> considering only the combinatorial part of the circuit at the moment.
>
Why? One of the benefits of PALs is that they allow you to build two or three
functions into a single device. You don't always want a PROM. If you do, you
should use one.
> [16C2]
> > > Actaully, the 'C' means Complimentary, refering to the fact that the 2
> > > outputs are always inverses of each other.
>
I found an old-enough databook to have that device ... it's actually a 16C1,
unless there was also a 16C2, which certainly isn't in this book. It appears
that it has 512 bits in its fuse array.
>
> > >
> > I can't find a databook old enough to have this part in it, but I do
remember
<snip>
> > 16L8. It has seven product terms plus one for the output enable. That
means
>
> The reason I picked the 16C2 was to avoid having any features that are
> irrelevant to the argument. OK, you want to pick the 16L8. It makes no
> difference. You might as well ignore the output control lines _because
> they make no difference to the combinatorial functions you can
> implement). And the feedback terms are almost irrelevant -- just add 6
> more pins to the package (IIRC only 6 of the outputs have feedback) and
> seperatate the feedback signal from the output. You can wire them back
> together if you want to.
>
OK, but Why? What's relevant is the question of what's realistically
implementable. I know of no PROM with performance comparable with PALs, and I
certainly know of no large field-programmable PROMs that are physically small
enough to fit where a PAL goes. What will fit in a given package is of some
interest. Now there are PLD's that have a really large AND array, since they
can share them. There's no reason why a PROM of a given size can't exist,
BTW, but there's probably a reason why they don't.
>
> The result is an imaginary device that would be more versatile than
> the real 16L8. So if we can show this has restrictions (which we clearly
> can), then the real 16L8 must have at least as many restrictions.
>
Yes, but the reason such a device doesn't exist is because there's too little
market for it. The PAL is extremely simple to use for the purpose for which
it was intended. The PROM, likewise is pretty easy to use for what it's
intended to do. It's a lookup table. It can function as a multiplication
table as you've pointed out, and it can do lots of other things. It does
require squandering resources on functions not required in order to provide
the functions of comparably sized/priced devices.
>
> > you can take all the inputs and create any combination of those in a
single
> > product term. If the seven PT's aren't enough, you have to sacrifice the
> > output associated with one group of seven and pass it back as feedback
into
> > the product term array via feedback, which one of the macrocells hasn't
got.
> > That's the one, probably, to which you'd pass the feedback from another
> > macrocell. If you need a really complex function it can generate it, but
you
> > have to use enough resources to do that. In this case, you have 64*32 =
2048
> > fuses. 1/8 of those are allocated to output enable product terms, so you
have
> > only 1792 fuses with which to combine the 16 inputs into 8 outputs. This
>
> OK. And considering it takes 65536 bits (or fuses) to specify an
> arbitrary _single output_ function of 16 inputs you must now see the PAL
> cannout generate all possible functions...
>
> > gives you a flexibility you don't have with a ROM, i.e. enabling only one
or
> > more of the outputs independently. Further, if you leave out the
feedback,
> > which a PROM won't allow you to have unless you feed the outputs back to
> > address lines, which will reduce the number of independent inputs you
have, you
> > essentially have only 8 inputs and 8 outputs. That's 256 bytes, and
that's
>
> Actually it's 10 inputs and 8 outputs IIRC (same as a 10L8, which has no
> feedback terms). That would be 1024 bytes or 8192 bits.
>
> > 2048 bits, which is more or less what the 16L8 has. I'd submit that you
can,
> > with a similarly sized PAL create pretty much the same range of
combinatorial
> > logic that a ROM with the same number of storage bits has. Remember, if
you
>
> I think I said this about 3 messages ago. And yes, it's clearly the case...
>
> > need ANY function of the 16 inputs, then you need a 64Kbit fuse array for
each
> > bit of output. There are PLD's that are that large, but they're not
commonly
> > used because the requirement for ANY combination of the 16 inputs is
seldom
> > encountered. There are such things, however.
>
> Again, agreed. PALs are restricted in what they can do, but the
> restrictions don't matter for many real-world applications. Perhaps you
> want to make an address decoder. Typically you need perhaps 2 or 3 (at
> most) product terms of some of the address lines. That fits easily into a
> PAL.
>
They offer flexibility beyond the capability of any PROM, but they don't
replace what a PROM was intended to do. A lot of the special-purpose devices
have gone by the wayside, e.g. the XOR PALs once popular for counters and the
like, and the 'L' and 'R' types in favor of the 'V' types. That suggests that
the PAL family, truly the simplest of the programmable logic devices, has been
refined considerably. Unfortunately
>
> > >
> > > And I am not disputing you can program a PAL to implement any function
> > > consisting of one product term (which is what 'any unique combination of
> > > the inputs' would be.
> > >
>
I'm not convinced that you or anyone else can find a use for a logic function
that requires more than 64 product terms of 42 inputs. I once had a very
senior engineer-turned-manager tell me he had never encountered a function
that wouldn't fit in a 22V10. I'm inclined to believe that, though there must
have been some if the Signetics guys cooked up that 42VA12. That was one
slick device, though. It could operate in part as a 22V10 superset, in part
as a 20RA10 superset, and in part as a 32VX10 superset, by which I mean that
you could use a few outputs as though they were from a 22V10, but with the
64PT sum, others as an async PAL macrocell with a product term clock, and
others with the XOR term that the 'X' implies, which makes expressing counters
much simpler (... weak example, but I've never used a 32VX10, so I don't
remember anything about it, and haven't got the relevant databook in front of
me). Normaly, the 42VA12 came in handy for me for fixes of previously 20RA10
and 22V10 logic that either didn't fit or needed an async element it couldn't
have. The buried registers with feedback were a nice option.
>
> > You seem to be ignoring the fact that you can use as many of the available
> > product terms as you like, however. That's why 16V8's, for example, are
so
> > popular.
>
> No I am not. You seem to think there are always enough product terms. I
> dispute this.
>
> > > Go back to that 22V10 for a moment. I don't have the data sheet in front
> > > of me, so I can't remember exactly how you can use the pins as inputs
and
> > > outputs, but I think I can program it so I have 1 output, 21 inputs, and
> > > don't use any form of 'registers' or feedback terms. OK, I am not using
> > > all the PAL in that case.
> > >
> > Just to refresh your memory, the 22 is the maximum number of inputs, the V
> > indicates the "versatile" macrocell, and the 10 is for the number of
outputs.
>
> Yes, but you don't have enough pins on the package to have 22 inputs and
> 10 outputs simultaneously. IIRC some of the inputs are reallty feedback
> terms from the outputs (yes, I know you can disable the output and use
> that as a true input, but if you disable all the outputs the device is
> not a lot of use).
>
Yes, the marketing department left its footprint here. The pins are I/O's, so
you can use a pin as an input when its output is disabled, which meets the
test. What I meant, I think, was that you have as many as M inputs and N
outputs in a PAL designated MTN with the macrocell type specified by the T.
With the parts that have product term output enables, it's not quite that
simple, since you can use a device pin as both input and output.
>
> Hence my comment. IIRC this is a 24 pin package (with 2 pins used for
> Vcc and ground). If I disable all the outputs but one, I can use the
> remaining 21 pins as inputs, right? So I can make a 21 input function
> with one output in this PAL.
>
> So far, so good. I now claim that I can't make _any_ 21 input function in
> that 22V10. There are some that won't fit.
>
> > A 16R4 has 16 possible inputs to the AND array, which are available both
true
> > and compliment, and there are 8 outputs, of which 4 are registered. You
get
> > the idea.
>
> Indeed I do. I have used PALs and GALs. I have read (and understood) the
> MMI databook (amongst others).
>
> >
> > In the case you cite, you are discarding most of the resources associated
with
> > control, i.e. product terms for output enable, global reset, set, etc.
aside
>
> Correct. These extra resources have nothing to do with implementing a
> combinatorial function. Well, apart from the fact that they take up
> programming bits, so there are fewer bits left to actually determine the
> function.
>
This was done with an eye to the fact that, using a PROM, one often programmed
bits that were redundant, since one didn't need every in put for every
function, and one didn't need every output in every application. Today, the
16R4, R6, or R8, is replaced by the V8, as is the 'L8.
I've never been plagued by product term depletion, though that was
occasionally a problem. The cases where I encountered too few product terms
it simply required I rearrange the output assignments on the device pinout.
My main complaint has always been there were too few outputs, not too few
inputs or product terms. Building a sort-of 74F269 replacement (subset) in a
20-pin package wasn't possible until the 16V10 became available. It always
troubled me that they wanted two enables, yet didn't care to make a
synchronous carry flag available on the smaller synchronous devices
(74x162/3). This allows one to get around that.
Received on Mon Apr 15 2002 - 02:16:00 BST