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_at_p850ug1.demon.co.uk>
To: <classiccmp_at_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
>
>
Received on Wed Jul 05 2000 - 23:48:40 BST