This Answer Record describes the impact of each of the items listed for the integrated block for PCI Express. For a full description of the problem, refer to the errata document. These issues only affect engineering sample (ES) silicon; they do not affect production grade silicon.
Small TLPs and Packet Not Accepted DLLPs
This condition is rare. Receiving multiple NAKs indicates poor link stability. On a normally functioning link, NAK DLLPs are very seldom transmitted and the chances of receiving multiple NAKs is small. If the problem does occur, a reset (warm or cold) is required. Overall, it is unlikely users will ever experience this problem.
CFGERRCPLRDYN Signal Inversion
This issue is fixed by placing an inverter on the cfg_err_cpl_rdy_n output of the wrapper, or by editing the top level file in the <core_name>/source directory to add an inverter to cfg_err_cpl_rdy_n. The file will be the same name as the generated core's name entered in the CORE Generator software.
Note that the simulation model for the Spartan-6 FPGA Integrated block will be updated in 12.1 to match production silicon. This means that if you are still using engineering samples in 12.1, you must remove the inverter during simulation and add it back for hardware.
LCRC Errors on Received Power Management Message TLPs
LCRC errors are rare on a normally functioning link. This, along with the fact that power management messages are sent infrequently, means the likelihood of receiving an LCRC error on a power management message is very small. A correctable error is registered on the LCRC failure and a correctable error message is sent if enabled. However, the corrupted TLP is passed on to the transaction layer. Depending on the corruption that caused the LCRC failure, the packet will either be identified as malformed, or it is possible for corrupted data to be written if the power management packet contains data such as the set slot power limit message. Overall, it is unlikely users will ever experience this problem.
Packet Accepted DLLPs and Replay Timer Expiring
Experiencing a replay timeout on a normally functioning link is rare. This would indicate that the link partner is failing to acknowledge the endpoint's transmitted packets which would be unusual and indicate more serious problems occurrin (such as LCRC failures on the returned ACK DLLPs).
This problem has also been seen in another scenario involving active state power management. If the link partner's transmitter is in L0s and the Xilinx device transmits a packet, the link partner must go back to L0 and then transmit the ACK. When transitioning from L0s to L0, the link partner must first send the required number of FTS (Fast Training Sequence) ordered sets to allow the Xilinx receiver to obtain bit and symbol lock. The integrated block advertises that it requires 256 FTS ordered sets through the N_FTS field of the training sequences. In some cases, due to the amount of time it takes to send the 256 FTS ordered sets, the replay timer might expire around the same time the ACK is finally received. If you are experiencing this problem, which would be indicated by a fatal error being expressed by the Xilinx endpoint, you can increase the replay timer value so that the ACK is received before the expiration (by modifying the <core_name>.v[hd] file in the <core_name>/source directory).
Change LL_REPLAY_TIMEOUT_EN from "FALSE" to "TRUE"