Hobbyist-friendly FPGA for very precise pulse timing?

[rs20]

I'm wondering if anyone can suggest an FPGA that fits these requirements, although I'm flexible because I realise this combination might be unreasonable:

-- Has PLLs whose phase can be adjusted with extremely fine resolution (let's say ~100ps or less) over a considerable range (0 - 1 us). Obviously if a combination of PLL and LUTs can achieve this, that's fine too.
-- Hobbyist-friendly package (obviously this is not a black-and-white requirement)
-- Hobbyist-friendly in-fpga-package flash (as opposed to needing configuration flash on the side, but this is only a nice-to-have)

On the plus side, I'll only need a small number of LUTs and IO pins. The application: I'm thinking of hacking together a time domain reflectometer (for fun) using equivalent time sampling; what I want this FPGA to do is to provide the pulse down the transmission-line-under-test, and also clock the ADC. A supervising uC needs to instruct the FPGA to change the phase relationship between the pulse and the ADC clock to achieve equivalent time sampling (yes, I could have two separate uncorrelated clocks, but this might get messy and I'd like to try the clean, controlled approach first!)

I'm also open to other, non-FPGA solutions. Do programmable clock-delaying/phase-rotating/timed-pulse-generating ASICs exist?

[jeremy]

I'm sorry, I do not have an answer for you, but 100ps or less in a "hobby-friendly" package is going to be tough. You would probably need some pretty serious connectors for that to actually give you anywhere near that performance.

Also, about the easiest package an FPGA comes in is a QFP. Some Lattice devices have on-chip flash, but you say "on-board"? are you talking about selecting an FPGA dev board?

[rs20]

I'm sorry, I do not have an answer for you, but 100ps or less in a "hobby-friendly" package is going to be tough. You would probably need some pretty serious connectors for that to actually give you anywhere near that performance.

Also, about the easiest package an FPGA comes in is a QFP. Some Lattice devices have on-chip flash, but you say "on-board"? are you talking about selecting an FPGA dev board?

I mean Lattice-style, flash on the FPGA chip. Just a nice to have, like I said. Also, to clarify, I'm not after a 100ps rise-time/pulse-width or anything like that that implies 10 GHz frequency content/connectors; I'm only after phase-accuracy of 100ps on a much lower frequency signal. (I know you need a reasonably sharp rise time, and therefore high frequencies, for phase delay to make any difference, but I'm just trying to feel my way around the possibilities at this stage).

[Precipice]

I'm also open to other, non-FPGA solutions. Do programmable clock-delaying/phase-rotating/timed-pulse-generating ASICs exist?

This Microchip apps guy reckons the spiffy CTMU in some PICs will do the job down to 3.5ps (he uses a 24FV32KA304), but it's using a time-voltage converter rather than equivalent time sampling like you wanted. (To get timings as tight as you want, I'm suspecting you'll need to just run a chain of buffers in the FPGA, and pick off from your chosen tap. I'm sure I've seen this used somewhere, but can't remember where. Possibly in the context of precise time interval measurement, rather than TDR. If you can wrap your FPGA inside a calibration loop, you may get some accuracy as well as resolution. If not, then you'll get a number
Part of the interest in the PIC solution is the calibration.

http://edn.com/design/sensors/4432793/Use-Time-Domain-Reflectometry--TDR--for-low-cost-liquid-level-measurement-Part-I
(You may have to search EDN for the other two parts)

Worth a read, even if you don't want to go down this route, and he'll send out project files if you ask nicely.
having a play is on my to-do list, but it's a hell of a long list.

[tggzzz]

FPGAs and their tools can be a very steep learning curve. You might prefer to look at at CPLDs: they are internally simpler, but the timing is more predictable and internal routing is easier.

For delays, consider an external ECL delay lines used to phase shift clocks. They have resolutions down to <50ps, but won't pass 20Gb/s signals!

Seriously consider getting a ready-made board containing and FPGA plus decent high frequency I/O connectors. The latter is more difficult than the former, but there are many around. If you want to play with an FPGA+processor, consider a Zynq.

[dannyf]

Does it have to be fpga? Seems to me a lowly comparator should work.

[rs20]

Does it have to be fpga? Seems to me a lowly comparator should work.

Yeah, inspired by Precipice's link, I'm moving in my mind towards a charging cap + comparator type idea. Certainly a lot easier to develop than an FPGA, although it does require some thought since it requires self-calibration now that it's analog. (Obviously my overall circuit was always going to have analog bits and require calibration, but I was maybe thinking of avoiding it in the pulse generation part.) Calibrating the pulse generation part is probably easier than tricking an FPGA into doing the job, though.

Ever since doing the "hello world" of FPGA development (sending a colourful pattern to the monitor via VGA from the FPGA dev board), I've been wanting to build a FPGA that acts as a peripheral to my uC. But it seems hard to contrive a need for such a thing!

[dannyf]

I'm moving in my mind towards a charging cap + comparator type idea.

You may not need a capacitor at all.

Granted, i don't know exactly what you are trying to do but presumably some form of measuring slopes of a pulse or width of a pulse or timing between two pulses?

If they are single shot, it is a little bit tougher, but still doable, for example, with a capacitor -> which essentially acts as timing device: the charges in that capacitor is linear to how long it has been charged (by a constant current source). There are a few ways to measure the charges in that capacitor.

If they are repeated shots, you can simply measure duty cycle -> running the output through a rc filiter and you are done.

[Precipice]

Ever since doing the "hello world" of FPGA development (sending a colourful pattern to the monitor via VGA from the FPGA dev board), I've been wanting to build a FPGA that acts as a peripheral to my uC. But it seems hard to contrive a need for such a thing!

The world needs (well, I need) camera input to microcontrollers. Preferably with image dewarping to compensate for fisheye lenses, plus auto iris control, and maybe some feature tracking (or at least feature searching) to allow a simple SLAM implementation. Other people seem to want simple object tracking (follow the orange ball).

It's a nice project, as you can start with just getting an image in, then add the higher layers as you get time. The time has come for vision based robotics to stop being so horribly expensive. It's only difficult, not impossible, dammit!
Even affordable FPGAs now have interesting amounts of on-chip RAM and DDRn interfaces for buffering. It's probably time.

[rs20]

Granted, i don't know exactly what you are trying to do but presumably some form of measuring slopes of a pulse or width of a pulse or timing between two pulses?

I'm aiming for something a bit more dramatic -- I want my device to output a graph of distance vs characteristic impedance. Not because it's useful, but because it'd be sort of cool. So I need to do equivalent time sampling, which in turn requires me to repeatedly send pulses with slightly different phase relationships to the sampling points. So I believe I need what's illustrated on page 33 of AN72 -- a little block that accepts a pulse from the uC, but delays it by a variable, programmable amount. I probably want my delay range to be around an order of magnitude shorter/faster than AN72, but hey, that application note is 16 years old, so should be easy these days, right?    I know high-speed is hard, but it'll be funny to see what I come up with.

The other interesting aspect will be finding an ADC that works well in an equivalent time sampling context -- since sample-and-hold jitter and analog bandwidth issues are exacerbated by ETS. More fun!

And yes, I know I can achieve my goal with just a pulse generator, oscilloscope, and BNC tee -- not as fun

The world needs (well, I need) camera input to microcontrollers. Preferably with image dewarping to compensate for fisheye lenses, plus auto iris control, and maybe some feature tracking (or at least feature searching) to allow a simple SLAM implementation. Other people seem to want simple object tracking (follow the orange ball).

It's a nice project, as you can start with just getting an image in, then add the higher layers as you get time. The time has come for vision based robotics to stop being so horribly expensive. It's only difficult, not impossible, dammit!
Even affordable FPGAs now have interesting amounts of on-chip RAM and DDRn interfaces for buffering. It's probably time.

Interesting idea! I'll probably wait until I can figure out how to do that in MATLAB first though, before moving to FPGAs :-)

[dannyf]

pulses with slightly different phase relationships to the sampling points

Generate a pulse with a reasonable slope (so it is not too fast), and feed it to a comparator. The other end of the comparator is a variable reference voltage.

By changing the reference voltage, the comparator's output timing / phase vs. the pulse that you feed to the comparator is changed.

[tggzzz]

Have a look at http://www.ko4bb.com/~bruce/TDC.html for time->digital converters

Search for "ECL digital delay line" and have a look at things like http://www.micrel.com/_PDF/HBW/sy100ep196v.pdf

[bingo600]

I think CERN has made something you might be able to use on a Spartan6.

http://tdc.web.cern.ch/TDC/hptdc/hptdc.htm
http://www.ohwr.org/projects/tdc-core/wiki

http://lekernel.net/blog/2011/09/open-source-tdc-core-for-fpgas/



/Bingo

[Marco]

This Microchip apps guy reckons the spiffy CTMU in some PICs will do the job down to 3.5ps (he uses a 24FV32KA304)

Thanks for pointing this out, never knew such a flexible analogue timing device was in PICs ... although digital noise is going to create a lot of jitter no doubt.

PS. in the comments to the last article in the chain he included some info on single shot accuracy, 50 ps apparently ... still nice, but the 3.5 ps requires repeated measurements.

[marshallh]

You wont be able to use fpga PLLs for this, jitter alone is 100-600ps.
Some RF synth chips support fine grain phase offset.

[tggzzz]

You wont be able to use fpga PLLs for this, jitter alone is 100-600ps.

True.

If anyone has any indication the accuracy of Xilinx's predictions for jitter in Zynq devices, I'd be interested to hear it.

[David Hess]

This Microchip apps guy reckons the spiffy CTMU in some PICs will do the job down to 3.5ps (he uses a 24FV32KA304)

Thanks for pointing this out, never knew such a flexible analogue timing device was in PICs ... although digital noise is going to create a lot of jitter no doubt.

PS. in the comments to the last article in the chain he included some info on single shot accuracy, 50 ps apparently ... still nice, but the 3.5 ps requires repeated measurements.

I am not surprised.  Even 50 picosecond accuracy will be difficult if there are asynchronous clocks or I/O running during the measurement because power and ground noise will become jitter at the CTMU inputs.  Below about 200 picoseconds, differential signalling and ECL/CML logic is common in time delay counters for just this reason.  The same restriction applies to FPGA designs.

This gives discrete implementations an edge since the power and ground noise are more easily controlled and there are no asynchronous clocks or logic creating noise in the critical paths.

[hamster_nz]

You wont be able to use fpga PLLs for this, jitter alone is 100-600ps.

True.

If anyone has any indication the accuracy of Xilinx's predictions for jitter in Zynq devices, I'd be interested to hear it.

The numbers are not quoted in http://www.xilinx.com/support/documentation/data_sheets/ds187-XC7Z010-XC7Z020-Data-Sheet.pdf, but need to be obtained from the Clocking Wwizard (I can do this for you if it is really needed...)

From http://www.xilinx.com/support/documentation/user_guides/ug472_7Series_Clocking.pdf  (in Dynamic Phase Shift Interface in the MMCM) "Each increment adds to the phase shift of the MMCM clock outputs by 1/56th of the VCO period", and that MMCM_FVCOMAX for a -2 device is 1,440 MHz (695 ps) it follows that the ZYnq allows you to adjust the phase of a clock in 12.4 ps at best.

[tggzzz]

You wont be able to use fpga PLLs for this, jitter alone is 100-600ps.

True.

If anyone has any indication the accuracy of Xilinx's predictions for jitter in Zynq devices, I'd be interested to hear it.

The numbers are not quoted in http://www.xilinx.com/support/documentation/data_sheets/ds187-XC7Z010-XC7Z020-Data-Sheet.pdf, but need to be obtained from the Clocking Wwizard (I can do this for you if it is really needed...)

But those are predictions, and could be wildly inaccurate.

[rs20]

You wont be able to use fpga PLLs for this, jitter alone is 100-600ps.

True.

If anyone has any indication the accuracy of Xilinx's predictions for jitter in Zynq devices, I'd be interested to hear it.

The numbers are not quoted in http://www.xilinx.com/support/documentation/data_sheets/ds187-XC7Z010-XC7Z020-Data-Sheet.pdf, but need to be obtained from the Clocking Wwizard (I can do this for you if it is really needed...)

But those are predictions, and could be wildly inaccurate.

600ps of jitter would be very bad news for, oh I dunno, a Rigol DS1052E which uses a Xilinx FPGA to drive 10 ADCs at 100MSPS for 1GaS/s (1 every 1000ps) total rate -- I feel like there must be some FPGAs out there with slightly better performance than this.

[hamster_nz]

600ps of jitter would be very bad news for, oh I dunno, a Rigol DS1052E which uses a Xilinx FPGA to drive 10 ADCs at 100MSPS for 1GaS/s (1 every 1000ps) total rate -- I feel like there must be some FPGAs out there with slightly better performance than this.

Agreed, and given that I have squeezed DVI-D 1080p @ 60 Hz out of a Spartan 6 (i.e. three parallel 1.5Gb/s serial links) which is one bit every 666ps,  100ps jitter? maybe - 600ps jitter? design wouldn't have worked at all.

Given that the serialisers are speced at about gigabit speeds anything over 100ps sounds wrong, but I just don't have access to the sort of test gear needed to back it up with hard data.

[David Hess]

600ps of jitter would be very bad news for, oh I dunno, a Rigol DS1052E which uses a Xilinx FPGA to drive 10 ADCs at 100MSPS for 1GaS/s (1 every 1000ps) total rate -- I feel like there must be some FPGAs out there with slightly better performance than this.

It is the FPGA PLL which is the source of jitter in this case.  There is nothing to preclude using a cleaner clock source to either drive the FPGA or ADCs.

[rs20]

600ps of jitter would be very bad news for, oh I dunno, a Rigol DS1052E which uses a Xilinx FPGA to drive 10 ADCs at 100MSPS for 1GaS/s (1 every 1000ps) total rate -- I feel like there must be some FPGAs out there with slightly better performance than this.

It is the FPGA PLL which is the source of jitter in this case.  There is nothing to preclude using a cleaner clock source to either drive the FPGA or ADCs.

Very true, although the very early "Rigol caught with their pants down" video suggests that the clock sources in the DS1052E are indeed on-board PLLs. It would be interesting to see the PLL jitter specs for the particular FPGA used in the DS1052E.