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

[Magnus Danielson]

From: "Didier Juges" <didier at cox.net>
Subject: Re: [time-nuts] Of rubidium life and piggy-bank anemia....
Date: Sat, 1 Dec 2007 08:18:44 -0600
Message-ID: <045101c83425$1571e840$6501a8c0 at didierhp>

> Bruce,
> 
> 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.

When you have two slow signals beating against each other, you can expect the
runs of "very close" to be quite lengthy in time, so will also the time when
they are "very far". Whatever time-stamping system you set up, you must be able
to handle these cases equally well. The system where a single time-stamp value
and a vector of time-stamped channels needs to handle case of lengthy time of
full event rate for totally independent phases (i.e. resulting in separate
event phases) and thus there is no real gain in reduction of event rate.
If memory is an issue, then you can reduce the N-bit vector to a log(N)-bit
vector by storing the channel number never the less. Such a system must be able
to handle the burst event when there is a lengthy run of same or near timings.
Different strategies can be used to acheive this, including small FIFOs per
channel of time-stamp data or using the vector form as initial "wide" format
for a common FIFO and then cut down on it.

Considering the needed event rate needed usually the problem is not the
aggregate event rate of N channels, but the burst rate at which they may come.

Keeping separate event time latches per channel comes at a very low cost in
modern FPGAs. 8 to 16 channels is not a real concern with even modest FPGAs.
Since we are considering beat frequencies of 1 to 100 Hz or so, we are still
talking a meager 1600 events per second. For the 100 Hz beat we can expect that
the next event is at least 1 ms away and assuing an event timer at 100 MHz we
have an event-tick of 10 ns. Collecting data from 16 channels into a common
buffer memory one at a time then takes 160 ns, with alot of time twiddeling the
thumbs until the next event. Thus a single event time per channel should
suffice to keep worst-case burst among 16 channels from loosing data.

It assumes that propper signal handling has been performed so that no bursts of
events occurs on each channel. Poor through-zero gain comes to mind.

Cheers,
Magnus