10-10-2019 01:27 PM
I'm looking for the variability or variance in the ODELAY and IDELAY values for an application that uses these as a simple logic delay to implement a timed pulse from signal edge (using XOR of input with delayed version of itself).
The only specification I've found lists "average delay per tap" (see DS191 page 52) .
Given that the variability in my resultant pulse width is directly affected and determined by the variability in the per-tap delay, I'd like to know max and min values (over process, voltage, and temperature variation) so I can know what range I can expect for resultant pulse width. Will Vivado show this or is there some other place this parameter is specified? "Average" delay per tap is nice to know but with a completely unknown max/min it's not particularly useful information!
10-10-2019 02:03 PM
The delay chain is part of a delay locked loop.
A slave 64 tap delay, identical in layout to all the others, forms a ring oscillator. It gets its vcc varied to lock to a 200 MHz reference clock supplied to the device. That means a tap is 5000 ps / 64 or 78.1 ps per tap.
Tap to tap matching is perhaps a few percent at most different due to layout edge roughness, while 64 taps are (always) 5000ps, because its locked to the reference. Process, voltage, temperature is canceled out. It is 78.1 ps per tap. Guaranteed.
10-10-2019 02:10 PM
The delay line taps in the 7 series are calibrated using the IDELAYCTRL - this means that they are calibrated for process, voltage and temperature. They should actually be almost completely constant from device to device over temperature and voltage...
What is not constant is the delay of each individual tap. The tap calibration mechanism is done in the IDELAYCTRL, where there are 64 taps (not 32 like in the IDELAY). The active calibration ensures that the delay of the sum of the 64 taps is exactly equal to the period of the reference clock. This will be true over PVT. So the sum of all 64 taps is one clock period, but that doesn't actually tell us the value of each individual tap; ideally they would all be exactly the period of the REFCLK/64, but that is not the case - for example it has been reported that the first one or two are significantly longer than tREFCLK/64, and the rest are smaller (but still not equal to eachother).
I think Vivado does know this. If you implement a system with an IDELAY/ODELAY, you can get the static timing analysis tool to tell you the delay based on the programmed value. The easiest way is simply to do a "report_timing -to [get_ports <output_port>" (or -from the input port) assuming you have constrained the design (at least a create_clock and a set_input_delay/set_output_delay on the port). If you look at the timing report it will give you a delay for the IDELAY/ODELAY - this includes a "fixed" portion (for routing to and from it and the MUXing within it) and a variable portion.
Once you have the report, you can change the tap value within Vivado by changing the IDELAY_VALUE property through the Tcl interface or GUI
set_property IDELAY_VALUE 1 [get_cells <instance_name_of_IDELAY]
If you now repeat the report_timing command you should get the new delay - this will allow you to plot the expected delay for each of the 32 taps.
Now, will they be completely PVT compensated? Will there be some variation from this nominal value - I have no idea... My understanding is that they are pretty well compensated...
There is also a white paper or app note out there somewhere that documented this, but for a much older technology (Virtex-4 or Virtex-5) - however, my understanding is that the structure of the IDELAY/ODELAY hasn't changed between then and the 7 series. It is, however, completely different in UltraScale (so this whole discussion doesn't apply to UltraScale/Versal).
Hmmm... It seems that I already answered this question 4 years ago in this post... (and the white paper is referenced there).
10-10-2019 02:13 PM