ManasiYadav

Community Member

Blog Activity
Options

Untangling PCIe L0p: How Four Bytes DLLP Reshape a Live Link

• 5 minute read

PCIe links in AI accelerators, storage subsystems, and data-centric platforms see traffic that arrives in bursts. Keeping every lane active through the quiet stretches burns power for bandwidth that isn't being used. PCIe 6.0 addresses this tradeoff with L0p, a power-saving substate of L0 supported only in flit mode. At the center of the transition to L0p is the link management DLLP. It carries the requested width, response semantics, and priority information, allowing both sides of the link to agree on a width change without forcing the entire link back through the traditional recovery and configuration path. The simplicity is only on the surface. Underneath the surface sits a multiphase sequence with arbitration rules, response timing, post-response tracking windows, and a physical link reconfiguration that must be completed before the clocks run out. That is exactly what makes the link management DLLP worth a closer look.

This blog walks through how link management DLLPs work under the hood, where the verification complexity actually lives, and how Cadence PCIe VIP addresses that coverage space.  

When a Power Saving Feature Becomes a Protocol Puzzle 

For years, changing link width was a disruptive event—the link had to leave L0, traverse recovery, pass through configuration, and return to L0. With L0p, PCIe introduces a cleaner way to change link width while the link remains logically up. 

It is tempting to picture L0p as a power knob: drop the active lane count on the fly, unused lanes go idle when bandwidth demand drops, bring them back when demand rises, and the link stays in L0 throughout. Getting it right means following a width change the way the silicon does: a link management DLLP exchange at the data link layer, an L0p Ack or Nak response within the required timing window, per-lane electrical idle signaling aligned with ordered set behavior, and training on lanes that are brought back into service. The lanes that remain active continue carrying flits. There is no full teardown. Just a live link changing its width under traffic. That's the design intent, and it's where most of the verification complexity begins.    

Inside the Link Management DLLP 

Link management DLLP is four bytes wide with a compact but highly structured format:   

Link Management DLLP is four-bytes wide with a compact but highly structured format:   

The key semantic fields are:  

  • L0p.Cmd: Encodes operations such as request, Ack, and Nak. 
  • L0p.Priority: Indicates requests that are policy or urgency-sensitive.  
  • L0p link width: Carries the requested or desired link width.  
  • Response payload: Qualifies the response behavior when responding to a request.   

Same DLLP Encoding, Different Protocol Universe   

Link management DLLP shares the same encoding as conventional DLLPs (Ack/Nak, PM, UpdateFC), but the resemblance ends there. Those three are housekeeping—the continuous background work that keeps the Data Link Layer operational. Link management DLLP carries no credits, no sequence numbers, no replay information. Its purpose is more direct: carry the L0p command, the priority bit, and the target width to the link partner, and get back a deterministic L0p Ack or Nak. Conventional Ack/Nak DLLPs track TLP sequence numbers and gate the replay buffer. By contrast, an L0p Ack does not acknowledge a TLP, and an L0p Nak does not request TLP replay. They answer a width management proposal: an L0p Ack indicates that the requested Link Width change is accepted, whereas an L0p Nak indicates that it is not accepted. 

The Request-Response Contract 

The link management DLLP operates within a tightly defined envelope. It is a flit mode mechanism, and if the link is not operating in flit mode, the receiver silently discards it. The same applies when reserved encodings are present in the DLLP fields. The DLLP must carry a valid link management type, a valid L0p command, and a valid link width encoding. Reserved fields are transmitted as zero, and reserved encodings do not go on the wire. The link management DLLP either fits the envelope completely, or it is treated as though it never arrived. A port initiates a link width change by transmitting up to three identical link management DLLPs within five consecutive flits. It gives the requester enough tolerance against loss without turning the request into noise on the link. 

The responder side is just as constrained. When duplicates arrive within the observation window, the responder must return the same L0p Ack/Nak for every copy received. No divergence is permitted—identical requests within the window get an identical response. That consistency is what keeps the exchange deterministic: the requester is allowed to repeat the ask, but the responder is not allowed to create ambiguity inside the same observation window.  

Ack, Nak, or Abandon: The Clock Keeps Running  

Response timing is where the link management DLLP becomes more than a request-response packet. It becomes a bounded protocol sequence. For links using 128b/130b or 1b/1b encoding, the responder must transmit an L0p Ack or Nak within 1 µs. For 8b/10b encoding, the response window extends to 4 µs. If the requester does not receive a response within 4 µs on 128b/130b or 1b/1b links, or within 8 µs on 8b/10b links, it must either re-request the same link width change or abandon the request. Once a response is out, both ports enter the post-response tracking window. The conditions for abandonment differ depending on the request direction and the response type. After an upsize Ack, the partner considers the request abandoned only if the requester does not initiate the link width upsize within 16 µs of the Ack and does not resend the upsize request within 8 µs of that Ack. For a downsize Ack, the request is considered abandoned only if the requester neither resends the downsize request within 4 µs of the Ack nor initiates the downsize within 16 µs. For a downsize Nak, if the requester does not resend the downsize request within 4 µs of the Nak, the partner considers the request abandoned. 

Small on the Wire, Big in Verification   

A robust verification strategy has to follow it all the way down—from the link management DLLP exchange to the physical realization of the width change on the lanes. Cadence PCIe VIP helps exercise and observe L0p behavior across the protocol stack. Representative capabilities include protocol-aware generation and checking of link management DLLP transactions, Flit-aware DLP visibility for debug, timing, and protocol checks for request-response behavior, configuration, and LTSSM-aware scenario validation, and a combination of directed and constrained-random testing for negative and corner-case scenarios.  

More Information