Hobbyist-friendly FPGA for very precise pulse timing? - Page 1
Forum section: electronics / general

author: rs20
author_rank: Super Contributor
timestamp: September 21, 2014, 07:34:41 am
content: 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?

author: jeremy
author_rank: Super Contributor
timestamp: September 21, 2014, 07:45:15 am
content: 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?

author: rs20
author_rank: Super Contributor
timestamp: September 21, 2014, 07:52:43 am
content: Quote from: jeremy on September 21, 2014, 07:45:15 amI 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 areasonablysharp 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).

author: Precipice
author_rank: Frequent Contributor
timestamp: September 21, 2014, 07:56:02 am
content: Quote from: rs20 on September 21, 2014, 07:34:41 amThis 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 numberPart 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.

author: tggzzz
author_rank: Super Contributor
timestamp: September 21, 2014, 08:20:22 am
content: 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.

author: dannyf
author_rank: Super Contributor
timestamp: September 21, 2014, 10:18:54 am
content: Does it have to be fpga? Seems to me a lowly comparator should work.

author: rs20
author_rank: Super Contributor
timestamp: September 21, 2014, 10:55:55 am
content: Quote from: dannyf on September 21, 2014, 10:18:54 amYeah, 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!

author: dannyf
author_rank: Super Contributor
timestamp: September 21, 2014, 11:15:24 am
content: QuoteYou 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.

author: Precipice
author_rank: Frequent Contributor
timestamp: September 21, 2014, 11:21:15 am
content: Quote from: rs20 on September 21, 2014, 10:55:55 amThe 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.

author: rs20
author_rank: Super Contributor
timestamp: September 21, 2014, 11:53:40 am
content: Quote from: dannyf on September 21, 2014, 11:15:24 amI'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 ofAN72-- 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 funQuote from: Precipice on September 21, 2014, 11:21:15 amInteresting idea! I'll probably wait until I can figure out how to do that in MATLAB first though, before moving to FPGAs :-)

author: dannyf
author_rank: Super Contributor
timestamp: September 21, 2014, 11:59:49 am
content: QuoteGenerate 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.

author: tggzzz
author_rank: Super Contributor
timestamp: September 21, 2014, 12:02:42 pm
content: Have a look athttp://www.ko4bb.com/~bruce/TDC.htmlfor time->digital convertersSearch for "ECL digital delay line" and have a look at things likehttp://www.micrel.com/_PDF/HBW/sy100ep196v.pdf

author: bingo600
author_rank: Super Contributor
timestamp: September 21, 2014, 05:55:31 pm
content: I think CERN has made something you might be able to use on a Spartan6.http://tdc.web.cern.ch/TDC/hptdc/hptdc.htmhttp://www.ohwr.org/projects/tdc-core/wikihttp://lekernel.net/blog/2011/09/open-source-tdc-core-for-fpgas//Bingo

author: Marco
author_rank: Super Contributor
timestamp: September 21, 2014, 08:31:11 pm
content: Quote from: Precipice on September 21, 2014, 07:56:02 amThanks 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 tothe last article in the chainhe included some info on single shot accuracy, 50 ps apparently ... still nice, but the 3.5 ps requires repeated measurements.

author: marshallh
author_rank: Unknown
timestamp: September 22, 2014, 05:46:21 am
content: You wont be able to use fpga PLLs for this, jitter alone is 100-600ps.Some RF synth chips support fine grain phase offset.

author: tggzzz
author_rank: Super Contributor
timestamp: September 22, 2014, 11:02:49 am
content: Quote from: marshallh on September 22, 2014, 05:46:21 amTrue.If anyone has any indication the accuracy of Xilinx's predictions for jitter in Zynq devices, I'd be interested to hear it.

author: David Hess
author_rank: Super Contributor
timestamp: September 22, 2014, 04:24:39 pm
content: Quote from: Marco on September 21, 2014, 08:31:11 pmI 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.

author: hamster_nz
author_rank: Super Contributor
timestamp: September 22, 2014, 09:37:02 pm
content: Quote from: tggzzz on September 22, 2014, 11:02:49 amThe numbers are not quoted inhttp://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...)Fromhttp://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.

author: tggzzz
author_rank: Super Contributor
timestamp: September 22, 2014, 10:16:33 pm
content: Quote from: hamster_nz on September 22, 2014, 09:37:02 pmBut those are predictions, and could be wildly inaccurate.

author: rs20
author_rank: Super Contributor
timestamp: September 23, 2014, 01:51:24 am
content: Quote from: tggzzz on September 22, 2014, 10:16:33 pm600ps 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.

author: hamster_nz
author_rank: Super Contributor
timestamp: September 23, 2014, 02:18:32 am
content: Quote from: rs20 on September 23, 2014, 01:51:24 amAgreed, 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.

author: David Hess
author_rank: Super Contributor
timestamp: September 23, 2014, 02:41:00 am
content: Quote from: rs20 on September 23, 2014, 01:51:24 amIt 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.

author: rs20
author_rank: Super Contributor
timestamp: September 23, 2014, 03:55:14 am
content: Quote from: David Hess on September 23, 2014, 02:41:00 amVery true, although the very early "Rigol caught with their pants down" videosuggeststhat 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.