Hi,
On 12/28/2014 09:35 PM, Bob Camp wrote:
Hi
On Dec 28, 2014, at 9:19 AM, Li Ang <lll...@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
_______________________________________________
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.
