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# 31207

Endpoint Block Plus Wrapper for PCI Express - Known issues related to GTP/GTX Transceivers

Description

There are three main components to the Endpoint Block Plus Wrapper for PCI Express:

- Virtex-5 FPGA Integrated Block for PCI Express

- Virtex-5 FPGA GTP/GTX Transceivers

- Block Plus Wrapper FPGA fabric logic

This answer record details issues related to the GTP/GTX Transceivers.

For known issues for the Virtex-5 FPGA Integrated Block for PCI Express, refer to the "Virtex-5 Integrated Endpoint Block for PCI Express Designs User Guide" (UG197 - v1.2, December 13, 2007). This information is included in Chapter 4, in the "Known Restrictions" section, on page 76. This guide is located at:

http://www.xilinx.com/support/documentation/user_guides/ug197.pdf

For Block Plus Wrapper fabric known issues, please refer to the Known Issue's Answer Record which can be found in the IP Release Notes Guide at:

http://www.xilinx.com/support/documentation/user_guides/xtp025.pdf

Solution

GTP/GTX Known Issues for PCI Express

Issue Name: Transceiver Exit from Rx.L0s

Area of Impact: Power Management

MGT Affected: GTP (LXT and SXT) and GTX (FXT)

Description: When the GTP transceiver exits from Rx.L0s, up to eight symbol times of valid data following the SKP symbol in the FTS-FTS-COM-SKP channel bonding sequence will be ignored by the block. This is a result of a delay in the assertion of the RXCHANISALIGNED signal from the GTP. If the packets are replayed by the upstream port and correctly ACKed by the integrated block, the link will stay up. However, there is a chance that if the original missed data was an ACK, that the upstream component sends the ACK, goes back to L0s, wakes up to send the ACK, and then returns to L0s. If this repeats continuously, this eventually triggers a link retrain. However, no data is lost and the link eventually recovers, causing minimal to no impact on safe operation.

Comments: This issue would arise only if Active State Power Management is in use. ASPM is OFF by default on power-on. If the BIOS or system does not turn on ASPM in the end-point device, the system will not be affected.

Issue Name: TX Path Entering L0s and Packet Received

Area of Impact: Power Management

MGT Affected: GTP (LXT and SXT) and GTX (FXT)

Description: When the TX path of core is entering L0s and a packet is transmitted by the link partner, the transition back to L0 to send an ACK is very long causing the link partner to replay the packet. It results in two ACKs sent by the core (one for the original packet and one for the replayed packet). This is a function of the time it takes for the GTP to return to L0 from L0s. This action is still compliant to the specification as two ACKs for the same packet can be legally sent. This could cause minor impacts on performance.

Comments: This is issue would arise only if Active State Power Management is in use. ASPM is OFF by default on power-on. If the BIOS or system does not turn on ASPM in the end-point device, the system will not be affected.

Issue Name: Reporting 8B/10B Error

Area of Impact: Link Traffic

MGT Affected: GTP (LXT and SXT)

Description: The GTP transceiver is required to signal an 8B/10B error by setting RXSTATUS[2:0] to 3'b100, RXDATA[7:0] to 8'hFE and RXCHARISK to 1. The transceiver correctly sets RXSTATUS, but does not indicate the correct values on RXDATA and RXCHARISK. As a result, an 8B/10B error manifests itself as an LCRC error and the integrated block transmits a NAK DLLP. This does not cause any fatal errors, but results in a noncompliant response. The link partner should resend the packet in response to the NAK. If the 8b/10b error continues to occur, the link will retrain.

Comments: In most functioning systems 8b/10b errors are rare. Although they can occur, as they manifest to the Integrated Block as an LCRC failure, it will NAK the packet which results in the link partner resending the packet. This may have slight impacts on performance, but since the occurrence is rare, there have been no reported concerns caused by this issue.

Issue Name: Simulating Electrical Idle

Area of Impact: Simulation

MGT Affected: GTP (LXT and SXT) and GTX (FXT)

Description: During simulation, it is necessary at certain times for each link partner to simulate driving electrical idle. The Xilinx GTP transceivers expect to receive either a 1, 0, or X on the RXp and RXn lines, and not a High-Z to represent electrical idle. If the link partner model transmits a High-Z to represent electrical idle, the design will fail to link up.

Comments: This issue affects simulation only and can be worked around. To work around this problem, you can either set the link partner model to driver a 1, 0, or X for electrical idle, or insert some logic in the testbench to "trap" the High-Z and replace it with an 1, 0, or X. This is similar to what is performed in (Xilinx Answer 29294) for a similar problem when interfacing to the Xilinx downstream port model for simulation.

Issue Name: Simulating GTP Reset

Area of Impact: Simulation

MGT Affected: GTP (LXT and SXT) and GTX (FXT)

Description: In simulation when the GTP is in reset, the TX outputs are held to the last logic value driven instead of driving both TXp and TXn to either X, 1, or 0. This might cause the link partner model to incorrectly interpret the behavior and see it as potential START of packet.

Comments: This has been reported using the Denali BFM and it causes the Denali model to report errors as it interprets these values as potential START of packet. To work around this issue, turn off the Denali error reporting when GTP/GTX is in reset. Although this has specifically been reported by customers using the Denali BFM, it could affect other BFMs as well.

GTP/GTX Known Issues for PCI Express Fixed in Block Plus Wrapper

The Endpoint Block Plus wrapper is to be used when targeting the Virtex-5 Integrated Block. The wrapper contains fixes for these two issues.

Issue Name: Channel Bonding on Exit from L0s

Area of Impact: Power Management

MGT Affected: GTP (LXT and SXT) and GTX (FXT)

Description: When the link transitions from L0s to L0, there is an issue with channel bonding on a multi-lane link. A work-around for this issue is already included in the Block Plus Wrapper for PCI Express. During implementation, MAP might report that latches are being used on a path similar to:

"ep/BU2/U0/pcie_ep0/pcie_blk/SIO/.pcie_gt_wrapper_i/icdrreset<7:0>".

These latches are expected and are necessary for proper operation of the core.

Comments: Issue is fixed in Block Plus Wrapper v1.3 and above.

Issue Name: Electrical Idle response to TXELECIDLE in the absence of clocks

Area of Impact: Power Management

MGT Affected: GTP (LXT and SXT) and GTX (FXT)

Description: TXELECIDLE assertion will transition the TXP and TXN outputs to Electrical Idle, only if USRCLK is active. Whenever the GTP/GTX is reset the PLLs are reset causing the clock to disappear. Hence the outputs TXN and TXP rely on AC Caps to slowly discharge to their common mode voltage. During this discharge, the link partner might not recognize TXN and TXP to be in electrical idle state and can cause potential link training issues. The work around for this is to use the GTP/GTX TXPOWERDOWN signals, which do not require clocks, to drive the TXN and TXP to common mode voltage. This work around is implemented in the Block Plus wrapper.

Comments: Issue is fixed in Block Plus Wrapper v1.3 and above.

Revision History

06/19/2008 - Initial Release

AR# 31207
Date Created 06/23/2008
Last Updated 12/15/2012
Status Active
Type General Article