UPGRADE YOUR BROWSER

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

Description

Keywords: clock correction, RXDATA, RXCLKCORCNT, error

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://secure.xilinx.com/webreg/clickthrough.do?cid=115636

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:
- XAUI: (Xilinx Answer 32539)
- PCIe Gen1: (Xilinx Answer 32270)
- SRIO: (Xilinx Answer 32188)

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 Created 03/11/2009
Last Updated 04/30/2009
Status Active
Type General Article