The UCIe Protocol Stack

Chapter 4.1 gave you the three layers. Chapter 4.2 gave you what each owns and where its state lives. Both were about structure. This chapter is about transformation: what actually happens to a piece of information as it descends the stack, crosses the package, and comes back up.

The reason this deserves its own chapter is that the most common wrong model of a layered stack is that each layer "passes the packet down". It does not. Each layer produces a different representation of the same underlying information, adds metadata it alone owns, and hands the result to a neighbour that neither understands nor needs the layer above's view. Getting that right explains where metadata belongs, why the receive path has state the transmit path does not, and what verification must actually check.

1. One Piece of Information, Three Representations

Follow a single payload down the stack and watch what it is at each level:

• At the Protocol Layer it is a semantic unit — a transaction or message of whatever protocol this endpoint implements. It has meaning: it is a read, a write, a completion, a message of some type. That meaning is the whole point.
• At the D2D Adapter it is a transport unit — something to be delivered across a link intact and in order. The Adapter does not care that it is a read; it cares that it is N bits that must arrive uncorrupted, possibly with error-detection information attached and a place in a retry scheme.
• At the Physical Layer it is a physical transfer — a pattern of bits distributed across lanes, timed against a forwarded clock, driven onto conductors.

Each layer transforms the representation of the same information while preserving the contract the layer above depends on.

That last clause is the discipline. Transformation is allowed; reinterpretation is not. The Adapter may frame, protect, and retransmit a payload. It may not decide the payload means something else. The PHY may spread bits across lanes in whatever deterministic order it likes. It may not reorder transport units.

2. The Protocol Representation

At the top, traffic still has protocol meaning. UCIe carries established protocols — PCIe and CXL — and a streaming/raw option for traffic that fits neither. Each brings its own transaction model, ordering rules, and completion semantics.

What matters architecturally is only this: the Protocol Layer owns the semantic unit, and it is the only layer that does. When it hands something downward, it is handing over an object whose meaning it understands and whose meaning nothing below will inspect.

The specific mappings — how a PCIe transaction or a CXL message becomes something the Adapter can carry — belong to Module 5 and later. Attempting them here would obscure the structural point.

3. The Adapter Transformation

The Adapter receives a payload with meaning attached and produces something that can be delivered reliably. Depending on the configured mode, that transformation involves responsibilities documented for this layer: flit framing, CRC insertion for error detection and link-level retry when reliability is enabled, arbitration and multiplexing where several protocols share the link, and the link-state and parameter coordination Chapter 4.2 assigned here.

The transformation adds metadata the Adapter owns. Error-detection information is the clearest example: the Protocol Layer did not compute it, cannot interpret it, and must never see it on the receive side. It exists to resolve transport uncertainty — did this arrive intact? — which is the Adapter's uncertainty by Chapter 4.2's test.

Recall the mode nuance from 4.2, because it applies directly to representation: in raw mode the payload is populated entirely by the Protocol Layer and error protection becomes the Protocol Layer's responsibility. So in that configuration the Adapter's transformation is thinner and the Protocol representation carries more. The layers are fixed; how much transformation happens at each is mode-dependent.

4. The PHY Transformation

The PHY takes a transport unit and produces a physical transfer: bits distributed across the link's lanes, timed against a forwarded clock, driven electrically across the package.

This transformation is about arrangement, not content. The PHY does not know what the bits mean, does not know where one protocol transaction ends and another begins, and does not interpret any Adapter metadata — it moves an opaque quantity of bits from one die to another in a deterministic arrangement the receiving PHY can undo. Chapter 4.4 covers that arrangement in detail.

5. Layer-Owned Metadata, in Structures

Make the transformation concrete. Two representations of the same payload:

Illustrative representation structures — not UCIe formats or field names. Real formats are defined by the specification and taught in later modules; these exist only to show that layers own different metadata.

// What the Protocol Layer hands down: information plus its own meaning.
typedef struct packed {
  logic [255:0] payload;   // the semantic content
  logic [7:0]   kind;      // protocol-level type -- meaningful to Protocol only
} protocol_item_t;
 
// What the Adapter hands down: the same information, plus what is needed
// to deliver it reliably.
typedef struct packed {
  logic [255:0] data;            // carried through unchanged
  logic [15:0]  transport_meta;  // adapter-owned: integrity/sequencing
} adapter_item_t;

Architecture. The information survives; the metadata around it changes. payload and data hold the same bits — the Adapter is a carrier, not an interpreter. But kind is meaningful only above, and transport_meta is meaningful only at the Adapter and its remote peer.

State. The structs are types, not storage; the storage is the boundary buffers of Chapter 4.2. What matters is that a buffer at the Protocol↔Adapter boundary holds a protocol_item_t while a buffer at the Adapter↔PHY boundary holds an adapter_item_t. Different boundaries hold different representations.

Now the transformation itself:

// Adapter transmit-side transformation: carry the payload through,
// and generate the transport metadata HERE -- not upstream.
always_comb begin
  adp_item.data           = proto_item.payload;
  adp_item.transport_meta = transport_meta_gen(proto_item.payload);
end

Contract. The Protocol Layer supplies payload and nothing else the Adapter needs. Everything transport-related is generated at the layer that owns it.

Why it must be here. If the Protocol Layer generated transport_meta, it would need to know the transport scheme — which error-detection method, which sequencing rules, which retry scheme. That knowledge would then have to change every time the transport changed, and every protocol implementation would have to reimplement it. The value of the layer split evaporates.

Failure/DV. The corresponding receive-side check is that the Adapter removes its own metadata before handing upward. A receive path that leaked transport_meta into the Protocol Layer's view would force protocol logic to know about it — the same coupling in the opposite direction.

6. The Transformation That Breaks the Stack

The clearest anti-pattern, and it is tempting because it looks like an optimisation:

// BAD: the semantic layer chooses physical resources directly.
assign proto_lane_sel = current_transaction[3:0];

Someone reasoned that certain transactions should go on certain lanes — perhaps to spread load, perhaps for a latency trick. It may even work on the design where it was written.

It is wrong for the reasons Chapter 4.2 established, now in metadata form:

• The Protocol Layer now owns physical arrangement. It knows lanes exist, and how many. Change the link width, change the module organisation, or enable lane repair, and protocol logic breaks.
• The transformation chain is short-circuited. Lane selection is a PHY concern resolving PHY uncertainty. Generating it three layers up means the intermediate layer's transformation is no longer a complete description of what it hands down.
• Verification collapses. The Protocol Layer can no longer be verified against an abstract lower model, because its behaviour depends on physical detail.

The correct structure keeps each layer's metadata inside the layer that owns it: the Protocol Layer emits a semantic unit, the Adapter decides transport treatment, and the PHY alone decides which bits go on which lanes.

7. Where State Lives During One Transfer

Trace one payload and note that although the representation changes at every level, state ownership does not blur:

• Protocol. Transaction context: what was issued, what is outstanding, what completion is expected. This state persists after the payload has been handed down — the Protocol Layer is still waiting for a response.
• Adapter. The transport unit in its boundary buffer, plus, where reliability is enabled, whatever bookkeeping lets it retransmit. Its state concerns this delivery.
• PHY. Lane state, training state, and the serialisation in progress. Its state concerns this physical transfer.

The same information is simultaneously represented three ways and tracked by three independent pieces of state, each with a different lifetime. Protocol state outlives the transfer; PHY state ends when the bits are gone. That difference in lifetime is a good intuition for why the layers cannot be merged.

8. Receive Is Not Transmit Reversed

A subtle and important point that a symmetric diagram hides.

On transmit, each layer adds something and hands down. On receive, each layer checks and removes something and hands up — and checking is not the inverse of adding, because checking can fail.

That asymmetry gives the receive path state and behaviour the transmit path does not have:

• The receiving PHY must recover a transfer from the physical link — reconstructing bit alignment from lanes and clock — which has no transmit equivalent because transmission is not uncertain in the same way.
• The receiving Adapter must validate before it can hand upward. That means a receive path has a decision point — accept or reject — that the transmit path does not.
• A failed check must stop the flow, so the receive path needs somewhere to hold a transport unit while it is being validated, and a defined behaviour for what happens when validation fails (§9 of Chapter 4.5 develops this).
• Errors detected on receive may require action on the transmit side of the same endpoint — a retransmission request travels the other direction — so the two paths are coupled rather than independent.

The practical consequence for anyone building or verifying one of these: transmit and receive are different designs with different state, not one design instantiated twice.

9. What Verification Checks at Each Boundary

Representation transformation gives verification a precise set of questions, one per boundary:

• Protocol → Adapter. Does the Adapter carry the payload through unchanged? Everything semantic must survive bit-for-bit; only transport metadata may be added.
• Adapter → PHY. Does the PHY transmit exactly the transport unit it was given, preserving whatever ordering the contract requires? A PHY that reorders transport units breaks a guarantee the Adapter is relying on.
• PHY → Adapter (receive). Does the recovered transfer match what was transmitted, and are physical errors reported rather than silently passed?
• Adapter → Protocol (receive). Does the Protocol Layer receive a semantic unit equivalent to the one sent — and no transport metadata? Leaking Adapter bookkeeping upward is a real bug even when it is harmless-looking.
• End-to-end. Does the semantic unit that emerges match the one that entered, with ordering preserved where required?

Two properties are worth naming as a class. Preservation: the information a layer was given comes out the other side intact. Containment: a layer's own metadata does not escape into its neighbours' representations. Most representation bugs are violations of one or the other, and both are checkable at a boundary the architecture already defines.

10. Common Misconceptions

11. Understanding Check

12. Summary and What Comes Next

The stack is a transformation chain, not a conveyor belt. The same information exists as a semantic unit at the Protocol Layer, a transport unit at the Adapter, and a physical transfer at the PHY — each a complete description for its own layer, each carrying metadata only its own layer understands. Transformation is permitted; reinterpretation is not.

Metadata belongs to the layer that owns the uncertainty it resolves: transport integrity information at the Adapter, lane arrangement at the PHY, semantic type at the Protocol Layer. Generating it elsewhere — the Protocol Layer picking lanes, or computing transport metadata — collapses the abstraction and couples layers that were separated deliberately. In raw mode more responsibility sits with the Protocol Layer, so the amount of transformation at each layer is mode-dependent even though the layers are not.

State ownership stays separate even though representation changes, and the three layers' state has different lifetimes — protocol transaction context outlives the transfer, PHY state ends with it. And receive is not transmit reversed: adding is unconditional, checking can fail, so the receive path carries recovery, validation, a decision point, and a defined failure behaviour that transmit does not have.

For verification this yields two clean classes: preservation (information survives a boundary intact) and containment (a layer's metadata does not escape into its neighbours).

We now know how information changes form as it descends. The remaining question in this module's first half is how the physical link is actually organised so the PHY can carry it at all:

• 4.4 — Link Structure — lanes, modules, link width, and how the organisation of the link becomes an architectural parameter with real physical cost.

Browse the full path on the UCIe tutorials index.