Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am designing time critical application where I need time resolution in order of 100 picoseconds.

I am considering to make an ring oscillator of 20 GHz and clock from ring oscillator.

Is there IC's for it or can I implement it using CoolRunner II CPLD or other FPGA?

I looked at its datasheet, and the maximum frequency for system clock is about 256 MHz and external clock is 145 MHz.Datasheet

Should I look for faster device or is there any other way to build it?

share|improve this question
Is this for time-of-flight measurements? There are dedicated TOF IC's with resolution down below 100ps. They work like a stop-watch. Perhaps you could press one of these into service? Have a look at ti.com/lit/ds/symlink/tdc7200.pdf. – Steve G Mar 3 at 9:05
Normally for this sort of time resolution you would use a time-to-digital converter, not a counter. These basically gate a small capacitor with the trigger signals, and you then measure the accumulated voltage on it. For some ideas have a look at how equivalent time sampling (ETS) oscilloscopes work. – Jon Mar 3 at 9:09
@Paebbels: Altera's fastest Stratix 10 devices can handle I/O at 28.3 Gb/s. Xilinx's fastest Virtex-7 devices can handle 28.05 Gb/s. Your knowledge is several years out of date. – Dave Tweed Mar 3 at 12:32
@DaveTweed, not any signal. A signal with very long runs of 0's or 1's would likely result in the transceiver's CDR losing lock, making the critical clock drift. You'd have to find a way of having the event you want to time switch between two input patterns each with adequate transition density, to use these inputs to the FPGA for event timing. – The Photon Mar 3 at 16:50
For OP, realize that you don't need 20 GHz clocks to achieve 100 ps timing. For example, two 5 GHz clocks with 90 degree phase difference can achieve 100 ps timing. Or 5 1-GHz clocks each offset by 36 degrees. But at some point keeping a big group of clocks aligned accurately enough and sampling them all at close enough to the same time becomes a bigger problem than making a faster clock. – The Photon Mar 3 at 17:05

15 years ago I designed a two parameter digitizer (energy and time) to measure time of flight. For this system I used a constant current source into a cap held in reset by a JFET. On receiving the trigger (NIM fast logic, level shifting kept in the analog (as opposed to saturated switching) regime, the JFET opened, and I was able to achieve 50ps resolution by digitizing the linear ramp, and interpolating from a 62.5MSPS ADC in an FPGA . The circuit was quite simple, and matched simulations perfectly.

share|improve this answer

FPGA fabric, as other answers point out, cannot be clocked at the rate you need.

However, some FPGAs also have high speed serial interfaces in the 5Gb/s to 10Gb/s range, intended for SATA, PCIe and other high speed communication protocols.

There are probably ways to harness these for high resolution (100ps but maybe not 50ps) time measurements.

Sorry I cannot be more specific about the details.

share|improve this answer
The details are here for Xilinx (chapter 3 in particular). The fastest Virtex-7 devices support speeds up to 28 Gb/s. Altera has similar guides, and some of their Stratix V and Stratix 10 devicess also go as high as 28 Gb/s. – Dave Tweed Mar 3 at 12:23
Thanks Dave, useful link. The SERDES blocks (starting on p.143) are the feature I had in mind. – Brian Drummond Mar 3 at 12:26

A 2 GHz clock has a period of 500 ps. So if you need a resolution of 100 ps then I'd say you need at least 10 GHz.

2GHz and up is way out of any FPGA's league as far as I know. You're now in RF territory which is analog only :-)

Texas Instruments and Analog devices make clock generator ICs which can generate clocks up to several GHz which might fit your needs.

share|improve this answer
Oops, I forgot a zero in there. Correction made – Steve Mar 3 at 8:57
You need to update your knowledge. Today's FPGAs can readily handle serial I/O at 12.5 Gb/s and up, using dedicated high-speed serializer/deserializer (SERDES) logic that's built right into the I/O structures. – Dave Tweed Mar 3 at 12:02
@DaveTweed OK, can you point me to an example of such an FPGA. – FakeMoustache Mar 3 at 12:10
See my comment on Brian Drummond's answer. – Dave Tweed Mar 3 at 12:25

As someone already pointed out, there are dedicated ICs for that purpose.

If you want to do it on your own a possible approach would be to use so called Vernier delay lines.

You have two delay lines (chains of buffers) where one chain uses faster buffers than the other. The resolution of your measurement is equal to the difference of the delays of the elements in the fast and "slow" chain.

For measuring the delay you send the start pulse through the slow chain and the stop pulse through the fast chain. The stop pulse travels faster and finally will catch up with the start pulse. The number of buffers required will be a measure for the delay.

My focus is on IC design, so I am not sure if this could be done with an FPGA. Literature suggests that it is possible, though.

share|improve this answer

Some long while ago, as a thought experiment, I 'designed' a time capture FPGA.

It had a ring oscillator, conventional other than the fact it had 41 inverters. The period was thus much much lower than the delay of any gate. The FPGA process had individual gate delays down in the 10s of pS where the routing was local and the fan-out low, but could only handle system clocks in the order of 100s of MHz, due to multiplexing, routing and loading delays between blocks.

The time capture process then used 41 D-latches, each capturing the input transition, but of course clocked at different phases of the ring counter cycle. The outputs of the D-latches could be interpretted as a 'thermometer code', interpolating the input transition to sub cycle precision, with a resolution in the 10s of pS. Another 41 D-latches captured a reference clock.

There are two main difficulties with such a structure. The first is getting the synthesis tools to lay out the ring counter and lines to the D-latches in a high-speed way. This part would probably be better handled by direct manual placement. It might need a specific type of small high speed FPGA, perhaps one without multipliers and processor cores in! The second is race-free handling of the overlap between the thermometer code, and a conventional counter clocked by the lower frequency reference, but it can be done, taking care of metastability issues.

I didn't pursue it as I found a better way of solving the problem, but it was fun.

share|improve this answer
Such structures are now built into FPGAs, both in the clock management blocks (PLLs and DCMs) and in the high-speed I/O structures. – Dave Tweed Mar 3 at 12:07
While those structures will be built into the DCMs, I'm not sure you could get at them to time randomly arriving pulses. You could certainly DPLL to regularly arriving pulses. The I/O timing shims may well be configurable however. You may again need manual configuration as the PAR routing timer optimiser will certainly not understand what you are trying to do, and 'improve' it for you. – Neil_UK Mar 3 at 12:48
All I was saying is that you don't need to use individual LUTs to create a programmable delay line any more. And the delay lines in IOBs are definitely configurable -- with some effort, you can implement logic to auto-equalize the delays on a memory data bus, for example. – Dave Tweed Mar 3 at 12:54

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.