The Timekeeper Speaketh

(LOL, I'm imagining I'm a Marvel-style Cosmic Abstract called "The Timekeeper," whose job it is to measure time on all scales, from Planck scale to cosmic.)

My thinking as to next steps, at the moment is this:

1) Put the ring oscillator and carry-save counter on the DE3 board, measure ring oscillator frequency. Expecting around a GHz.

2) Try using the dual edge-triggered flip-flop to double the frequency again.

3) Reconstruct our input-capture circuit at this faster timescale, for registering 10MHz OCXO edges against the ring oscillator cycle counter. (We don't want to use the 50MHz on-board clock since it is less stable.) At 2 GHz, we could count ring oscillator cycles for >292 years without rolling over a 64-bit counter (although, since the cycle counts will always be in the general neighborhood of 200, give or take 100, there would also be no information lost by just using a 8-bit counter, and calculating the deltas by just subtracting modulo 256). If there are any metastability problems due to the short cycle time, fix them by adding some latch stages.

3) Learn how to use the DRAM in the DE3 SIMM card slot, and use it to store 1 GB of time delta data. Using 8-bit data values (adequate to cover a pretty range of deltas, from say 72 to 327), this gives us 1 billion (well, 2^30) samples. At the 10MHz OCXO frequency, that gigabyte of data will take only 100 seconds to collect. However, transferring it to the server over 56Kbaud serial would take about 2 days. Instead of doing that, I should either (a) collect less data, or (b) copy it to a file on an SD card, which I can then transfer to the server physically.

4) Do the Allan deviation computation for this dataset in C (instead of Scilab, which is too slow). In C, each pass through the GB of data (once it's loaded into RAM) should only take a few seconds, at most. Generating a thousand data points for a high-res data plot would then take around an hour, which is quite tolerable. Again, however, the range of timescales covered by the plot will only be up to 100 seconds. The minimum of the Allan deviation curve may well be below that point, though. (If not, we can set up the Ethernet on the DE3 board, and collect more data by streaming it at 10 MB/s to the server in real time while the data collection is running.)

5) Find the minimum of the Allan deviation curve for the ring oscillator vs. the OCXO. This will tell us the optimum window size T (hopefully <100 sec.) for measuring the ring oscillator frequency most precisely.

6) Implement a circular storage buffer of that size (10 MB/s)*T, and use it to store the last T amount of time worth of deltas, and also keep around a register large enough to store the running sum of all the deltas currently in the window. Add in the new values, and subtract out the old ones. This then becomes a proportional representation of the average frequency of the ring oscillator (relative to the OCXO) over the last T amount of time.

7) This technology then, I think, becomes sufficient to measure sensor event times with resolution about equal to the half-period of the ring oscillator (about 0.5 ns). We can measure threshold-crossing times by using an HSMC daughter card to do DAC conversion, to generate the threshold levels to send into the FPGA's LVDS input comparators. Then, when a pulse comes in from the PMT (or APD), we can capture that input transition, and store the threshold-crossing time, measured in ring-oscillator half-cycles since the last OCXO clock edge, as well as OCXO cycles since the start of the run. The data sent to the server can include the sum of the ring-oscillator cycle-count deltas from the most recent size-T window, which tells the server (quite accurately) the present mean frequency of the ring oscillator. Furthermore, we could even keep a running tally of the 1-cycle Allan variance over this window, which would give us an up-to-the-minute measure of the time deviation inherent in extrapolating times using the ring oscillator over the 100 ns OCXO cycle. (We could refer, instead, to OCXO half-cycles, but the problem with that is that the duty cycle of the OCXO is only specified to +/-5%, so we would have to first characterize the variability of that quantity as well.)

I think that's as far as I'm going to look ahead as to my plans for this line of development, for now. Let me get some feedback from Ray on this first.

He says he'd like to proceed with Sachin's board anyway, for now at least, but I might still spend a little time tinkering with the DE3.

On tap for Monday: Open Science Grid meeting, and installing LabView on the XP partition of the Acer (now that Juan has restored access to the Windows 7 partition and we know the state of that machine is stable). Right now, I am installing critical Windows Updates, to get the machine ready for the LabView install.