R 2.2: Ensuring TLP Integrity: A Deep Dive into Ack and Nak DLLPs

In the high-speed world of PCI Express (PCIe), ensuring that your data arrives flawlessly is a monumental task. The PCIe specification requires a Bit Error Rate (BER) of no worse than 10−12, but at gigatransfer speeds, transient errors are inevitable, and a single flipped bit will corrupt an entire packet.

To combat this, the Data Link Layer employs an automatic, hardware-based mechanism to guarantee reliable transport across the link. The unsung heroes of this reliable delivery system are two specific types of Data Link Layer Packets (DLLPs): Acks and Naks.

Here is how these specialized packets verify whether Transaction Layer Packets (TLPs) were received successfully or if they need to be rescued and re-sent.

The Two Messengers: Ack and Nak

Every time a TLP is sent across the link, it is protected by a 32-bit Link CRC (LCRC) and assigned a unique 12-bit Sequence Number. When the neighboring device receives the TLP, it checks these values. Based on the results, it will eventually generate one of two DLLPs:

  • Ack (Acknowledge): Confirms the successful reception of one or more good TLPs.
  • Nak (Negative Acknowledge): Indicates that a transmission error occurred (such as an LCRC failure or a missing packet) and that the transmitter needs to replay the data.

Inside the Ack/Nak DLLP

Like all DLLPs, Acks and Naks are strictly local traffic and are fixed at exactly 8 bytes in size. Their 4-byte core contains three vital pieces of information used to manage TLP integrity:

  1. The DLLP Type Field: This 1-byte code tells the transmitter exactly what kind of message it is receiving. An Ack is encoded as 0000 0000b, while a Nak is encoded as 0001 0000b.
  2. The AckNak_Seq_Num: This 12-bit field contains the sequence number of the last good TLP that the receiver successfully processed.
  3. 16-bit CRC: Like all DLLPs, Acks and Naks are protected by a 16-bit CRC calculated specifically for the DLLP to ensure the acknowledgement itself wasn’t corrupted in transit.

How the Protocol Works: The Magic of Sequence Numbers

The brilliance of the Ack/Nak protocol lies in how it uses sequence numbers to manage the transmitter’s Replay Buffer, which stores a copy of every transmitted TLP just in case it needs to be sent again.

Processing an Ack (Forward Progress) When a receiver successfully receives a sequence of TLPs, it doesn’t need to send an individual Ack for every single packet. Instead, it can wait for a designated timer to expire and send a single Ack containing the sequence number of the most recently received good TLP. Because the golden rule of PCIe is that TLPs must be received in order, receiving an Ack for Sequence Number 7 means that TLP 7—and all packets before it—arrived perfectly. The transmitter then safely purges those acknowledged TLPs from its Replay Buffer.

Processing a Nak (The TLP Replay) If a TLP arrives with a bad LCRC, the receiver discards it and schedules a Nak. Interestingly, the sequence number placed inside the Nak is not the number of the bad packet. Instead, it is the sequence number of the last good TLP received.

When the transmitter receives this Nak, it takes two immediate actions:

  1. Purge: It clears out any TLPs in the Replay Buffer up to and including the sequence number in the Nak, because the receiver confirmed it got those successfully.
  2. Replay: It halts new traffic and re-transmits every remaining TLP in the Replay Buffer in order, starting with the packet immediately following the sequence number in the Nak.

What Happens if an Ack or Nak is Corrupted?

Because Ack and Nak DLLPs are just packets on a wire, they too can be corrupted by bit errors. If a transmitter calculates the 16-bit CRC on an incoming Ack or Nak and it fails, the DLLP is immediately discarded.

Because DLLPs don’t have their own acknowledgement protocol, the transmitter doesn’t ask for the Ack/Nak to be re-sent. Instead, it simply waits. If it was an Ack that was lost, the next periodic Ack will automatically update the sequence number and purge the buffer. If a Nak was lost, the transmitter’s internal Replay Timer will eventually expire, triggering an automatic replay of the buffer’s contents to ensure the data is never permanently lost.

Summary By exchanging lightweight, localized Ack and Nak DLLPs, the Data Link Layer creates an incredibly robust safety net. This protocol guarantees that even on noisy, high-speed connections, your Transaction Layer Packets will always arrive exactly as intended.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top