AR# 32164

Virtex-5 GTX RocketIO - Data errors with CLK_COR_ADJ_LEN = 1 or 3 during asynchronous operation

Description

Xilinx has determined that the Clock Correction feature of the Virtex-5 GTX transceiver can cause data corruption on the Receiver when a clock correction sequence is skipped or added. For detailed information about the Clock Correction feature, see the Virtex-5 FPGA RocketIO GTX Transceiver User Guide (UG198).

This issue can occur when all the following conditions are true:

  • Asynchronous operation: When the local reference clock of the Virtex-5 GTX transceiver is driven from a different oscillator than the far-end transceiver. This introduces a Parts Per Million (PPM) offset in frequency between the operation of the transceivers, requiring clock correction to skip or add clock correction sequences on a periodic basis. This also implies that the RXUSRCLK and RXUSRCLK2 ports of the Virtex-5 GTX Transceiver are derived from the local oscillator and not the RXRECCLK port.
  • Clock Correction is enabled: CLK_CORRECT_USE_0/1 attribute is set to TRUE
  • The length of the clock correction sequence is 1 or 3 Bytes: CLK_COR_ADJ_LEN_0/1 attribute is set to 1 or 3.

When the conditions described above are met, the Clock Correction feature of the Virtex-5 GTX transceiver must be disabled. This Answer Record discusses the potential work-arounds available.

Solution

If the application permits, implement one of the following options:

  • Use synchronous clocking.
  • Convert to 2-byte or 4-byte clock correction sequence.

If these options are not viable due to layout or protocol limitations, the user application must implement the fabric clock correction module located at:

https://www.xilinx.com/member/forms/download/design-license.html?cid=115636&filename=xtp037.zip

The steps required to instantiate this block and fabric utilization estimates are outlined in the Virtex-5 FPGA RocketIO GTX Transceiver Clock Correction Module (XTP037), located at:

http://www.xilinx.com/support/documentation/sw_manuals/xtp037.pdf

For individual IP affected by this issue, please refer to the following Answer Records:

Other protocols which might experience this problem:

  • Infiniband
  • PCIe Gen2

FAQ:

Q: Is Aurora affected by this issue?

A: No, Aurora uses a 2-byte CC sequence.

Q: Is the GTP affected by this issue?

A: No, the GTP uses a different clock correction circuit which does not exhibit this problem.

Q: Is the Virtex-6 GTX affected?

A: No, the GTX does not exhibit this failure.

Q: When will the affected IP be updated?

A: For individual Xilinx IP, please refer to the Answer Records above. The RocketIO Wizard will be updated to use the fabric work-around by 11.2 and will implement attribute changes to protocol templates where applicable.

AR# 32164
Date 02/28/2017
Status Active
Type General Article
Devices More Less
IP