How, true! It's a good thing we're looking at a CPLD rather than an FPGA.
The CPLD is not without its problems, but the architecture, particularly for
small ones, is straighforward enough that one can look at it simply as a
number of interconnected PALs.
----- Original Message -----
From: Tony Duell <ard(a)p850ug1.demon.co.uk
To: <classiccmp(a)classiccmp.org
Sent: Wednesday, July 05, 2000 6:56 PM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
>
<snip
There are 2 issues here.
Firstly, the fact that you may not have enough routing resources to feed
out the signal. This is trivially cured by using a larger FPGA for the
prototype...
The second problem which I agree with is that re-routing the device
changes the timing. However, if you're not running the device close to
the maximum speed _and_ you've got an almost fully synchronous design,
then this shouldn't matter. If it's that critical, then you probably
should be routing the device by hand anyway (this is slow and painful,
but you can get the last few ns out of a chip that way...)
If your circuit is _that_ critical as to timing, then any change in the
logic is going to cause a re-route, which is going to change timings all
over the circuit. Unless you really know what you are doing, and know how
to handle this (which will involve hand-routing, most likely), IMHO you
should re-think the design. I've seen designs where a 'section', compiled
and stuck in an FPGA worked, but when something totally unrelated was
added, the first part fell over due to timing changes. Since the speed of
the circuit was nowhere near the maximum speed the FPGA was capable of,
that was a bad design IMHO.
The main thing to keep in mind is that what's under study is a CPLD. They
are not at all like FPGA's in many respects, including, by the way, the ones
you seem to remember so well, for obvious reasons. The delay in a CPLD is
always determinstic and predictable, and the timing spec's are simple and
easy to understand. The I/O is straightforward and so is the "routing"
though there's little of that to bother with in a small part like the
XC9572. I have severe doubts about the pin count, though, and can't
understand why the same die in a different package costs so much more. (the
PLCC84 is just under $30 while the PLCC44 is at $5.50) Fortunately, there's
a good chance another device, perhaps from another vendor, and in a 68-pin
package, maybe one from ALTERA or CYPRESS might fill the bill without
breaking the bank. Their software is free as well and they support a wider
range of CPLD's. Of course they're not readily available form DigiKey . . .
<snip
> > That's why I made the remark I
made about simulation, which has LONG
been
> near and dear to my heart. I tolerate its
weaknesses where they occur
for
> > the benefit and confidence the give me. I've seldom been disappointed.
> Last time I used an FPGA simulator (a
couple of years back, and it was
> one provided by Xilinx), it was so broken as to be unusable. It showed
> glitches where there were none (like on the output of D-types far from
> any clock edge), it failed to show then when they most certainly did
> occur, it failed to get a couple of simple test circuits 'right' (it said
> signals were undefined when they certainly were not!), it couldn't handle
> external memory devices or logic in any reasonable way, etc.
Ah, yes . . . good old SILOS . . . it's one
of many and there are good ones
and not-so-good ones. The one from MENTOR was OK but the one purchased from
XILINX (SILOS) was useless. However, I bought the MAXPLUS+ software from
ALTERA the same year that I learned how crappy the XILINX software was, and
its simulator had problems that couldn't be worked around, too. I had a mux
that simulated a 70 ns prop-delay with a one and 15 with a zero. The spec
showed no difference and the FAE couldn't explain the problem either. That
was not such a good investment either.
> I can assure you that bringing out signals
_carefully_, noting how the
> timing differed from internal signals when it mattered, was a _lot_
> easier and more reliable. It actually meant that physical circuits
> started working and working reliably!
That requires more effort, (painstaking manual
layout and floorplanning)
than I've ever wanted to use up on an FPGA. Nowadays, when there are over a
million gates in one of these babies, you either have to trust your
simulator or go nuts trying to figure out how to do otherwise.
<snip
> -tony