stanley_reyno...@yahoo.com said: > I need to go back and read what you are trying to measure with your > clock. Is it internal to the computer or an external event ?
I was thinking of a FPGA on a PCI bus. It has to be PCI rather than USB in order to get reasonable timings. I was going to put the Unix clock in the FPGA. It's a pair of 32 bit words. The high word is seconds since some magic date/time. The low word is nano-seconds within this second. I was planning to drive that with a stable external clock, say a GPSDO. So if things were setup properly, it should be a very good clock. The typical Unix clock is implemented by looking at the TSC. I think that's Intel's term for a register that counts each CPU cycle, Time Stamp Counter. The CPU comes from an inexpensive crystal. The frequency of that crystal varies (wildly) with temperature. The temperature varies with activity. The basic idea is that you maintain a reference time and TSC value. To get the current time, you read the TSC, subtract off the reference TSC. That gives you the number of CPU clock ticks since the reference time. Convert that to nanoseconds, add on the reference time, and normalize. You have to update the reference info periodically, in particular before that subtract will over/underflow. phk points out that you can use the TSC type clock logic by reading a simple counter from the FPGA rather than the TSC register. That gets you a stable clock without all the problems with reading 64 bits from the FPGA. You could also replace the CPU crystal with a clock derived via a PLL from your stable 10 MHz clock. Things get slightly messy because the CPU and PCI clocks usually have some spread spectrum to reduce EMI. I don't have numbers. I expect it will be small/tiny, but I'll bet you can measure it. That just gets you a basic clock. If you also feed a PPS signal into the FPGA, then you can get very accurate timings by grabbing a copy of the time register(s) on the leading edge of the PPS signal. That has metastability opportunities, but if you can solve the basic metastability issues, the same trick will work here. As phk points out, the idea of putting the whole Unix clock in the FPGA may be silly. It seemed like a fun problem so I've been thinking about how to do it. Another variation that might be interesting... The implementations I described previously all assumed the clocks had round numbers so you could do things like add 30 or 40 ns to the counter each PCI clock tick. Those round numbers are convenient. You could also add fractions of a ns. Since this stuff can be pipelined as much as necessary to meet timings, you can make the fractional part as wide as you want to get better accuracy. This might be handy if your external clock was slightly off, say a Rubidium that wasn't calibrated. -- These are my opinions, not necessarily my employer's. I hate spam. _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
