Carry-chain based tapped delay line in Spartan3 - resolution? PVT variability?

I'm considering various options to implement a tapped delay line in an S3 device.

I believe that using the carry chain (and travelling through adjacent slices) would give a much finer resolution than going through the LUTs.

I would like to know what granularity I can expect for this type of delay line ?

What is the MUX delay, local interconnect delay, process/voltage/temp variability for each? As far as I know, Xilinx publish worst case (max) LUT delay values only.

Any info greatly appreciated.

PeterC.

Reply to
PeterC
Loading thread data ...

In my Spartan3E starter kit (3s500E-4) I'm getting an average of 450 ps per LUT when using the fastest route between LUTs in a CLB. The carry chain gets about 100 ps per tap. The way I tend to use the delay is a broadside sample of the whole chain since muxing a signal back out tends to be up to the whim of the routing.

I do use a controlled injection of the source into the 8 LUTs at the bottom of my chain giving pretty strong repeatability there. I used a method from XAPP 671 to get another half-LUT delay but I added it at the front end. Bottom line: I have 0-7.5 LUTs worth of programmable delay averaging just over 200 ps for each half step along with about 100 ps per tap up the carry chain.

It was huge fun to do. I recommend putting a frequency counter in your design to extract the precise timing. It's great to see the results.

The changes over operating conditions aren't extreme. I haven't seen the numbers on the shot of freeze spray but from what I observed early and the numbers I know now, I'd estimate less than 10% shift. What I

*have* seen that's cool is a strain-based change in delay: I push on the top of the chip with an eraser and the 5700 ps delay changes by about 10-15 ps. I considered the Spartan3E for use as a load cell!
Reply to
John_H

John_H wrote: [snip]

This is an important point. I tried to create a variable delay by injecting the input into each mux element of the carry chain and controling the muxes to select the source point. In simulation I saw that changing the delay parameter (mux control) made almost no difference in the delay. I first thought something was wrong with the logic, then found that the routing delays to the various carry mux inputs very nearly matched the carry chain delay, causing the the net effect of the delay selection to be almost zero.

Regards, Gabor

Reply to
Gabor

Now just close a servo loop on Vccint.

John

Reply to
John Larkin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.