Late Data Edge Delay in IDELAY and ODELAY Modes
The IODELAY2 block can add up to 350 ps of delay on the rising or falling edge transitions when the IDELAY_VALUE or ODELAY_VALUE is 4 or higher for all IDELAY_TYPE settings or when used as output delay. This behavior can be present at all data rates and should be included in system timing margin analysis. Late Data Edge Delay Workaround
The late data edge delay issue has no work-around and must be accounted for in system timing margin analysis. Please see (Xilinx Answer 39046)
for guidance with timing constraints to account for thepotential change indelay. Early Data Edge Delay in ODELAY Mode
The IODELAY2 block used in the ODELAY mode can generate a data edge up to 350 ps early on the rising or falling edge transitions. The early data edge is earlier than the expected or normal data edge. This behavior can be present at data rates higher than 533 Mb/s and for all ODELAY_VALUE settings and should be included in system timing margin analysis. Early Data Edge Delay Workaround
The increased edge delay issue has no work-around and must be accounted for in system timing margin analysis.Please see (Xilinx Answer 39046)
for guidance with timing constraints to account for thepotential change indelay. Single Data Bit Corruption in IDELAY and ODELAY Modes
The IODELAY2 block can corrupt a single data bit for all IDELAY_TYPE settings or when used as output delay. Single Data Bit Corruption Workaround
The specific workaround is based on the setting of the IDELAY_TYPE. The guidelines below recommend restricting the usage of the IODELAY2 based on the modes in which it is used. Note that IDELAY_TYPE is the attribute for defining the mode of operation; it is unrelated to the IDELAY_MODE or SERDES_MODE attributes. Also note that all performance restrictions are in terms of the actual data rate, not the clock frequency. The values are independent of the use of SDR or DDR, or the ISERDES2 DATA_RATE attribute.
- IDELAY_TYPE=DEFAULT - The data rate must not exceed 250 Mb/s to avoid data corruption. This mode is most commonly used with low-speed registered inputs, so the impact is considered low.
- IDELAY_TYPE=FIXED or VARIABLE_FROM_ZERO or when used in ODELAY mode - The IDELAY_VALUE or ODELAY_VALUE must not exceed the values in Table 2 to avoid data corruption at the indicated data rate.
- IDELAY_TYPE=VARIABLE_FROM_HALF_MAX - The data rate must not exceed 400 Mb/s, the IODELAY2 IOCLK frequency must be equal to the data rate, and the positive increment must not exceed 5 to avoid data corruption.
- IDELAY_TYPE=DIFF_PHASE_DETECTOR - The data rate must not exceed 400 Mb/s. At 400 Mb/s and below, the data to clock skew, including package trace difference, must not exceed 0.15 Unit Intervals (UI)to avoid data corruption. In this instance, data to clock skew means the clock edge cannot happen more than 0.15UI into (after) the data pulse.The .15 UI guidance relates to the fact that a late clock forces the tap value to increment, so too much skew would cause the taps to be incremented beyond a supported range.
- These issues affect all Spartan-6 Previous Mask Revision devices. See XCN11012 for details on how to identify the Previous and New Mask Revisions.
- Impact of this issue for the Spartan-6 New Mask Revision devices can be found in (Xilinx Answer 41083).
- Impact of this issue for the -1L devices is can be found in (Xilinx Answer 41356).
- Extra edge delays, data corruption, or both could happen on a pin.
- Workarounds to avoid data corruption do not avoid extra edge delay.
- Failures are intermittent
- The max tap restriction in FIXED mode is before the midpoint for all data rates beyond 400 Mb/s. This drives the restriction to 400 Mb/s or less for the variable modes, such as VARIABLE_FROM_HALF_MAX.
The overall failure rate is very low, and is relative to data rate and number of IODELAY2 elements used. Memory Controller Block
Please note thatthe Memory Controller Block (MCB) interfaces are not affected by the IODELAY2 issue. Software/User Guide
There are no software or user guide changes to address this issue. Additional Guidance
The following are additional guidelines to help design with the workarounds given above. When using IDELAY_TYPE as VARIABLE_FROM_ZERO or VARIABLE_FROM_HALF_MAX, itis important to monitor the current tap value so it does not violate the values specified. To do this, design a counter circuit which adds "1" every time you increment your tap delay value, and subtract "1" every time you decrement your tap delay value. This value can be monitored to ensure the tap values are no higher than what is specified to avoid a single data bit corruption.
- Avoid per-bit deskew and use clock deskew instead to minimize the number of susceptible pins.
- Contact your FAE or open a WebCase with Xilinx Technical Support at: http://www.xilinx.com