[time-nuts] schematics of frequency counter

Magnus Danielson magnus at rubidium.dyndns.org
Sun Dec 28 17:36:46 EST 2014


On 12/28/2014 09:35 PM, Bob Camp wrote:
> Hi
>> On Dec 28, 2014, at 9:19 AM, Li Ang <lllaaa at gmail.com> wrote:
>> There 2 issues from the test:
>> 1) As we can see from the data, the number is around 1.98x not 2.00x. So
>> there is about 2ns delay between tdc_start and tdc_stop1 for this simple
>> test code. If it is from the PCB trace and something inside FPGA, this part
>> should be a constant value at certain temperature.
> So far all correct. If you are using Quartus, you can fire up the timing analyzer and take a look at what it guesses for timing / delay on the pulse. It is not a perfect number, but I’d bet it will confirm that the 2 ns does come from the FPGA.

You might want to work with timing constraints. FPGA delays typically 
shifts with temperature and voltage. Also, routing distance. If you 
force locations of critical parts to be pinned down, the variations 
allowed in the routing for critical path may be steered, or you can pin 
it down even harder. That should help making delays from synthesis to 
synthesis stable. It's a painstaking job.

As you go for better precision, the "freedom" of the FPGA will haunt you 
for stability and precision as timing stability in low ps numbers isn't 
really what they where aimed for.

>> 2) For a 90ps TDC, I think the result should be something like +-0.001
>> cycle. But I get something like +-0.003 cycle. I do not know the reason for
>> now.
> Two reasonable *guesses* would be crosstalk and noise.
> 1)  If there are any other clocks running around during this test, I’d see if they can be shut down. Things like an free running OCXO are good for this - they are easy to isolate.
> 2) Noise could be internal to the TDC. If it’s 90 ns at one sigma, then you will indeed see +’/- 3 X that (or more) depending on how long you watch it. At least by my math the one sigma on the data is 149 ps. That’s a bit over 90 ps, but not terribly far.
> Delaying the signals relative to each other (clock and output) as Magnus suggests in another post is probably a real good idea for sorting some of this out.

Cross-talk between start and stop channels, if this is an issue, is very 
easy to test using a power-splitter and two short coaxes and one 
slightly longer. Cross-talk comes either by capacitive cross-talk from 
one channel to the other, or through inductive common mode from say a 
power-pin. Both have been seen in actual hardware.

Cross-talk from other signals, such as a clock should raise the noise, 
but if they have sufficient large beat-note with the signal, it can 
average out pretty good. For TICs, cross-talk as well as non-linearities 
from the internal reference is to be expected, but if this beats quick 
enough with the signal at hand, it should average out nicely. A highly 
reference-synchronous signal will hit about the same space in the ref 
cross-talk and non-linearities, so that helps.

Anyway, using a 1 m longer coax gives you about 5 ns shift between start 
and stop. Oh, some counters use such a delay to make sure they can arm 
the stop-channel after the start-channel triggered.


More information about the time-nuts mailing list