In Lecture 10, we examined the math that transmitters use to decide if a packet can be sent. But what happens when the receiver processes those packets and frees up its buffer space?
In Lecture 11, we are going to explore how devices keep the Link running continuously by sending Flow Control Updates, how the system handles mathematical counter rollovers, and how receivers perform optional buffer overflow error checking.
Part 1: The Role of FC_Update DLLPs
As the receiving device’s core logic processes incoming transactions, it removes them from the physical Flow Control buffer. When this happens, new space opens up. The receiver tracks this newly available space by incrementing its internal Credits Allocated (CA) counter.
However, the transmitter on the other side of the Link has no idea this space has been freed up. To inform the transmitter, the receiver regularly broadcasts Flow Control Update packets (FC_Update DLLPs).
- A Clever Design Choice: When an
FC_Updatepacket is sent, it reports the actual, absolute value of the Credits Allocated register, rather than simply sending an increment value (like “+3 credits”). - Why? Unlike Transaction Layer Packets, Data Link Layer Packets (DLLPs) do not have a replay mechanism; if they are corrupted on the wire, they are simply dropped. If the receiver only sent “+3”, a dropped packet would mean those 3 credits are lost forever, permanently reducing Link bandwidth. By sending the actual counter value instead, if an
FC_Updateis dropped, the next successful update will automatically instantly resynchronize the counters.
Part 2: Handling Counter Rollovers
Because the system is continuously sending data, the Flow Control counters (Credit Limit and Credits Required) only increment upward and will eventually hit their maximum limit and roll over back to zero.
This might seem like a mathematical nightmare. For example, what happens if the Credit Limit (CL) counter has rolled over back to a small number, but the Credits Required (CR) counter has not yet rolled over and is still a very large number?
Fortunately, the Flow Control Gating Logic uses unsigned (2’s complement) arithmetic. By performing 2’s complement subtraction, the logic automatically calculates the correct available credit regardless of whether one, both, or neither of the counters have rolled over. The math always works!
Part 3: Optional Buffer Overflow Error Checking
What if something goes wrong and the transmitter sends a packet it was not supposed to, overflowing the receiver’s buffer? The PCIe specification highly recommends implementing an optional FC buffer overflow error checking mechanism.
To implement this, the receiver uses a third counter:
- Credits Received (CR) Counter: This tracks the total credits of all TLPs that have been actively received into the buffer.
The logic here is beautifully simple: If Flow Control is working correctly, the receiver’s Credits Received count will never exceed its Credits Allocated count.
The receiver continuously monitors this using a specific formula. If the Credits Received ever evaluates as mathematically greater than the Credits Allocated, it means the transmitter sent more data than the receiver had room for. This triggers an instant overflow condition, which PCIe considers a fatal Link error.