[time-nuts] schematics of frequency counter
Magnus Danielson
magnus at rubidium.dyndns.org
Sun Dec 28 22:36:46 UTC 2014
Hi,
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.
Cheers,
Magnus
More information about the Time-nuts_lists.febo.com
mailing list