From: "Didier Juges" <[EMAIL PROTECTED]> Subject: Re: [time-nuts] Of rubidium life and piggy-bank anemia.... Date: Sat, 1 Dec 2007 08:18:44 -0600 Message-ID: <[EMAIL PROTECTED]>
> 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 _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
