Subnanosecond time measurment with FPGA

[DrMah]

Dear ALL,

I have to measure time intervals with precision of 750 ns with FPGA.
Is there any known methods of doing this?
Will be gratefull for any ideas.

Thanks.

 

[barath_87]

what is the frequency of the clock available to the FPGA?

 

[FvM]

Latest FPGA families are supporting high-speed interfaces with data rates > 1 GHz, e.g. 1.6GHz with A.ltera Straix IV, that allow direct aquisition of an input signals with the requested time resolution. Previous and lower cost families would require multiple phase shifted channels to achieve the speed, and most likely additional calibration circuitry.

 

[DrMah]

what is the frequency of the clock available to the FPGA?

Input clock is 40 MHz. With PLL it can be multiplied up to 350 MHz.

Added after 1 minutes:

Latest FPGA families are supporting high-speed interfaces with data rates > 1 GHz, e.g. 1.6GHz with A.ltera Straix IV, that allow direct aquisition of an input signals with the requested time resolution. Previous and lower cost families would require multiple phase shifted channels to achieve the speed, and most likely additional calibration circuitry.

Can you please describe in more details "phase shifted channels" method?

 

[FvM]

Can you please describe in more details "phase shifted channels" method?

It depends on the PLL's ability to create multiple phase shifted clocks. Most FPGA families also have dual-data-rate circuitry, that allows to sample on both edges of a clock.

One challenge is in combining the acquisition data from pahse shifted clock domains, the other in minimizing the data path/clock delay skew to achieve the intended accuracy.

You have to check the timing specification of your FPGA familiy.

Instead of shifting the sampling clock, you can also add logic cell delay to the datapath to create phase shifted channels. Buth the stability of clock cell delay can't compete with PLL phase taps, that are dividing the VCO period by an integer (e.g. 8) factor.

 

[DrMah]

Can you please describe in more details "phase shifted channels" method?

It depends on the PLL's ability to create multiple phase shifted clocks. Most FPGA families also have dual-data-rate circuitry, that allows to sample on both edges of a clock.

One challenge is in combining the acquisition data from pahse shifted clock domains, the other in minimizing the data path/clock delay skew to achieve the intended accuracy.

You have to check the timing specification of your FPGA familiy.

Instead of shifting the sampling clock, you can also add logic cell delay to the datapath to create phase shifted channels. Buth the stability of clock cell delay can't compete with PLL phase taps, that are dividing the VCO period by an integer (e.g. 8) factor.

... the other in minimizing the data path/clock delay skew to achieve the intended accuracy.

This means to take high enougth clock freq?

OK, but in first case ), how to deal with transient values of phase shifted clocks? I mean - there is probability that signal will come with rising( or falling) edge of one of the clocks (probably more, 2-4 depends on number of phase shifted clocks).
It seems that logic cell delay will do the job better, because there will be thermometer code inside delay cells chain, with maximum error 1 delay cell value.

Thanks

 

[FvM]

there is probability that signal will come with rising( or falling) edge of one of the clocks

I don't see a particularly problem. There's a (rather low) likelihood of metastable states, as with any acquisition of asynchronous signals. But you get a "thermometer code" in the combined output of phase shifted channels as well. Only the signal edge that coincidides with the clock will be unsure.

I have an 8 year old design based on a FPGA without highspeed dual data rate or deserializer capability, there we use LC delay lines to provide a stable tapped hardware delay. But newer designs are always using PLL clocks for high resolution timing measurement.

 

[DrMah]

there is probability that signal will come with rising( or falling) edge of one of the clocks

I don't see a particularly problem. There's a (rather low) likelihood of metastable states, as with any acquisition of asynchronous signals. But you get a "thermometer code" in the combined output of phase shifted channels as well. Only the signal edge that coincidides with the clock will be unsure.

I have an 8 year old design based on a FPGA without highspeed dual data rate or deserializer capability, there we use LC delay lines to provide a stable tapped hardware delay. But newer designs are always using PLL clocks for high resolution timing measurement.

Dear FvM, I think now I see what you mean. Correct me if I am wrong.
You mean, to have lets say 8 laches, and drive each one with clock shifted by +45 degree. And to rout signal-in to this latch chain?
Because what I understood first was, to have 8 FFs, and trigger them by incoming signal, and connect treir D inputs to appropriate shifted clock net. Then you obviously will not have "thermometer code" and have to decode it. And in this case metastable states seem to be problem. In your case it seems not.