Modern design strategy, (developed as a result of much experience like
yours) demands that all the circuitry in an FPGA be synchronous, i.e. driven
by the same (not derived or gated) clock. Having been raised on individual
components, I find this restrictive, but that's because of my age, not my
wisdom. In reality, once an FPGA is on the table you have to use techniques
that 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!
A lot depends on the flop-flop types you use in an FPGA, Tony, and there are
more types availablel today than there were ten years back. These CPLD's
have quite a variety as well, but the task is one that requires only one
clock for the "main" task, i.e. SIPO/PISO from/to the RAM. Synchronization
with the parallel port is driven from the PC, so its interface has to be
dual-rank registered, but I doubt there's need for gating the clock. That
is, as you say, an iffy practice justified only by a pipeline register to
resync the output of that circuit segment.
I've concluded that a 44-pin CPLD, though it might hold sufficient resources
to effect some FDC functions, won't have enough ins and outs to accomodate a
large SRAM. We're looking at 30 pins here just for the SRAM and half that
number +1 would be needed with a DRAM. That might still not be enough . . .
I've made a couple more remarks below, if you're interested.
Dick
----- Original Message -----
From: Tony Duell <ard_at_p850ug1.demon.co.uk>
To: <classiccmp_at_classiccmp.org>
Sent: Wednesday, July 05, 2000 5:18 PM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
<snip>
> The frequency (IMHO) is irrelevent. I've seen FPGA-based designs where
> the maximum clock frequency on the board was 32kHz. The reason is that a
> narrow glitch, a small faction of the clock, will still trigger a
> flip-flop in the FPGA if it appears on the clock input [1]. It may well
> flip the write-data flip-flop in a floppy drive. Or provide just enough
> of a write pulse to the SRAM to cause you problems later.
>
> [1] Yes, it is a bad idea to gate clock signals to FPGA flip-flops for
> _exactly_ that reason. Clock enable inputs are provided for a reason :-).
>
Flipflops with enables solve that problem to large extent.
>
> > so slow it won't make a lot of difference for speed reasons. Moreover,
> > we're talking CPLD, *NOT* FPGA. Routing delays in a sizeable FPGA will
have
> > huge effect on system performance, while those in a relatively small
CPLD
> > like this one are negligible. A CPLD is like a large PAL, AOI-gate-like
>
The reason this will likely work is because the whole process is
synchronous. It lends itself to glitch-free operation in a CPLD, because
the CPLD is basically a large PAL. Think of the XC9572 as half-a dozen
26CV12's with both pin and register feedback and product-term sharing.
>
What might make this thing workable for everybody would be developing a
schematic with fairly straighforward and well defined constructs, as one
might find in a databook, and a conversion, component by component to the
CPLD. Unfortunately , the XILINX software only supports the small CPLD's
with a library of primitives and no MSI's.
>
Received on Wed Jul 05 2000 - 19:01:45 BST