[time-nuts] Of rubidium life and piggy-bank anemia....
bruce.griffiths at xtra.co.nz
Sat Dec 1 15:47:19 EST 2007
Hal Murray wrote:
>> You don't actually require a latch for each input as long as flag bits
>> (one per input channel) are used to denote which transitions occurred
>> at the latched count.
> A handful of 64 bit counters is not a big deal in modern FPGAs.
Bad idea, you should only be using a single counter with perhaps
multiple registers to save the count.
However a using a single address and a FIFO can save significant time
when using a microprocessor to read/process the stored counter samples.
>> I think there may still be a problem if you only have one counter
>> latch and a tag to indicate which input's data is in the latch, aside
>> from metastability issues. If two of the signals you want to compare
>> are very close in timing, there may not be enough time for the
>> processing logic to collect the data from the first pulse before the
>> second one comes along.
> The standard solution for that sort of problem is a small buffer.
> The worst case is that all the input signals tick in sequential cycles so the
> PC doesn't have a chance to grab any of the data. For that, you need one
> slot in the buffer for each input signal.
> Consider the alternative of a counter per input signal. It also needs a
> buffer slot per input signal so you can grab all of the counters at the same
> time. I don't see how to use RAM as a buffer, but fortunately, modern FPGAs
> have lots of FFs. (The Spartan 3 -200 has 3940.)
Such a solution adds the problem of ensuring all counters are
synchronised or at least a means of determining their offsets.
Much better to use a single counter with multiple count latches (or a
FIFO wide enough to include channel event flags).
More information about the time-nuts