5 Jul
2000
5 Jul
'00
12:36 p.m.
There are a couple of things not so obvious to the casual looker-on. First,
the FPGA uses a RAM lookup table to generate all its logic functions, hence,
the 5-input limit on XC3000-series logic cells, (32-bit LUT). This means
that a NAND output propagates just as fast (or slowly) as an XOR, since the
prop-delay of the LUT is what it is regardless.
I have to take exception to your suggestion of making a modified version of
your FPGA to generate test points. There are lots of flops in an LCA and
limited routing resources. WHERE in the array your test point is driven to
an I/O cell is going to have major impact on the timing. Moreover, because
the routing resource allocation is critical, which flop you use will have
effects on speed and propagation of your signals. I know that's a fine
difference, but at any speed over half the rated speed of the device, it's
likely to affect your outcomes. Consequently, you can't rely on the timing
of a specially routed signal if it's not going to be part of the final
result. Another problem is that recompiling often leads to timing AND
pinout changes. Few devices allow pin locking and of those it's really only
effective if you are satisfied with 50% or lower utilization. I've seen
boards fresh from the PCB house, no parts on them yet, which had to have a
dozen or more wires placed on them in spite of the fact that all the parts
on the board were programmable logic.
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.
Dick
----- Original Message -----
From: Tony Duell <ard(a)p850ug1.demon.co.uk
To: <classiccmp(a)classiccmp.org
Sent: Wednesday, July 05, 2000 6:09 PM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
That's likely to change circuit timing and pinout.
But, of course, this 'recompile' means
that the circuit is rerouted. If
> your design in marginal anyway then the glitches will move around.
If they just move around, you may not see them.
If your circuit is
pipelined and synchronous, it will have few hazards or none at all.
> Please don't think I'm totally
against FPGAs. I'm against the misuse of
> FPGAs, including using them when half a dozen TTL chips would be better
> (for a suitable definition of better). I'm also against just shoving an
> existing circuit into them and hoping it works, because most of the time
> it wont...
<snip
> I've seen inexperienced Xilinx
designers use AND gates to gate the clock
> to most of the flip-flops in their circuit and then wonder why they get
> false clocking...
Inexperienced designers with TTL did the same
thing until they were wised
up.
> -tony
> Modern design strategy, (developed as a result of
much experience like
<snip will be likely
to yield the lowest-risk result. You can't poke around
with a 'scope, so you have to rely on a simulator. It's a pain!
Actually, you can probe with a 'scope if you have enough routing
resources and pins left over (it's worth building the prototype with 'too
big an FPGA' for this reason). You simply route internal signals to pins,
recompile, and test.