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!

AR# 32164

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


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.


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:


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:


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

Other protocols which might experience this problem:

  • Infiniband
  • PCIe Gen2


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
  • Virtex-5 FXT
  • Virtex-5 LXT
  • Virtex-5 SXT
  • Virtex-5 TXT
  • Virtex-5 RocketIO GTX Transceiver Wizard