AR# 36063: Design Assistant for PCI Express - Why is a NAK sent on a Previously ACKed Packet?
Design Assistant for PCI Express - Why is a NAK sent on a Previously ACKed Packet?
When looking at a link dump, you may see a NAK sent for a previously ACKed packet. Why does this happen?
Note: This Answer Record is a part of the Xilinx Solution Center for PCI Express(Xilinx Answer 34536). TheXilinx Solution Center for PCI Express is available to address all questions related to PCIe. Whether you are starting a new design with PCIe or troubleshooting a problem, use the Solution Center for PCIeto guide you to the right information.
Often you may see a link dump showing that the core ACKed a TLP, but then a bit later the core NAKs the same sequence number. For example, the following happens:
DS Port sends TLP with Sequence Number #1 Endpoint ACKs Sequence Number #1 DS Port sends TLP with Sequence Number #2 Endpoint NAKs Sequence Number #1
The reason this happens is the specification states that if an incoming TLP or TLPs is corrupted, the device informs the link partner to resend them by NAKing the last valid sequence number it received. So, in the above example, this means that when the endpoint NAKed TLP #1, it is actually informing the link partner to resend TLP #2.
Here is another example:
DS_ Port sends TLP #1 Endpoint ACKs TLP #1 DS Port sends TLP #2 DS Port sends TLP #3 DS Port sends TLP #4 DS Port sends TLP #5 DS Port sends TLP #6 Endpoint NAKs TLP #4
In this example, the endpoint is instructing the DS Port to that something has gone wrong with TLP #5. So, at this point the DS Port knows that TLPs #2, #3, and #4 were valid, but TLP #5 was in some way corrupted. The DS Port will now resend TLP #5 and TLP #6.
If received correctly, the endpoint will either ACK both TLP #5 or just TLP #6. Remember that the specification allows ACKs (and NAKs for that matter) to be collapsed.
Another example, sometimes the core will NAK a sequence number even though the DSPort has not actually sent out a packet after the sequence number that was NAKed. For instance:
This situation can be a bit confusing, because the NAK of TLP #1 is basically saying "resend anything after TLP 1." But, no packets after TLP #1 are showing up on the link analyzer. The reason the core would do this is if it encountered a physical error (8b/10b error, not in table error, invalid K-character, etc) or a framing error on the TLP or DLLP such as an incorrect START or END character. The specification allows the core to send a NAK, and it would then be up to the other end of the link to determine whether it actually was trying to send another TLP, or if it was just an error it can ignore. Also, note the core will set the Correctable Error flag in the Device Status register if it NAKs something in this manner.