AMD Chiplets on UCIe

Chapter 22.1 read a record whose strongest evidence was a demonstration. AMD's is a different shape entirely — a long, high-volume shipping history over a proprietary fabric, and a public position on the standard that is stated as intent.

1. The One-Sentence Model

For a vendor with a mature proprietary fabric, adopting a standard is not a replacement decision — it is a layering decision. UCIe separates Protocol Layer, D2D Adapter and Physical Layer, so the question is not "fabric or UCIe?" but "which layers move, at which die boundary, and what happens to coherence?"

That reframing is what makes this chapter different from 22.1. Intel's most concrete evidence was a cross-foundry interoperability result; AMD's is an installed base and a stated direction — and reading intent correctly is a different skill from reading a demonstration.

2. What This Chapter Owns

22.1 established the evidence method and this chapter uses it without restating it. What is new here is architectural:

The incumbent-fabric problem (§7–§10). A proprietary fabric with a large installed base is not a legacy burden to be migrated away from; it is a working system whose properties a replacement must match.

Layer separation as the actual mechanism (§11–§14). UCIe's stack means a vendor can adopt the physical and packaging layers without abandoning the protocol above them — which is a far more likely path than wholesale replacement, and it changes what "adoption" even means.

Coherence as the binding constraint (§15). It is the reason this is hard, and the reason the answer differs by die boundary.

And reading roadmap evidence (§6, §19) — a weaker level than 22.1's demonstration, needing more care rather than less.

3. Sourcing and Evidence Date

4. Claim-vs-Evidence — AMD and UCIe

Four readings, and the contrast with 22.1 is the point.

The strongest UCIe-specific rows here are Level C — a stated position and a stated intent. 22.1's strongest was Level D, a demonstration. Neither is Level A, but they fail differently: a demonstration proves capability without deployment; intent proves neither.

Rows 4–6 are the strongest rows in the table and none of them is about UCIe. They establish incumbency, which is the actual subject of this chapter (§8).

Row 2's quote is doing less work than it appears to. "Supporting industry standards" and "the ecosystem provided by UCIe is critical" are statements about an ecosystem's importance, not about a product's interface — and the second is explicitly framed around scaling for AI, which is a market claim rather than an implementation claim.

And row 6 is the one I most wanted to resolve and could not (§3). Whether AMD's own fabric roadmap positions UCIe alongside Infinity Fabric is exactly the interesting question, and my partial extraction cannot answer it either way.

5. Two Vendors, Two Evidence Shapes

Two readings.

Neither vendor's record establishes claim 4 (22.1 §4), and both records are genuinely strong on other things. That symmetry is worth noticing, because the internet's claims about the two differ far more than their evidence does.

And the asymmetry is what each chapter teaches. Intel's record raises the cross-foundry question (§14 of 22.1); AMD's raises the incumbent-fabric question, which is the rest of this chapter.

6. Reading Roadmap Evidence

Level C is weaker than Level D, and needs a specific kind of care.

Three rules.

Always carry the date of the statement. A 2025 statement about "future products" describes 2025's intent; repeated in 2027 without its date it reads as a description of shipping silicon.

Never convert "plans to" into "does". 22.1 §26's tense table: ROADMAP and SHIPPING are two rows apart, and the verb is the only thing distinguishing them in a sentence.

And read the scope of the statement, not just its subject. "UCIe is critical to the ecosystem" is a claim about the ecosystem. It is compatible with a company using UCIe everywhere, nowhere, or at one boundary — which means it constrains almost nothing about implementation.

7. Incumbency Is the Subject

Three of the strongest rows in §4 are not about UCIe, and that is not a gap in the evidence — it is the finding.

A vendor that has shipped multi-die processors in volume since well before the standard existed has a working answer to every problem the standard solves. The question is therefore not "will they adopt a solution?" but "what would make them change a solution that works?"

And that is a genuinely different question from 22.1's. Cross-foundry interoperability is about whether something is possible; incumbency is about whether something is worth doing — and the second is answered by architecture and commerce together.

8. The Incumbent-Fabric Problem

What a mature proprietary fabric actually gives you, stated generically (§3 — no Infinity Fabric internals are described here).

Three consequences.

The switching cost is not the interface — it is everything in the right-hand column. Replacing a fabric means re-earning silicon confidence, rebuilding debug intuition, and revalidating a software stack that assumed the old behaviour.

So "why not just adopt the standard?" has a real engineering answer, and it is not inertia. 21.7's row alone is years of accumulated capability.

And none of it argues against the standard where the standard's advantages apply (§10) — which is why the answer is boundary-by-boundary rather than company-wide.

9. What Would Actually Motivate Adoption

Two readings.

Every decisive row involves a boundary that crosses an organisation. 22.1 §15's conclusion, sharpened: the choice tracks the die boundary because the commercial boundary is what a proprietary fabric structurally cannot cross.

And that predicts a mixed package rather than a migration. A product can reasonably use a co-designed fabric between its own tightly coupled dies and a standard interface to a third-party die in the same package — which is not a compromise but the correct answer to two different problems.

10. Where a Standard Wins Inside an Incumbent's Product

And the last row is why this chapter needs §14–§15. Coherence is where the incumbent fabric's advantages are largest and the standard's constraints are tightest — so it is both the most interesting boundary and the least likely to move first.

11. Layering, Not Replacement

The chapter's central architectural insight, and it follows directly from the published stack.

UCIe separates the Protocol Layer from the D2D Adapter and the Physical Layer (19.1). A vendor can therefore adopt the lower layers — the PHY, the packaging discipline, the electrical and interoperability story — while continuing to carry its own protocol above them.

Three readings, and the second is the one most analysis misses.

"Adopting UCIe" is not one decision. It is three, and a product can take the first without the third. A press statement saying a company "supports UCIe" does not say which row — which is §6's scope problem in concrete form.

Row 1 is a genuinely useful outcome on its own. Standard electricals and packaging mean a die can be built with predictable physical behaviour and characterised against a shared methodology, even if only the vendor's own protocol crosses it.

And row 3 is the only row that delivers what the standard is for. A proprietary protocol over a standard PHY is two dies from one company using a shared wire — which is worth something, but it is not the multi-vendor chiplet market.

12. Carrying a Proprietary Protocol

What official UCIe material establishes about non-native protocols (§3): PCIe and CXL are natively mapped; Streaming Protocols were supported in Raw Mode in UCIe 1.0 and permitted on FDI from 1.1.

Which gives a proprietary fabric two structural options, with different consequences:

Four readings.

Raw Mode is the minimum-change path and the most expensive in obligations. The protocol keeps its own framing and semantics — and must therefore provide its own error detection, retry and flow control, because it is not using the Adapter's (14.1, 14.2).

For an incumbent fabric that already has those mechanisms, that is not a burden — it is the status quo. Which makes Raw Mode a much more natural first step for a mature fabric than for a new one.

The Streaming path trades adaptation work for the Adapter's reliability, and the question is whether the fabric's own semantics survive the Adapter's framing and ordering model — which is exactly the analysis 19.2 sets up.

And the 1.0 → 1.1 change is a worked example of 21.6 §32's revision scoping with real commercial consequence: the same architectural intent is legal on FDI under one revision and not the other — so "does this work?" cannot be answered without naming the revision.

13. Illustrative — a Protocol-Agnostic Die Boundary

// ILLUSTRATIVE ONLY. A die-boundary wrapper parameterised on WHICH layers come
// from the standard — the §11 decision, expressed as a configuration rather
// than as three separate designs.
typedef enum logic [1:0] {
  ADOPT_PHY_ONLY     = 2'd0,  // proprietary protocol + own reliability, raw wire
  ADOPT_PHY_ADAPTER  = 2'd1,  // proprietary protocol, standard framing/retry
  ADOPT_FULL_STACK   = 2'd2   // natively mapped protocol — full interoperability
} adoption_mode_e;
 
module die_boundary #(
  parameter adoption_mode_e MODE = ADOPT_PHY_ADAPTER
) (
  input  logic            clk,
  input  logic            por_n,
  // upstream: whatever protocol this die actually speaks
  input  fabric_txn_t     up_txn,
  input  logic            up_valid,
  output logic            up_ready,
  // downstream: toward the physical layer
  output link_payload_t   dn_payload,
  output logic            dn_valid,
  input  logic            dn_ready
);
 
  // The RELIABILITY OBLIGATION moves with the adoption mode. This is the whole
  // architectural content of §12: in PHY-only mode the fabric must supply its
  // own error detection and retry, because the Adapter's are not in the path.
  localparam bit FABRIC_OWNS_RELIABILITY = (MODE == ADOPT_PHY_ONLY);
 
  generate
    if (MODE == ADOPT_PHY_ONLY) begin : g_raw
      // Proprietary framing straight onto the wire. The fabric's OWN CRC and
      // retry are mandatory here — omitting them is not "simpler", it is a
      // link with no error handling at all (14.1).
      fabric_raw_framer u_framer (
        .clk(clk), .por_n(por_n),
        .txn(up_txn), .txn_valid(up_valid), .txn_ready(up_ready),
        .payload(dn_payload), .payload_valid(dn_valid), .payload_ready(dn_ready)
      );
    end else if (MODE == ADOPT_PHY_ADAPTER) begin : g_stream
      // Proprietary transactions carried as an opaque stream. The fabric's
      // SEMANTICS must survive the adapter's ordering and framing model — this
      // is the real adaptation work, and it is not a wrapper (19.2).
      fabric_to_stream_shim u_shim (
        .clk(clk), .por_n(por_n),
        .txn(up_txn), .txn_valid(up_valid), .txn_ready(up_ready),
        .payload(dn_payload), .payload_valid(dn_valid), .payload_ready(dn_ready)
      );
    end else begin : g_native
      // A natively mapped protocol. Only this mode delivers cross-vendor
      // interoperability (§11 row 3).
      native_protocol_engine u_native (
        .clk(clk), .por_n(por_n),
        .txn(up_txn), .txn_valid(up_valid), .txn_ready(up_ready),
        .payload(dn_payload), .payload_valid(dn_valid), .payload_ready(dn_ready)
      );
    end
  endgenerate
 
  // MANDATORY. English: in PHY-only mode the fabric's own integrity check must
  // be present on every payload. Fires if a design is reconfigured from
  // adapter-mode to raw-mode and inherits the ASSUMPTION that something
  // downstream is checking — the most dangerous edit in this whole file.
  if (FABRIC_OWNS_RELIABILITY) begin : g_reliability_assert
    a_raw_mode_carries_own_integrity: assert property (
      @(posedge clk) disable iff (!por_n)
        dn_valid |-> dn_payload.fabric_crc_valid
    );
  end
 
endmodule

Architecture. One boundary, three adoption modes, with the reliability obligation derived from the mode rather than assumed.

State. None at this level; the generated sub-blocks hold it.

Event behaviour. Structural — the mode is elaboration-time.

Contract. FABRIC_OWNS_RELIABILITY encodes §12's central consequence: in Raw Mode the Adapter's CRC and retry are not in the path, so the fabric must supply its own. This is not a tuning parameter — it is a statement about who is responsible for correctness.

Failure. The dangerous edit is reconfiguring an existing design from adapter-mode to raw-mode. The protocol still works; the error handling silently disappears, and the link runs unprotected until a marginal channel exposes it — at which point the symptom is data corruption with a perfectly legal protocol trace (21.7 §32's physical-suspicion signature, produced by a configuration error).

Debug/DV. The assertion is generated only in the mode where the obligation exists, so it cannot fire spuriously in the other two — and its presence documents the obligation in the RTL rather than in a comment.

14. Illustrative — Where Coherence Constrains the Boundary

// ILLUSTRATIVE ONLY (§13). Coherent traffic imposes requirements a streaming
// transport need not meet. This structure exists to make §18's constraints
// concrete and CHECKABLE, not to describe any product.
typedef struct packed {
  logic [ID_W-1:0]    txn_id;
  logic [3:0]         coh_opcode;      // request / snoop / response / completion
  logic [ADDR_W-1:0]  addr;
  logic [1:0]         order_domain;    // which ordering rules apply
  logic               requires_ack;    // must a completion return?
  logic               snoop_related;   // part of a snoop transaction
  logic [7:0]         home_node;       // who owns the coherence decision
} coherent_txn_t;
 
// The four properties a transport must preserve for coherence to remain
// correct across a die boundary. Each is a REQUIREMENT on the link, and each
// is a reason coherent boundaries are the hardest to move (§18).
typedef struct packed {
  logic ordering_preserved;   // within an order domain, order survives
  logic no_silent_drop;       // a lost request is a HANG, not a retry (14.2)
  logic completion_guaranteed // every requires_ack transaction completes
       ;
  logic bounded_latency;      // beyond a bound, coherence stalls the system
} coherence_transport_reqs_t;
 
// MANDATORY. English: a transaction requiring acknowledgement must complete
// within the architecture's bound. For coherent traffic this is not a
// performance property — an uncompleted coherent request stalls a core
// indefinitely, which is why §18 calls latency a CORRECTNESS-ADJACENT concern.
property p_coherent_txn_completes(int id);
  @(posedge clk) disable iff (!por_n)
    (txn_issue_fire && (issue_id == id) && issue_txn.requires_ack)
      |-> ##[1:MAX_COHERENT_LATENCY] (completion_fire && (comp_id == id));
endproperty
a_coherent_completes: assert property (p_coherent_txn_completes(TEST_ID));
 
// MANDATORY. English: ordering is preserved WITHIN an order domain and is not
// asserted across domains — asserting a global order would be 21.6 §15's
// false violation, and would serialise the link to satisfy a rule nobody made.
property p_order_within_domain(int dom);
  @(posedge clk) disable iff (!por_n)
    (deliver_fire && (deliver_domain == dom))
      |-> (deliver_seq[dom] == expected_seq[dom]);
endproperty

Architecture. A coherent transaction record plus the four transport requirements coherence imposes, expressed as checkable properties.

State. Per-domain expected sequence, and outstanding-transaction tracking.

Event behaviour. The completion property arms on issue and must be satisfied within an architectural bound.

Contract. MAX_COHERENT_LATENCY is a system quantity, not a link tuning knob. A coherent request that does not complete stalls a core — so a latency bound that a streaming transport would treat as a performance target is, for coherence, the boundary between working and hung (13.3's deadlock reasoning).

Failure. The p_order_within_domain property is deliberately scoped to a domain. Asserting a global order across domains is 21.6 §15's error, and the "fix" — serialising the link — is a throughput regression introduced to satisfy a rule that was never required.

Debug/DV. These four requirements are what §18's table lists in prose. Writing them as properties is what makes "coherence is harder" a testable statement rather than an assertion of difficulty.

15. Coherence Is the Binding Constraint

Three readings.

The first row is why coherent boundaries move last. A transport whose latency varies is a performance problem for streaming and a correctness problem for coherence, because a core waiting on a coherent request is not making progress at all.

The fourth row is why 14.2's reliability question is load-bearing here and only advisory elsewhere. §12's Raw Mode option — where the Adapter's CRC and retry are not in the path — is far more consequential for coherent traffic, because the fabric's own mechanisms must be complete rather than merely present.

And this is the strongest architectural argument for why an incumbent fabric persists at coherent boundaries (§10): the fabric was co-designed with the coherence protocol, and the transport requirements above were satisfied by construction rather than by adaptation.

16. Reading the Chiplet Timeline

AMD's FAD 2025 presents a chiplet and packaging arc from 2017 to 2026 (§4, Level A/B, partial read). Read architecturally rather than chronologically, that arc says three things:

Chiplet partitioning predates the standard by years. Whatever interfaces those products used, they were designed before UCIe 1.0 existed (March 2022) — which is 22.1 §12's point with a timeline attached.

The strategy is presented as a headline capability, not an implementation detail — which tells you partitioning is a product-level decision at this company, with the interface subordinate to it.

And a decade of accumulated packaging and fabric co-design is exactly §8's right-hand column. The switching cost is not conceptual; it is ten years of silicon confidence, debug intuition and software assumptions.

17. What Public Evidence Cannot Tell You

And the fifth row is the one worth wanting most. §11's three-way layering choice is the single most informative thing a disclosure could reveal about a vendor's relationship with the standard — and it is almost never stated, because "supports UCIe" is the marketable sentence and "adopts the PHY but not the Adapter" is not.

18. Claims Deliberately Not Made

Stating these explicitly is part of the method, not an apology for it.

And the second row is the most instructive. I have a primary document, a partial read, and a conspicuous absence — and the absence is a property of my extraction, not of the deck. 21.7 §11: a record that is real but incomplete produces conclusions that are confident and wrong.

19. Common Misconceptions

"A proprietary fabric is legacy that will be replaced." §8: it is a working system with a decade of silicon confidence, debug intuition and software assumptions behind it. The switching cost is that column, not the interface.

"Adopting UCIe is one decision." §11: it is three — PHY, PHY plus Adapter, or the full stack — and a company can take the first without the third.

"A proprietary protocol can't use UCIe." §12: Raw Mode and the Streaming path both exist. What changes is who owns reliability.

"Raw Mode is the simple option." §12–§13: it is the minimum-change option and the maximum-obligation one, because the Adapter's CRC and retry are not in the path.

"Coherence is just low-latency traffic." §15: latency becomes correctness-adjacent, a silent drop becomes a deadlock, and every request must complete.

"AMD is behind Intel on UCIe." §5: the two records differ in shape — a demonstration versus a stated intent — and neither establishes shipping deployment.

"'Plans to integrate' means it's coming next generation." §6: a roadmap statement carries a direction and the date it was made, not a schedule.

"If the standard is better, the incumbent should switch everywhere." §9–§10: the decisive pressures all involve a boundary that crosses an organisation. Inside one, co-design usually wins.

20. Understanding Check

21. Summary

Five things, and only the first is about AMD.

Incumbency changes the question (§7). A vendor with a decade of shipping multi-die products has a working answer to every problem the standard solves — so "why adopt?" is answered by architecture and commerce, not by the standard's merits.

Adoption is a layering decision, not a replacement (§11). PHY, PHY-plus-Adapter, or full stack — three genuinely different outcomes that one press sentence cannot distinguish, and only the third delivers interoperability.

Reliability moves with the layer (§12–§13). Raw Mode is the minimum-change path and the maximum-obligation one, and reconfiguring into it silently removes error handling — which is why §13 generates the assertion only in that mode.

Coherence binds hardest (§15). Latency becomes correctness-adjacent, drops become deadlocks, completion becomes mandatory — so coherent boundaries move last, if at all.

And the decisive pressure is organisational, not technical (§9). Every strong reason to adopt involves a die crossing a company boundary — which predicts mixed packages rather than migrations, and means the honest expectation is both interfaces coexisting for a long time.

On the evidence itself: AMD's public record is strong on chiplet incumbency and Level C on UCIe — a stated position and a stated intent, with no shipping deployment established from sources I could reach (§3). 22.1's was strong on a cross-foundry demonstration and equally silent on deployment. The two records differ in shape rather than in rank, and treating either as evidence of shipping UCIe is the same error in two costumes.