Not Every Byte in a UALink DL Flit Is a Payload

Imagine a cargo train carrying three kinds of shipments: the railway company's own cargo, customer packages, and unfinished packages that are continuing from an earlier train. Now imagine you're unloading the train. Looking at a coach full of boxes, how would you know where a new shipment starts, whether it belongs to the railway company or a customer, and which shipment is simply continuing from before?

The railway solves this using a record book carried by the engine and small labels attached to each coach. The record book tracks the train itself, while the coach labels identify where new shipments begin. Without them, all you would see is a long line of boxes with no clear boundaries between shipments.

UALink's Data Link Layer (DL) faces a remarkably similar challenge. A DL flit must carry different types of information while allowing the receiver to identify what starts where, what is continuing from before, and whether everything arrived correctly. To understand how UALink achieves this, let's first examine the structure of a DL flit and the roles played by the flit header, segment headers, and flit packing rules. 

Figure 1: Flit flow across TL, DL, and PHY

3 B Flit Header + 5 B Segment Headers + 628 B payload arranged as SP0(128B), SP1(128B), SP2(128B), SP3(124B), SP4(120B) + 4 B CRC = 640 Bytes

Flit Header

In our cargo-train analogy, the flit header is like the record book carried by the engine, helping the receiver identify the arriving train, track its sequence, and confirm deliveries moving in the opposite direction. The flit header actively manages two conversations at once through either the explicit or command format.  

• The explicit header uses a 9-bit FlitSeqNo to state exactly which sequence is currently transmitting or restarting during a replay.
• The command header handles both directions simultaneously, pairing 3-bit FlitSeqLo (the compressed outgoing sequence number) with AckReqSeq, which acknowledges safely received data or targets a specific replay.
  • This dual-purpose design makes UALink highly efficient compared to protocols like UCIe retry; instead of wasting bandwidth alternating between separate sequence and Ack/Nak flits. UALink tightly packs both the outgoing sequence state and the incoming acknowledgment into one fast-moving header.

Figure 2: Types of flit headers

But if normal command flits only carry a 3-bit compressed sequence number, how does the receiver avoid losing track? The challenge is that three bits wrap around every eight flits. Without a solid reference point, a value like '001' quickly becomes ambiguous—does it mean sequence 1, 9, or 17? The answer lies in occasionally dropping an anchor.

To prevent this confusion, UALink periodically inserts an explicit header carrying the full 9-bit sequence value. This provides a fresh, unambiguous baseline, allowing the receiver to safely piece together the true sequence numbers for all the compressed command flits that follow.

Segment Header

If the flit header is the engine's record book, the segment header is like the label attached to a cargo coach. It doesn't describe every box inside the coach—it simply tells the receiver what new shipment begins there. Each segment has one small header byte: 

• DLAltSector marks a DL-to-DL message in the first sector.
• TL Flit[0] and TL Flit[1] mark new TL flit starts.
• Two message fields carry metadata only when the matching TL Flit start is present.

The important point is that the segment header marks start, not lengths. Once a 64-byte TL flit starts, the receiver simply counts 64 bytes to rebuild it. If a segment only carries continuation from an earlier TL flit, there is no new start to mark. So the same header byte can describe a DL alternative sector, one new TL start, two new TL starts, or no new start at all. That keeps decoding simple even when TL data, DL messages, and carry-over share the same segment.

Figure 4: Segment header

Figure 5: NOP flit vs empty payload flit vs payload flit

This distinction is important because all-zero segment headers do not automatically mean NOP. If the payload bit is set, or if continuation data is present, the flit remains a payload flit and must be handled through the normal sequence and replay path.

The Core Flit Packing Rules

Now imagine the workers loading each coach. To avoid confusion at the destination, they must follow a strict loading order: company cargo first, unfinished shipments next, and then new customer shipments. In UALink, these loading rules are known as the flit packing rules. 

1. DL alternative sector: DL message is present, it claims absolute priority and locks into the very first sector(4 bytes).
2. Carry-over bytes: Unfinished remainder of a TL flit spilling over from the previous segment or flit. (ranging 4 to 60 bytes).
3. TL Flit[0]: The first brand-new TL flit start in the segment.
4. TL Flit[1]: The second brand-new TL flit start in the segment.

Because this rigid rule prioritizes speed, several fascinating corner cases emerge.

• The segment header can announce at most these two new TL-flit starts
• First, a new 64-byte TL flit doesn't need a massive opening; as long as just one unallocated 4-byte sector exists, it will start packing, letting the rest naturally spill into the next segment as carry-over.  
• Furthermore, the packer refuses to stall: if data for TL Flit[0] isn't ready on the first clock tick, it mercilessly zero-fills that half-segment. If TL flit[1] shows up on the second tick, it immediately starts packing.
• Even if all segment headers read 0x00 (indicating no new starts), the segment might still be crammed with carry-over data, meaning it must strictly remain a payload flit and never be converted into a NOP.
• If a 4-byte alternative sector and 60 bytes of carry-over perfectly consume the entire first half of a segment, the very first new TL flit squeezing into the second half is still designated as TL Flit[0], simply because it is the first new arrival for that segment. Refer to S.No 14 from figure 7.

Figure 6: Flit packing flow chart

From Rules to Packing Outcomes

Once the priority chain is clear, the next natural question is what the packer can actually produce inside a segment. The answer comes from four visible outcomes: whether a DL Alternative sector starts, whether carry-over is already waiting, whether TL Flit[0] begins, and whether TL Flit[1] begins. Together, these outcomes create sixteen possible packing patterns. The Figure-7 below captures those sixteen possibilities, using Segment 4( 0-indexed), the last segment, which provides 120 bytes or 30 sectors of payload space.

Figure 7: Packing outcome visual map

After the valid paths are clear, the other side of the story is what makes a layout invalid.

• The packer must preserve TL order, place any DL alternative sector only in the first sector of the segment, complete carry-over before starting new TL flits, and keep every TL flit aligned to 4-byte sectors.
• It cannot leave hidden gaps between TL data, set message bits when the matching TL flit present bit is clear, treat continuation as a new TL start, or convert a payload flit carrying carry-over into a NOP just because its segment headers are 0x00.

In short, the receiver trusts the layout only when the flit header, segment header, segment payload, and packing rules all agree. A DL flit is discarded if: 

1. The CRC is bad
2. The opcode is invalid
3. Explicit flit FlitSeqNo is invalid or 0
4. Command flit carries AckReqSeq=0. Other out-of-range AckReqSeq values are different; they are treated as invalid feedback and ignored, but they do not by themselves make the whole flit an invalid flit or cause the payload to be discarded.

Replay begins later, only when receive ordering shows that an expected payload sequence is missing or an unexpected payload sequence has arrived.

Conclusion

With that, the packing story comes full circle. What initially appears to be a simple DL flit carrying a payload is actually a carefully orchestrated structure. Flit headers maintain ordering and reliability, Segment headers mark where new data begins, and flit packing rules ensure that TL flits, DL messages, and carry-over data share the available space efficiently without losing their meaning. Together, these mechanisms allow the receiver to reconstruct the original stream correctly, even when data crosses segment and DL flit boundaries.

Testing this intricate balance of packing rules, priority chains, and error-recovery scenarios requires a protocol-aware VIP. Cadence UALink VIP delivers exactly this with flit-accurate, credit-aware visibility across every layer—from UPLI down to PHY. Verification teams can drive ordered traffic, monitor real-time Flit packing, inject malformed conditions, and validate replay paths, turning protocol theory into a measurable proof of design robustness. To integrate this end-to-end validation capability into your environment, contact Cadence Support, visit the Simulation VIP for UALink product page, or explore the wider range of Cadence Simulation VIP solutions. For any clarification or technical assistance, please reach out to us at talk_to_vip_expert@cadence.com.