[Hold for 10.1 IP Update 0]
This Release Note and Known Issues answer record is for the Endpoint Block for PCI Express v1.7 released in ISE 10.1 Initial IP Update and contains the following information:
- General Information
- New Features
- Bug Fixes
- Known Issues
For installation instructions, general CORE Generator known issues, and design tools requirements, see the IP Release Notes Guide at: http://www.xilinx.com/support/documentation/user_guides/xtp025.pdf
Users should use the LogiCORE PCI Express Block Plus design for all typical PCI Express endpoint applications. Please see (Xilinx Answer 30120) for more information. The Endpoint Block Plus wrapper contains many needed features not available in the Endpoint Block wrapper v1.7.
Virtex-5 FPGA Integrated Block for PCI Express Known Restrictions
Please refer to the "Virtex-5 Integrated Endpoint Block for PCI Express Designs User Guide"
(UG197 - v1.2, December 13, 2007), found at: http://www.xilinx.com/support/documentation/user_guides/ug197.pdf
for a list of Known Restrictions for the Integrated Block. This information is found in Chapter 4, in the "Known Restrictions" section, on page 76.
Virtex-5 FPGA GTP Transceivers
The following are known issues regarding the GTP Transceivers interfacing to the Integrated Block for PCI Express.
- Transceiver Exit from Rx.L0s
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 due to 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.
-TX Path Entering L0s and Packet Received
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 due to the time it takes for the GTP to return to L0 from L0s. There is no work-around at this time.
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. This has been reported using the Denali BMF, and it causes the Denali model to report errors as it interprets these values as potential START of packet. The work-around is to turn off the Denali error reporting when GTP is in reset.
-Reporting 8B/10B Error
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 non-compliant response. Users can work around this by monitoring the GTP transceiver RXSTATUS output and using fabric logic to insert the correct values on the RXDATA and RXDATAK inputs to the integrated block.
-Channel Bonding on Exit from L0s
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:
These latches are expected and are necessary for proper operation of the core.
-Simulating Electrical Idle
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 an High-Z to represent electrical idle, the design will fail to link up. To work around this problem, the user 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 (XilinxAnswer 29294) for a similar problem when interfacing to the Xilinx downstream port model for simulation.
-Simulating GTP Reset
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. This has been reported using the Denali BMF, and it causes the Denali model to report errors as it interprets these values as potential START of packet. The work-around is to turn off the Denali error reporting when GTP is in reset.
Endpoint Block Wrapper
- Example Design: No split transactions. Completer cannot break a read request into two or more separate completions.
- Example Design: Can only process packets in VC0 and only on traffic class 0.
- Example Design: Endpoint does not initiate traffic without further modifications to the code.
- Some 250 MHz designs might not meet timing. Introducing area constraints and maxdelay constraints in the ucf might help the design to meet timing.