The UCIe Layers

Chapters 25.1 and 25.2 answered why. This is the first question where an interviewer can interrupt at any point and ask "and what happens if that fails?" — so the answer has to be a structure you can enter anywhere, not a sequence you recite from the top.

1. What They Ask

"Walk me through the UCIe stack."

Or one of its variants: "What are the layers?", "Where does retry live?", "What sits between the Adapter and the PHY?"

It is the most common intermediate UCIe question, and it is the one you most likely invited yourself (25.1 §12: say "three layers" in your opening answer and this is what comes next).

2. The One-Sentence Model

Protocol defines meaning. The Adapter turns meaning into reliable die-to-die objects. The PHY moves those objects across the package.

Say that sentence, then expand it. It is the whole answer in compressed form, and every follow-up in §18 is a request to expand one of its three clauses.

3. What They Are Really Testing

Not whether you can name three layers. Anyone can.

And the strongest single signal is the last row. A candidate who can say "the Protocol Layer doesn't know how many lanes there are" has understood layering; one who lists features has memorised a diagram.

4. What You Can Safely Assert

5. The Answer Ladder

6. Fifteen and Thirty Seconds

15 SECONDS — identification only.
 
  "Three layers. Protocol layer carries whatever you're running — PCIe or
   CXL, for example. The adapter handles reliability and framing. The
   physical layer moves it across the package."

30 SECONDS — adds the WHY of the split.
 
  "Three layers. The protocol layer holds the meaning of a transaction —
   PCIe and CXL are natively mapped, so what's above may not have to
   change. Under it the die-to-die adapter turns that into objects it can
   send reliably; it adds a small header and a CRC, and it can do
   link-level retry. Then the physical layer does the actual signalling
   across the package.
 
   The reason for the split is that each layer can change without the
   others — you can swap what's on top or what's underneath."

Two properties.

The 15-second version names one responsibility per layer and stops. It does not say "adapts" — see §19.

And the 30-second version earns its extra time with the last sentence. "Each layer can change without the others" is the point of layering; a candidate who never says why the split exists has described a diagram.

7. The Ninety-Second Answer

SCRIPT — ~205 words, ~90 seconds. Say it aloud and time it.
 
  "There are three layers, and the cleanest way to think about it is that
   each one owns a different kind of thing.
 
   The protocol layer owns meaning. This is where a transaction actually
   means something — a read, a write, a completion. PCIe and CXL are
   natively mapped, so a design that already speaks one of those can carry
   it across the boundary without changing its semantics.
 
   The die-to-die adapter sits underneath and turns that meaning into
   objects it can move reliably. It adds a small header and a CRC, and it
   can provide link-level retry — I'd say 'can' deliberately, because it's
   described as optional rather than mandatory. If more than one protocol
   is in play, the adapter is also where arbitration between them lives.
 
   The physical layer is the actual die-to-die signalling, plus link
   training and the link state machine.
 
   The two interfaces between them are FDI, between protocol and adapter,
   and RDI, between adapter and physical.
 
   The reason this matters is that the layers hide things from each other.
   The protocol layer doesn't know how many lanes there are, and the
   physical layer doesn't know what a read is."
 
  [STOP.]

Five things this script does deliberately.

It says "can provide" and flags why — "described as optional rather than mandatory." That one clause is the strongest accuracy signal in the answer (§20), and it costs three seconds.

It names arbitration, which most candidates omit, and it is directly supported (§4).

It puts FDI and RDI in one sentence and stops there. §13 is why saying more is a risk.

It ends on what each layer does not know — the abstraction point from §3, which is the sentence that separates the answer.

And it never says "adapts." §19's first bad answer.

8. The Whiteboard

Three properties of drawing it this way.

Three boxes, two labels, one line at the bottom. That is thirty seconds of drawing and everything you need to answer §18's ten follow-ups from.

Write FDI and RDI between the boxes, not inside them — because they are boundaries, and drawing them as boundaries pre-empts §13's trap.

And the package line at the bottom is the highest-value stroke. It shows you know this is an in-package link, which is the confusion behind 25.1 §10's "UCIe replaces PCIe."

9. The Responsibility Table

The centrepiece. If you can reconstruct this, you can answer any layer question.

Four readings.

Row 5's parenthesis is the accuracy signal. "Optional" is the word most candidates drop, and dropping it turns a correct statement into an overclaim (25.2 §12's theme).

Row 10 is deliberately not answered. Flow control's placement depends on which protocol is being carried and what the Adapter provides — and "it depends on what you're carrying" is a better answer than a confident wrong one (§18 Q4).

Row 11 is the senior sentence (25.1 §8): UCIe transports a coherence protocol; the protocol owns the state.

And the empty cells matter as much as the ticks. "The PHY doesn't know what a read is" is the abstraction claim from §3, stated as a table.

10. The Trap — Retry Is Not Reissue

The single best follow-up an interviewer has for this question, and the one that separates levels.

A transport retry must not become a second semantic operation. One application request may become one transport object and several physical attempts — and the layer that counts deliveries must count the first, not the third.

Three properties.

Confusing them produces duplicate delivery — the application sees an operation executed twice because a lower layer retried, which is a correctness bug, not a performance one.

It also produces the opposite misdiagnosis: an engineer sees two physical arrivals and reports a protocol violation, when a working retry mechanism produced exactly what it should (21.6 §19).

And it is the natural bridge to §11. "How would you represent that?" is the follow-up, and having three types ready is a strong answer.

11. RTL — Three Identities

// ILLUSTRATIVE ONLY. Three types, because there are three lifetimes (§10).
// The whole point is that they are SEPARATE types, not one struct with more
// fields (§12).
 
// 1. SEMANTIC — what the application asked for. Lives longest.
typedef struct packed {
  logic [SEM_W-1:0]  sem_id;
  logic [GEN_W-1:0]  generation;    // which USE of this id
  logic [3:0]        op_class;      // read / write / completion / message
  logic [ORD_W-1:0]  order_domain;  // ordering scope, protocol-defined
} semantic_req_t;
 
// 2. TRANSPORT OBJECT — what the adapter is moving. Refers to the semantic
//    operation; it does NOT contain it.
typedef struct packed {
  logic [OBJ_W-1:0]  obj_id;
  logic [SEM_W-1:0]  sem_id;        // the operation this serves
  logic [GEN_W-1:0]  generation;
  logic [LEN_W-1:0]  length;
  logic [EPOCH_W-1:0] cfg_epoch;    // which configuration it was framed under
} transport_obj_t;
 
// 3. PHYSICAL ATTEMPT — one transmission. Many per object.
typedef struct packed {
  logic [OBJ_W-1:0]  obj_id;
  logic [ATT_W-1:0]  attempt;       // 1, 2, 3 ...
  logic [EPOCH_W-1:0] link_epoch;   // which link agreement
} phys_attempt_t;

Architecture. Three types because there are three lifetimes. A semantic operation outlives its transport object; a transport object outlives any single attempt.

State. The semantic layer holds an outstanding table keyed by sem_id + generation; the Adapter holds one keyed by obj_id; the link holds only the current attempt.

Event. attempt increments on retransmission. No branch anywhere increments sem_id — and that absence is the correctness argument, not an omission.

Contract. The Adapter's object refers to sem_id rather than owning it. Delivery is counted on the semantic identity, never on the attempt — which is what makes exactly-once possible.

Failure. If a retry allocates a new sem_id, the peer sees two operations and may execute both. If delivery is de-duplicated on attempt, every retry presents a new key and nothing is ever de-duplicated — a mechanism that looks implemented and does nothing.

DV/debug. All three identities belong in a trace event (21.7 §16). A trace showing attempt = 3, one sem_id, and one delivery is the system working — and being able to say that at a whiteboard is a senior answer.

12. Wrong RTL — One Struct for Every Layer

// WRONG — one "transaction" type carrying every layer's fields. It looks
// convenient and it welds the layers together.
typedef struct packed {
  logic [SEM_W-1:0]  sem_id;
  logic [3:0]        op_class;      // protocol-layer meaning
  logic [LEN_W-1:0]  length;
  logic [15:0]       crc;           // adapter concern
  logic [ATT_W-1:0]  retry_count;   // adapter concern
  logic [7:0]        lane_map;      // PHY concern
  logic [3:0]        train_state;   // PHY concern
  logic              phy_ready;     // PHY concern
} mega_txn_t;

What it costs, layer by layer:

Three properties.

Nothing here is a bug today. Every field is real and someone needs it — which is why an experienced engineer writes this, not a careless one.

The cost appears when you try to change something. Swap the transport, and the protocol layer breaks because it was reading train_state. That is the exact scenario the layering exists to permit (25.1 §8's "PCIe over UCIe").

And the correct answer at a whiteboard is §11's: three types, each layer sees only its own, and the lower layers refer to the identity above rather than embedding its meaning.

13. FDI and RDI Without Overclaiming

FDI sits between the Protocol Layer and the D2D Adapter. RDI sits between the D2D Adapter and the Physical Layer. That is the architecturally important fact, and it is safe to state (§4).

What to say if pushed:

INTERVIEWER:  "What signals are on FDI?"
 
WEAK:         [starts listing remembered signal names]
 
STRONG:       "I'd want the spec in front of me before I list signals. The
               architectural point is that FDI is the boundary where
               protocol-layer meaning stops and adapter-level objects
               begin — so it's where you'd expect to see the handshake for
               handing a transaction down, and state about whether the
               link is able to accept. RDI is the equivalent boundary one
               layer lower, between the adapter and the physical layer."

Three properties.

The strong answer describes what the boundary separates, which is what the question is actually probing.

Listing signals from memory is pure downside (25.1 §13): if you are right, nobody is impressed; if you are wrong, you have made a confident error about a specification you have not read.

And "I'd want the spec in front of me" is not a weak phrase here — it is the 25.2 §12 accuracy theme, and an interviewer who knows the spec will notice you did not bluff.

14. The Recovery Question

The best interview follow-up in this chapter, because it has no one-line answer.

INTERVIEWER:  "If the PHY retrains, do I clear my protocol-layer state?"
 
WEAK:         "Yes, you restart."
WEAK:         "No, everything survives."
 
STRONG:       "It depends on the scope of the recovery, and that's the
               important part. A physical retrain is a transport event. It
               doesn't by itself mean the semantic operations above it
               stopped being valid — a request that was accepted is still
               outstanding, and something still owes it a completion.
 
               So the design has to decide explicitly: does the transport
               retain outstanding objects across this recovery, or does it
               discard them and require replay? Both are legitimate, but
               both sides have to agree, and the protocol layer needs to
               know which.
 
               What's not acceptable is silently dropping them — that
               turns a recovery into a lost transaction, and the symptom
               is a hang with a healthy link."

Four readings.

The answer's shape is "it depends, and here is what it depends on", which is stronger than either flat answer — and it is honest, because the retention rule is a scope question this chapter does not assert (§4).

It names the failure mode, which is what makes it a senior answer rather than a hedge: silent drop produces a hang with a healthy link (23.3 §14).

It introduces "both sides have to agree", which is the bridge to interoperability (22.5 §4) if they want to go there.

And §15 is the RTL follow-up — "show me what going wrong looks like."

15. Wrong RTL — PHY Recovery Deletes Semantic State

// WRONG — the semantic outstanding table is cleared on a physical recovery.
// It is a plausible line of code: the link restarted, so start clean.
always_ff @(posedge clk or negedge rst_n) begin
  if (!rst_n || phy_retrain_done)                 // <-- the bug
    for (int i = 0; i < N_SEM; i++) sem_live_q[i] <= 1'b0;
  else begin
    if (sem_accept_fire)  sem_live_q[sem_alloc_id] <= 1'b1;
    if (sem_retire_fire)  sem_live_q[sem_retire_id] <= 1'b0;
  end
end

The failure, step by step:

Five properties.

Every CRC passed and every link counter is clean. 23.3 §14: transport correctness is not semantic correctness, and this is that lesson at interview depth.

Step 3 is a reasonable-sounding decision. "The link restarted, so its state is stale" is correct for transport state and catastrophic for semantic obligations.

Step 7 is a silent hang — the hardest symptom to debug, because nothing reports an error.

Step 8 turns it into corruption, and is prevented by the generation field in §11.

And the correction is a scope decision made explicit — §16.

16. Corrected — Recovery Scope Is Explicit

// CORRECTED. A transport event never touches semantic state. What happens to
// outstanding work across recovery is a stated CONTRACT, not a side effect.
logic transport_retains_across_recovery;   // from the negotiated agreement
 
always_ff @(posedge clk or negedge rst_n) begin
  if (!rst_n) begin
    for (int i = 0; i < N_SEM; i++) sem_live_q[i] <= 1'b0;
  end else begin
    // Semantic lifetime is driven ONLY by semantic events.
    if (sem_accept_fire)  sem_live_q[sem_alloc_id]  <= 1'b1;
    if (sem_retire_fire)  sem_live_q[sem_retire_id] <= 1'b0;
 
    // A recovery may require REPLAY. It never requires deletion.
    if (recovery_exit && !transport_retains_across_recovery)
      replay_pending_q <= sem_live_q;      // a replay list, NOT a clear
  end
end
 
// MANDATORY. English: a physical recovery does not change the set of live
// semantic operations. Sampled on the recovery EXIT edge, because that is when
// retention is observable; sampling during recovery compares against a
// transient. Fires at the cycle §15's clear would happen.
a_recovery_preserves_semantic_state: assert property (
  @(posedge clk) disable iff (!rst_n)
    $fell(in_recovery) |-> (sem_live_q == $past(sem_live_q, RECOVERY_DEPTH))
);

Architecture. Semantic lifetime driven by semantic events only; the recovery contract selects between retain and replay — and never "clear."

State. The live-operation vector and a replay list.

Event. sem_accept_fire and sem_retire_fire are the only writers. recovery_exit writes the replay list, not the live set.

Contract. transport_retains_across_recovery must come from the negotiated agreement, not be assumed. Two implementations disagreeing about it is a real interoperability failure (22.5 §4).

Failure. Clearing is §15. Retaining when the peer replays produces duplicate delivery instead — which is why the field must be agreed rather than chosen locally.

DV/debug. RECOVERY_DEPTH must be derived from the recovery's duration; a guessed value makes the assertion vacuous or constantly false (21.6 §29). In silicon this becomes a counter: a live-operation count that drops without a matching retirement is §15 caught at the cycle it happens.

17. Assertions Worth Naming

If asked "what would you assert?", these four — and be able to say what each catches.

And the last one is the interview-worthy answer. "That one I'd want to prove formally rather than simulate, because non-interference is a property about all stimulus, not the stimulus I happened to run" — which is a sentence very few candidates say.

18. Ten Follow-Ups

Each with the reasoning, not a one-liner.

Q1 — "Where does retry live?" In the Adapter, and say "can" rather than "does" — it is described as optional (§4). The architectural reason it sits there: it needs to see whole objects and their integrity result, which the PHY does not have and the Protocol Layer should not have to care about.

Q2 — "Does UCIe define coherence?" No. It transports a coherence protocol's messages; the protocol owns the state — who has a line, what ordering is required, when a transaction completes (23.3 §10).

Q3 — "What does FDI separate?" Protocol-layer meaning from adapter-level objects (§13). Describe the boundary, not the signals.

Q4 — "Which layer owns flow control?" "It depends on what you're carrying." A natively mapped protocol may bring its own; the Adapter provides the die-to-die side. A flat answer here is the trap (§9 row 10).

Q5 — "What survives a recovery?" §14's answer: it depends on the recovery's scope, both sides must agree, and silent drop is the one unacceptable option.

Q6 — "Why not merge Adapter and PHY?" Because they change for different reasons. The PHY is tied to the process, package and electricals; the Adapter is tied to the protocols above. Merging them means a process change touches protocol handling.

Q7 — "How do PCIe and CXL relate to this?" They are natively mapped protocols — carried by the Protocol Layer, with their semantics intact. "Carrying PCIe" is not "being PCIe" (23.1 §8).

Q8 — "Which layer owns training?" The Physical Layer, along with the link state machine — RESET through ACTIVE (§4). The Protocol Layer should never see a training state (§12).

Q9 — "Which layer sees a semantic request?" Only the Protocol Layer. The Adapter sees an object that refers to one; the PHY sees an attempt (§11).

Q10 — "What changes with Raw Mode or Streaming?" Which protocol is carried and how much of the Adapter's machinery is in the path. Be careful here — the detail is revision-dependent; the safe framing is "it changes what's carried above the transport, and therefore who owns reliability."

19. Bad Answers

And the first one is the most common. It sounds like an answer, contains three verbs and no content, and an interviewer will immediately ask "adapts what into what?" — which is the question you should have answered unprompted.

20. Controlling the Next Question

End on the clause you most want to expand.

And the third row is the one to aim for. "A retry isn't a second operation" is one clause, it is unambiguously correct, and the follow-up lands you in the three-identity model — which is the most senior thing in this chapter and the easiest to draw.

21. Whiteboard Self-Check

Close the page. Draw the stack and label all six, from memory:

If you can do all six, you can answer §18's ten follow-ups. If you cannot do 2 or 6, those are the two an interviewer is most likely to probe.

22. Understanding Check

23. Summary

Five things.

One sentence, then expand it (§2). Protocol owns meaning, Adapter turns meaning into reliable objects, PHY moves them — and every follow-up expands one clause.

Say what each layer does not know (§3, §7). "The protocol layer doesn't know how many lanes there are" is the abstraction claim, and it separates the answer.

Qualify the Adapter's reliability (§4, §9). "Can provide, described as optional" — three seconds, and the strongest accuracy signal available.

Three identities, not one (§10, §11). A semantic operation, a transport object, several physical attempts — and a retry is never a second operation.

And recovery is a scope question (§14). Retain or replay, agreed by both sides; silent drop is a hang with a healthy link.