AR #32164 - Virtex-5 GTX RocketIO - Data errors with CLK_COR_ADJ_LEN = 1 or 3 during asynchronous operation
Virtex-5 GTX RocketIO - Data errors with CLK_COR_ADJ_LEN = 1 or 3 during asynchronous operation
| AR# | 32164 |
| Part | HW-Rocket_IO |
| Last Modified | 2009-04-30 00:00:00.0 |
| Status | Active |
| Keywords | clock correction, RXDATA, RXCLKCORCNT, error |
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.