In the UltraScale and UltraScale+ family of FPGAs, using the IDELAY block in Component mode will add an additional delay (referred to as insertion delay in this article) that causes the actual delay created by the IDELAY block to have a longer DELAY_VALUE attribute in TIME mode than specified.
Neither timing simulation, nor static timing analysis will reflect the true delay that the block will generate in hardware.
This is part of the Component Mode Known Issues list. For updates on changes to the documentation or Vivado, please refer to (Xilinx Answer 66012)
When using an IDELAY block in Component mode with the DELAY_VALUE specified in TIME mode, the IDELAY block will typically add an insertion delay of around 50 taps (more if inter-byte clocking is leveraged on the path) larger than the requested delay.
This insertion delay will add delay to the TIME specified on the DELAY_VALUE of the IDELAY instance. This insertion delay can vary based on a specific device's inherent delay and the exact clocking path used. The true delay will not be reflected in either static timing analysis or timing simulation.
One impact of the added insertion delay is that the DELAY_VALUE specified in TIME mode will be lower than the actual delay value achieved by the IDELAY. Another impact is that the minimum delay that can be achieved when the DELAY_VALUE is set using TIME mode is higher than several hundred picoseconds.
Avoiding the use of TIME mode when specifying the DELAY_VALUE is the best approach to achieve expected delays in a system with tight margins or where small delays are necessary.
When specifying an appropriate COUNT value in order to assign a DELAY_VALUE, the conversion of a TIME delay into a COUNT delay value requires calibration on every device used. This is because a given tap variation can be quite large.
There are two approaches for determining the tap delay for a given device:
Enable the ability to use the CNTVALUEIN port and CNTVALUEOUT port to set and read the delay tap value for the design using the IDELAY block. This design should have the desired TIME (Requested Delay) value for the DELAY_VALUE attribute set.
With the device in question is configured, capture the CNTVALUEOUT which we will call total delay (Td), then change the delay using the CNTVALUEIN port to "00000000" and record the new tap delay using the CNTVALUEOUT port.
We will call this delay insertion delay (Id) as it represents only the undesired insertion delay.
You can then use the following equation to determine the approximate delay of a single tap:
Single Tap Delay = (Requested Delay) / (Td - Id)
For example, if a 500ps delay shows 150 Taps of delay (Td) , then the 0ps delay indicates 50 taps of delay (Id). We can conclude that the insertion delay is 50 taps (Td-Id).
We can also conclude that for the specific part tested, a single tap delay is 5ps:
Single Tap Delay = 500ps / (150 taps - 50 taps) = 5ps
Create an ODELAY DESIGN on the device to be used, and assign the same TIME value for the DELAY_VALUE. The CNTVALUEOUT read-back will represent the delay needed on the IDELAY for the same delay but the delay will not have any insertion delay added for the tested device.
To find the minimum delay possible when using the TIME mode DELAY_VALUE setting, the above method can be used to determine the single tap delay and the insertion delay tap count. By multiplying the insertion delay tap count by the single tap delay value, the insertion delay is given in time. The insertion delay is the smallest initial delay that can be achieved for this specific design and device.
If TIME mode is not used to specify a delay on an IDELAY block in component mode, the issue will not apply to a design.