Industry Standardisation

Chapter 3.2 established what interoperability costs: agreement across four layers, every one of them conjunctive, with invariants precise enough that an independent team can implement from the text and get a compatible result. That is a substantial amount of agreement to reach with one partner.

This chapter asks what happens when you want it with many, and the answer is not "more of the same work". It is a different problem with a different shape, and recognising that shape is what motivates a standard. The chapter is deliberately about standards architecture rather than about UCIe: what a good die-to-die specification must define, what it must deliberately leave alone, and why the interesting engineering decisions in standards work are about restraint.

1. Six Agreements for Four Companies

Count the work. Four companies each want their dies to work with the others'. Bilateral agreements give:

A↔B, A↔C, A↔D, B↔C, B↔D, C↔D — six relationships.

Each of those six is a full instance of Chapter 3.2: four layers, negotiated, documented, implemented, and verified between two specific parties. Add a fifth company and it needs four new relationships, bringing the total to ten. The count grows roughly as N × (N − 1) / 2 — quadratically rather than linearly.

The arithmetic is the least interesting part. What matters is what each relationship contains:

• A negotiation between two organisations that may be competitors.
• A document that exists only for that pair, which nobody else benefits from.
• Two implementations built against that document, reusable with nobody else.
• A verification effort against that specific partner.
• A maintenance obligation whenever either side revises.

So the cost is not just quadratic in count — each unit of it is non-reusable. Effort spent making A work with B contributes nothing to making A work with C. A company wanting to interoperate with four partners builds four interfaces, not one.

2. What Changes, and What Does Not

Be precise about the improvement, because overstating it is the standard failure mode of standards advocacy.

What changes. Each participant implements against one definition rather than several. Verification targets a specification rather than a set of named partners. A die built once can meet partners that did not exist when it was designed. And the specification's cost is shared across everyone who uses it, rather than paid per pair.

What does not change. Every implementation still has to be verified. Every physical pairing still has to be validated (Chapter 2.6 — the package does not standardise itself). Ambiguity in the specification still produces incompatible-but-compliant implementations (Chapter 3.2, §11). Nobody is relieved of engineering.

The honest summary is a change in the kind of work rather than its absence:

A standard replaces "design an interface with this partner" with "implement this contract, then demonstrate conformance and interoperability against it."

That is a better trade at almost any ecosystem scale, and it is not a free one.

3. What a Standard Must Define

A specification is useful exactly to the extent that an independent team can implement from it and interoperate. That sets the requirement: it must define everything externally visible, and nothing more.

Concretely, it must pin down:

• Externally visible behaviour at every layer of Chapter 3.2's stack — electrical, link, transaction, management. Anything an implementer must assume about the partner belongs here, including the invariants that only appear as assertions.
• Required functionality — the mandatory baseline every conforming implementation provides.
• Optional functionality — capabilities an implementation may support, defined precisely enough that a partner can rely on them when present.
• Configuration and negotiation rules — how a mutually supported operating point is found, and what happens when none exists.
• Error semantics — what is detected, who reports, who retries, whether traffic continues, what reset is required.
• Versioning and compatibility rules — how revisions identify themselves and what a newer implementation owes an older partner.
• Compliance expectations — what it means to claim conformance, and how that is demonstrated.

Notice that the list is derived directly from Chapter 3.2's failure modes. That is not a coincidence — a specification is the set of agreements whose absence causes interoperability failures, which is why studying the failures first was the right order.

4. Standardise the Contract, Not the Implementation

Now the restraint, which is the harder half of standards design and a genuinely fundamental architecture principle.

A standard should not prescribe internal RTL structure, state-machine microarchitecture, FIFO depth or implementation, internal clocking arrangement, pipeline depth, or physical placement — unless externally visible behaviour genuinely requires it.

The reason is not politeness toward implementers. Over-specification actively destroys value: it forecloses optimisations that would not affect interoperability, prevents implementations from being tuned to their product's needs, makes conformance harder to demonstrate (you now have to prove internal structure, not observable behaviour), and ages badly, since internal techniques improve faster than interfaces do.

Standardise the contract, not the implementation.

Make it concrete. Here are two implementations of the same external transport contract from Chapter 3.2 — the one requiring that a presented beat be held stable until accepted.

Illustrative RTL — not UCIe specification signal naming.

Implementation A — direct register. The simplest conforming sender: one beat in flight, held while stalled.

// Endpoint A: single-beat register. Stalls the upstream source whenever
// the presented beat has not yet been accepted.
always_ff @(posedge clk) begin
  if (!rst_n) begin
    valid_q <= 1'b0;
    data_q  <= '0;
  end else if (valid_q && !ready_i) begin
    valid_q <= 1'b1;            // hold: contract requires stability
    data_q  <= data_q;
  end else if (src_valid) begin
    valid_q <= 1'b1;
    data_q  <= src_data;
  end else begin
    valid_q <= 1'b0;
  end
end
 
assign src_ready = !valid_q || ready_i;   // accept when we have room

Implementation B — skid buffer. Adds one stage of storage so the upstream source is not stalled the moment the downstream stalls. Different internal structure, different area, different timing, identical external contract.

// Endpoint B: skid buffer. Absorbs one beat so src_ready need not fall
// on the same cycle that ready_i falls. Externally indistinguishable
// from A apart from throughput under intermittent backpressure.
logic              skid_v_q;
logic [DATA_W-1:0] skid_d_q;
 
always_ff @(posedge clk) begin
  if (!rst_n) begin
    valid_q  <= 1'b0;  data_q  <= '0;
    skid_v_q <= 1'b0;  skid_d_q <= '0;
  end else begin
    if (!valid_q || ready_i) begin
      // Output stage is free: take from skid first, else from source.
      if (skid_v_q) begin
        valid_q  <= 1'b1;      data_q <= skid_d_q;
        skid_v_q <= 1'b0;
      end else begin
        valid_q  <= src_valid;
        data_q   <= src_data;
      end
    end
    // Output stalled but source is offering: capture into the skid stage.
    if (valid_q && !ready_i && src_valid && !skid_v_q) begin
      skid_v_q <= 1'b1;
      skid_d_q <= src_data;
    end
  end
end
 
assign src_ready = !valid_q || ready_i || !skid_v_q;

A receiver cannot tell these apart by anything the contract covers. Both hold a presented beat until accepted; both never present unknown data; both refuse new input when full. They differ in area, timing, and throughput under intermittent backpressure — all of which are implementation concerns the standard has no business dictating.

That is the principle in action: the specification constrains the observable invariant, and everything behind it remains an engineering choice. Had the standard instead mandated "register the payload in a single flop", Implementation B would be non-conforming despite being externally indistinguishable and better for some products.

5. The Contract as Executable Specification

The natural companion to §4 is that externally visible rules can be written so a tool checks them — which is what makes a specification verifiable rather than merely readable.

// Illustrative externally observable requirements — generic transport
// invariants, not UCIe normative properties.
 
// A qualified beat must carry defined data. Catches X-propagation and
// uninitialised paths that would otherwise corrupt a partner silently.
property p_no_unknown_when_valid;
  @(posedge clk) disable iff (!rst_n)
    valid_q |-> !$isunknown(data_q);
endproperty
assert property (p_no_unknown_when_valid);
 
// The stability rule from Chapter 3.2 — the invariant a receiver relies on.
property p_hold_until_accepted;
  @(posedge clk) disable iff (!rst_n)
    (valid_q && !ready_i) |=> (valid_q && $stable(data_q));
endproperty
assert property (p_hold_until_accepted);

Both properties hold for Implementation A and Implementation B. That is the point worth dwelling on: the assertions constrain exactly what the contract constrains, and no more. They pass for two structurally different designs, and they would fail for a sender that advanced its payload while stalled.

This gives a practical test for whether a proposed specification rule is well-formed:

If a rule cannot be expressed as a check on externally observable behaviour, it is probably describing an implementation rather than a contract — and it probably does not belong in the specification.

A rule about FIFO depth fails that test. A rule about payload stability under backpressure passes it. The distinction is not stylistic; it decides whether conformance is demonstrable.

6. Mandatory Baseline and Optional Capability

A standard needs both, and the balance between them determines whether it is useful.

All-mandatory forces every implementation to build every feature. A small, cost-sensitive die pays for capability it will never use, so it either implements the standard expensively or does not adopt it. Adoption suffers, and a standard nobody adopts provides no interoperability.

All-optional produces a specification that guarantees nothing. Two "conforming" implementations may share no capability at all, so Chapter 3.2's capability intersection comes out empty and the link cannot come up. Conformance stops predicting interoperability, which is the one thing it exists to do.

So a workable standard needs: a mandatory baseline that every conforming implementation provides, optional capabilities defined precisely enough to be relied on when present, discovery and negotiation so a common operating point can be found, and compatibility rules describing legal combinations.

The value of a standard depends on having a useful mandatory common subset — one large enough that any two conforming implementations can actually do something together.

The tension is real and permanent. Every proposal to make a feature mandatory raises the cost of entry; every proposal to make one optional weakens what conformance guarantees. This is much of what standards working groups actually argue about, and neither position is obviously right.

7. Revision Evolution Is Part of the Design

A specification that cannot change becomes obsolete; one that changes carelessly destroys the ecosystem it created. So evolution has to be designed rather than improvised.

The mechanisms are the ones Chapter 3.2 identified from the implementation side, now viewed as specification features:

• Revision identification so each side knows what the other implements.
• Backward compatibility rules stating what a newer implementation owes an older partner — and, importantly, whether that obligation exists at all, since "compatible" is a promise with a cost.
• Capability discovery so new features are additive rather than breaking.
• Deprecation policy for retiring behaviour without stranding deployed silicon.
• Optional extensions as the mechanism for adding capability without raising the mandatory baseline.

The constraint that makes hardware standards harder than software ones is worth naming: deployed silicon cannot be patched. A software interface can require all parties to upgrade; a die that shipped three years ago will still be shipped, and a new partner either works with it or does not. Compatibility obligations therefore extend across silicon generations, and a revision that breaks them strands real inventory.

A standard is not a snapshot of compatibility. It is a strategy for preserving compatibility over time.

8. What a Standard Still Does Not Give You

The final restraint, because this is where standards are most often oversold — and where a reader who believes the oversell will be surprised in practice.

A common die-to-die specification defines the interface. It does not by itself deliver:

• Package compatibility. Two dies can implement the same interface and require incompatible physical arrangements — bump patterns, reach, routing structure. Chapter 2.6's constraints are unaffected by the interface being standard.
• Thermal and power compatibility. A die's dissipation and delivery requirements must fit the package and system it lands in.
• Software readiness. Drivers, firmware, and runtime support are not implied by a hardware interface.
• Security posture. What each die trusts, and what it exposes to a partner, is a system question.
• Validation of the specific combination. Every assembled product is a new system requiring its own qualification.
• Commercial qualification. Availability, support, quality data, lifecycle guarantees — the things a company needs before designing a part into a product.

So a standard is a necessary condition for cross-vendor composition, and a long way from a sufficient one. The distance between the two is roughly what remains of the chiplet-ecosystem problem after the interface is solved.

9. Common Misconceptions

10. Understanding Check

11. Summary and What Comes Next

Bilateral compatibility fails on two counts: the number of relationships grows roughly as N(N−1)/2, and none of the effort is reusable — making A work with B contributes nothing toward A and C. A standard changes the shape of the problem, from a quadratic mesh of private agreements to one contract each party implements once. It does not remove work; it converts "design an interface with this partner" into "implement this contract and demonstrate conformance and interoperability against it."

A standard must define everything externally visible — behaviour at each layer, the mandatory baseline, precisely specified options, negotiation rules, error semantics, versioning and compatibility, and what conformance means — a list derived directly from Chapter 3.2's failure modes. And it must standardise the contract, not the implementation: the direct register and the skid buffer satisfy identical assertions with different internal structure, and a standard that forced one of them would destroy value without buying interoperability. A useful test is whether a rule can be expressed as a check on observable behaviour; if not, it is describing an implementation.

Two balances then decide whether the standard works. The mandatory baseline must be large enough that any two conforming implementations can do something together, while remaining small enough that adoption is affordable. And revision has to be designed — identification, backward-compatibility obligations, discovery, deprecation, optional extensions — because deployed silicon cannot be patched. Finally, a standard is necessary and not sufficient: package, thermal, software, security, per-combination validation, and commercial qualification all remain.

Which leaves the institutional question. A shared contract of this kind has to be written, argued over, revised on a cadence, and kept neutral enough that competitors will build against it — none of which happens without an owner:

• 3.4 — The UCIe Consortium — who maintains the specification, why a consortium rather than a company, and how governance decisions become engineering requirements.

Browse the full path on the UCIe tutorials index.