We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome,
Firefox,
Internet Explorer 11,
Safari. Thank you!

This Answer Record describes the behavior of the Previous Mask Revision Devices.See (Xilinx Answer 41083) for details regarding the New Mask Revision Devices.See XCN11012 for details on how to identify the Previous and New Mask Revisions.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.

Solution

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.

Devices Affected

These issues affect all Spartan-6 Previous Mask Revision devices. See XCN11012 for details on how to identify the Previous and New Mask Revisions.

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.