IDELAY : Tap delay control using Ref_frequency

Question

Hello, 
I am trying to understand the IDELAY modules and I've read quite a few discussions on this forum regarding the same. 
My doubt is the following: 
I am using Kintex-7, with speed grade -2 and the data sheet states that I must get an average delay of 52ps (Tap delay) when I set the reference frequency to 300Mhz. 
I tried driving two IDelay blocks with tap values 0 and 1 with the same signal(data_in). Ideally, the output must be two signals separated by 52ps; This is exactly what I see in the post-route FUNCTIONAL simulation. 
However, when I run the post route TIMING simulation, the difference is 64ps and not 52ps. 
Also, I probed the DATAIN  pin of the two IDelay blocks and I see the signals at the input of both the IDELAY blocks, arrive at the same time. This means the routing delay is not causing the extra (65-52)ps of delay.
Could anyone please explain this? 
Thanks! 
-Kamath 

Answer 1

The calibration process does not take into account the exact values, but tries to calibrate by increasing/decreaasing these tap values such that the data is at the centre of the eye
Sorry, but that's not true...
Don't confuse the calibration process of the IDELAY (which is done internally using the IDELAYCTRL and sets the delay of each tap), and any user implemented dynamic calibration process that is trying to find the center of a data eye by adjusting the number of taps.
The delay taps in the IDELAY are calibrated to be fixed values. The average value of an individual tap is Trefclk/64, however there is some variation from tap to tap - notably, the first tap is larger than the rest.
The calibration done by the IDELAYCTRL calibrates a string of 64 elements, so that the sum of the 64 elements is one complete period of REFCLK. The calibration information obtained for these 64 element is used for the 32 elements in each IDELAY/ODELAY. If all the delay elements were identical, then that would result in the perfect tREFCLK/64 for each element, but they aren't perfectly identical - due to a number of internal factors, the delay elements are slightly different.
But, a given element  will always be the same value across process voltage and temperature (PVT). So, if tap0 measures as 64ps, it will be 64ps across all PVT; tap1 may be a different value, but it will be that value across PVT.
There is a white paper that describes this effect (and others) for the Virtex-4 (which was similar to V5, V6 and the 7 series - but not UltraScale) here.
The static timing analysis tools know about the variation from tap to tap, so the results you get out of trce or Vivado static timing analysis will be exact; these should always be your final verification for "tweaking" the number of taps you want for static phase shifting of an interface.
Avrum