AR# 35681

|

Virtex-6 GTX Transceiver - MMCM fails to lock and TX/RXRESETDONE fails to assert

描述

This Answer Record discusses the symptoms and work-arounds regarding situations where TXOUTCLK is the incorrect rate or flat lined, and TXRESETDONE fails to assert.

解决方案

The Virtex-6 FPGA GTX Transceiver can experience errant behavior after FPGA device configuration, or after applying user TXPLL reset (if TX uses TXPLL) or RXPLL reset (if TX uses RXPLL).The results of this behavior are that the internal reset state machine does not complete and TXRESETDONE does not assert, or that TXOUTCLK might be the incorrect frequency or flat lined.WhenTXPLL_DIVSEL_OUT = 2 or 4 it is possible that the internal parallel clock that in turn can be used to drive TXOUTCLK will flat line.

To work around this issue, one of the following must be implemented:
  • A small amount of logic can be added to pulse GTXTEST[1] twice to re-initialize the PLL output dividers. This requires logic clocked by a free running clock (MGTREFCLK can be used after going through either a BUFG or BUFR) to generate 2 pulses on GTXTEST[1] 1024 cycles after TX/RXPLLLKDET asserts. If only the RXPLL is used, then only RXPLLLKDET needs to be used; otherwise, an AND of TXPLLLKDET and RXPLLLKDET can be used. Each pulse should be 256 cycles long with 256 cycles between pulses. Once complete, the user application needs to issue a TXRESET to avoid and/or clear a buffer overflow in the TX phase compensation FIFO.


  • If there are multiple possible VCO rates for the target line rate, use the VCO rate that uses TXPLL_DIVSEL_OUT = 1. For example, at 2.5 Gb/s the VCO rate could be 2.5 GHz or 1.25 GHz. The higher VCO rate requires DIVSEL_OUT = 2 to generate the correct data rate (recalling that the GTX transmits data DDR). Please use the Wizard and the supported VCO rates in the Virtex-6 FPGA Data Sheet to see if this option is valid for a particular setup.

Note: Since USRCLK and USRCLK2 need to be provided for RESETDONE to assert, similar failure modes can be seen from a software issue discussed in (Xilinx Answer 36274).


Affected Xilinx IP

  • Integrated Block for PCI Express for Production Devices - Fixed in v1.5 and later versions first available in ISE 12.1; see (Xilinx Answer 35322).
  • Integrated Block for PCI Express for ES Devices - Fixed in v1.3 rev 2 and later v1.3 revisions first available in ISE 12.1; see (Xilinx Answer 33276).
  • Serial RapidIO - Is to be fixed in v5.6 first available in ISE 13.1. See (Xilinx Answer 35570) for work-around.
  • Aurora 8b10b - Is to be fixed in v6.1 first available in ISE 12.3. The work-around is to be referenced here when ready.
  • Aurora 64b66b - Is to be fixed in v4.2. ISE release version is being determined. The work-around is to be referenced here when ready.
  • Ethernet 1000BASE-X PCS/PMA or SGMII - Fix version is being determined. The work-around is to be referenced here when ready.
  • Embedded Tri-Mode Ethernet MAC Wrapper - Fix version is being determined. The work-around is to be referenced here when ready.
  • CPRI - Is to be fixed in v4.1, tentatively scheduled for ISE 13.1; see (Xilinx Answer 37455).
  • OBSAI - Is to be fixed in v5.1, tentatively scheduled for ISE 13.1; see (Xilinx Answer 37454).
  • Virtex-6 FGPA GTX Transceiver Wizard - In 12.3, v1.7 of the Wizard will automatically generate a module that will implement the above recommendations that can be used in custom designs.
  • DisplayPort - Is to be fixed in v2.2 first available in ISE 13.1.The work-around is to be referenced here when ready.
  • IBERT GTX - Fix version to be determined. For a work-around, refer to (Xilinx Answer 34669)

Note that XAUI and RXAUI are not affected by this issue.

If you need immediate help for any core that does not have a work-around available, open a WebCase and refer to (Xilinx Answer 35681):
http://www.xilinx.com/support/clearexpress/websupport.htm

链接问答记录

相关答复记录

AR# 35681
日期 08/31/2012
状态 Active
Type 综合文章
器件 More Less
People Also Viewed