Generating a short, precise, adjustable time delay - Page 1
Forum section: electronics / projects

author: AndyC_772
author_rank: Super Contributor
timestamp: June 10, 2015, 02:40:20 pm
content: Hi all,I have a project in mind which will require two logic signals to be generated. One must follow the other by an amount which is:- small, of the order of 10ns to 100ns- adjustable in increments of 10ps or thereabouts- predictable across temperature and from device to deviceThe signals are repetitive, and both will be generated by my circuit, probably using an FPGA and some kind of external delay component. It's that delay circuit I could use some help with.The obvious component to use would be a PLL, but unless its VCO is incredibly fast, I don't think I'll get the fine resolution in the adjustment of the delay that I'm looking for.Or, perhaps I could generate a signal which has a controlled rise time, then threshold it with a fast comparator. The problem then becomes characterising that rise time and ensuring it's predictable and consistent. And the same for the comparator, of course. Noise around the threshold crossing might be a problem.There are programmable ICs designed to help eliminate clock skew, which could just as easily be used to deliberately introduce it. Micrel have a few, but they're quite expensive and power hungry (>200mA). Nevertheless, they look quite easy to use, and tick all the boxes otherwise.Any other suggestions from the high speed design and/or RF experts out there please?

author: awallin
author_rank: Frequent Contributor
timestamp: June 10, 2015, 04:04:15 pm
content: Here's a design that might be worth studying:http://www.ohwr.org/projects/fmc-delay-1ns-8cha/wikiAFAIK they use a 125 MHz FPGA clock+counter for coarse timing and then SY89295 (3.2ns to 14.8ns in 10ps increments) for ps-level fine adjustmenthttp://www.micrel.com/_PDF/HBW/sy89295u.pdfthey consume quite a bit of power and require fan-cooling.

author: Kleinstein
author_rank: Super Contributor
timestamp: June 10, 2015, 04:30:57 pm
content: The 10 ps resolution needs some kind of two step design. A digital part (e.g. from the FPGA) to get something like 10 ns and maybe a little better steps in a digital way. Than there is something like an extra 10 Bits to do in analog.One method may be using a PLL to create a phase shifted clock. The VCO / PLL does not need to be very fast, but should be highly stable and low noise. So possibly even using a VCXO. One drawback of this solution is, that changing the delay is relatively slow.Doing a classical delay with rise time and level might get difficult and prone to jitter. To get the delay independent of components and temperature, some kind of in circuit calibration might be needed - e.g. checking when the two signals are in phase searching for that point.

author: AndyC_772
author_rank: Super Contributor
timestamp: June 10, 2015, 05:08:46 pm
content: I found the SY89295. Nice chip, but a hot little thing, and not in a good way

author: KJDS
author_rank: Super Contributor
timestamp: June 10, 2015, 05:43:33 pm
content: The classic RF phase shifter uses a 3dB coupler, these days from Anaren, and some varicap diodes on the coupled ports. The take the signal from the isolated port. I need to go and cook dinner, so PM me if you need more info than is readily available via google and I'll see what info I have lying about.

author: LaserSteve
author_rank: Super Contributor
timestamp: June 10, 2015, 09:49:38 pm
content: Just buy one from Highland Technologies or license their technology for a design.Talk to John Larkin....Steve

author: Someone
author_rank: Super Contributor
timestamp: June 10, 2015, 11:00:42 pm
content: Self calibrating delay lines in the FPGA are used for some timing critical systems, the i/o delay primitives are a hard implementation but longer delay chains have been hand crafted in logic. If they need to be perfectly monotonic with low DNL then it will likely require hand placing of much of the logic.

author: Marco
author_rank: Super Contributor
timestamp: June 10, 2015, 11:55:33 pm
content: Does the delay have to be spot on immediately or can you dial it in?If you can dial it in you could use some analogue phase shift circuit for fine delay (simple clock based delay for coarse) clean up the pulse and measure the fine delay between them with a PIC's CTMU ...which is saidto be able to get below 10 ps accuracy.

author: langwadt
author_rank: Super Contributor
timestamp: June 11, 2015, 12:30:40 am
content: Quote from: AndyC_772 on June 10, 2015, 02:40:20 pmwhich FPGA?

author: Lukas
author_rank: Frequent Contributor
timestamp: June 12, 2015, 08:10:15 am
content: Quote from: AndyC_772 on June 10, 2015, 02:40:20 pmAre both signals synchronized to a common clock? This simplifies things a lot. Hittite has some fractional-n plls that allow shifting the output phase with femtosecond resolution.

author: Marco
author_rank: Super Contributor
timestamp: June 12, 2015, 04:14:03 pm
content: The PLL based solution is only half a solution really ... you still have to create output pulses similarly shaped enough with 2 different circuits from those clocks that the 10 ps phase shift of the clocks remains meaningful, which is somewhere between hard and impossible AFAICS (if you need say 10 ns + X*10 ps delay it becomes a lot easier, because you can use a single circuit which if fast enough can be expected to be in equilibrium again).

author: AndyC_772
author_rank: Super Contributor
timestamp: June 14, 2015, 10:06:09 am
content: Some interesting suggestions there, thanks everyone.I think the best option for prototyping purposes, is going to be a programmable delay IC from Micrel or On Semi. They both have a range of ECL parts which, though rather power hungry, look as though they should do exactly what's required.I do also like the idea of replicating the effect by using delay chains in an FPGA, though the prospect of writing that particular SDC file doesn't fill me with enthusiasm. I have some prior experience of trying to specify delay constraints this way, and IIRC, all that happened was TimeQuest told me it couldn't meet them. I ended up using an additional output from the FPGA's PLL instead, but sadly they don't offer fine enough granularity in this case.Ultimately the cost and power consumption need to come down, so perhaps I'll look at using the CTMU in a PIC