The IODELAY2 block in Spartan-6 FPGA devices can experience late data edge delays, early data edge delays, and single data bit corruption. The Spartan-6 FPGA Production Errata (EN148) has been updated with this issue for all Production Status Spartan-6 FPGA devices:
This Answer Record describes the behavior of the Previous Mask Revision Devices.
XA Automotive, XQ, Q grade, and XC Lower Power -1L devices will be released with the New Mask Revision only.
NOTE: The MCB is not affected by this issue.
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 the potential change in delay.
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 the potential change in delay.
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.
The overall failure rate is very low, and is relative to data rate and number of IODELAY2 elements used.
Memory Controller Block
Please note that the Memory Controller Block (MCB) interfaces are not affected by the IODELAY2 issue.
There are no software or user guide changes to address this issue.
The following are additional guidelines to help design with the work-arounds given above. When using IDELAY_TYPE as VARIABLE_FROM_ZERO or VARIABLE_FROM_HALF_MAX, it is 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.