CPLD computing

From: Richard Erlacher <edick_at_idcomm.com>
Date: Tue Apr 16 23:32:40 2002

Just to keep things straight ... the PLC42VA12 that I mentioned is a device
that plugs in where a 22V10 fits. It has vastly greater resources than a
22V10, but it's NOT a CPLD. It's got 42 inputs because you can "bury" the
register associated with a particular pin, isolating it from the pin's
feedback path, and from the output pin, thereby leaving the pin as input only.
The output from the register, however, has, as it always had, a separate
feedback path so the 10 output pins have 20 feedback paths associated with
their macrocells, one from the register, and one from the pin. There are also
two macrocells that have no associated output pins, so they're always buried.
This is a considerable enhancement over what a 22V10 offers, aside from the
fact that it has many more product terms than the 22V10.

A CPLD would have several banks of these, at least three or four, but probably
more than forty, with a product term matrix common to all the banks, as well
as a product term matrix for each block.

more below.

Dick

----- Original Message -----
From: "Ben Franchuk" <bfranchuk_at_jetnet.ab.ca>
To: <classiccmp_at_classiccmp.org>
Sent: Tuesday, April 16, 2002 3:52 PM
Subject: CPLD computing


> Richard Erlacher wrote:
>
> > > OK, but that's still not enough to generate _all_ possible functions.
> > >
> > I'm getting really curious what sort of function one could NEED that
requires
> > a set of more than 64 products of those 42 inputs, though you can
certainly
> > use more than that by combining sums if you do need.
>
> Carry logic found in adders can use up a lot of terms if one is not careful.
>
I'm not sure I buy that ... the carry is a single product term, isn't it?
That's why fast carry terms work faster than their respective sum terms, in
physical adders. In lookup tables, it doesn't matter.
>
FPGA makers take lots of trouble to ensure that you have fast carry logic
available.
>
> > I think that's why this argument has persisted for so long. With
programmable
> > devices, I can build what I want. With TTL SSI/MSI/LSI you can build what
you
> > want. We could switch roles, but the fact remains, each approach has
> > advantages. I just believe that the advantages of the SSI/MSI/LSI
approach
> > are diminshing, while the programmable logic approach continues to expand.
> But the programmable logic setup is still a mess. I have yet find a
> CLEAN hardware description language that is portable, simple and free.
>
> > If you were ever to want to investigate, thoroughly, at least as
thoroughly as
> > you could by building such a thing, a system that required such a
complicated
> > logic function, with as many as 56 ORs of products with 1..20 ANDed
inputs,
> > you would likely start with a simulator and not with hardware.
>
> I tend to work bottom up. I start with REAL hardware and build up.
>
That works OK if you're building stuff you know will work the way you predict
because people have built it for years. If you're trying something new, the
simulator saves lots of money for hardware you may not ever need.
>
> > You'd then
> > write a top-level functional simulation program and then test it with a
sample program.
> > (snip)
.>
 Testing is good. How ever it still needs to fit in the hardware.
>
SInce the hardware hasn't been started at this point, it's virtually infinite,
since its only virtual. Once you're convinced it's going to work as you wish,
you can progress toward an implementation.

Testing, in fact, exhaustive testing of every feature in every combination and
range of permutation you can generate is essential. Nothing should ever be
comitted to hardware until you're sure of how it works under all conditions.
>
> > Doesn't this seem less spainful than (a) finding a set of bare wire-wrap
> > boards, (b) installing sockets, (c) working out a large schematic design,
(d)
> > acquiring the long list of parts, only some of which you'll already
have,(e)
> > integrating the various modules you fabricate and test separately, (f)
finding
> > the problems and going on only when there don't appear to be any more
(else go
> > to (C)...) (g) and then, finally, going to the step at which you'd have
> > arrived without ever fiddling with any hardware with the former approach?
You
> > don't really EVER have to implement anything in programmable logic unless
you
> > want to, but you can use all the tools to support a development in
> > SSI/MSI/LSI.
>
> But debuging TTL is visible. You put a logic probe on the output and
> test data in. I favor switches and lights.It is not that I don't like
> modern software , I as design should be able to have the final say in
> exactly how things are connected even if this means shooting myself in
> the foot now and then.
>
Yes, and it's so slow, even a cheap oscilloscope can show you real features of
what's going on. Unfortunately, they don't make oscilloscopes fast enough any
more, that you can see what's really going on with an event that happens every
ten seconds or so and has a 130 ps duration. The simulator can show you where
to look, however, if you've got a simulator and appropriate models for the
TTL. You can't stick your 'scope or LA into the programmable logic, so you
have to do what you can with the simulator.
> --
> Ben Franchuk - Dawn * 12/24 bit cpu *
> www.jetnet.ab.ca/users/bfranchuk/index.html
>
>
Received on Tue Apr 16 2002 - 23:32:40 BST