[time-nuts] Of rubidium life and piggy-bank anemia....

[Bruce Griffiths]

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).

bruce