AR# 37246: Endpoint Block Plus Wrapper v1.14 for PCI Express - Possible inbound packet loss if a 8b10b error occurs while previous packet is being written into receive block RAM
Endpoint Block Plus Wrapper v1.14 for PCI Express - Possible inbound packet loss if a 8b10b error occurs while previous packet is being written into receive block RAM
Known Issue: v1.14 and all previous versions It is possible to lose an incoming packet if an 8b10b decode error occurs on a packet coming from the MGTs while the previous good packet is still in the receive block RAM. This causes the block to send a NAK with the same sequence number as the good packet, which is correct per the specification. However, under some conditions this causes the integrated block to disregard that previous packet and overwrite it with the next good packet received. The problem is that since that previous packet was already ACKed by the integrated block, the link partner does not transfer it again, resulting in a loss of packet. This problem only happens if an 8b10b error is detected in the first 8 bytes of the TLP header as it is received by the MGTs. This does not include the START symbol or the sequence number, but the actual transaction layer header portion.
If a completion is lost and the fatal error bit is not set, this might be the issue. If a completion is lost and the fatal error bit is set, this is most likely not the problem. In that case, it is more likely a receiver buffer overflow condition. The user application can monitor the fatal error bit on the cfg_dstatus output from the wrapper. Xilinx is currently investigating this issue and will update this answer record as soon as a possible workaround is found. If you are experiencing this problem, open a WebCase and refer to Answer Record 37246: http://www.xilinx.com/support/clearexpress/websupport.htm