Future SoCs

Three chapters have asked where a standard boundary fits in products that exist. This one asks what would have to be true for dies from different suppliers to be integrated by a third party — and the link is the easy part.

1. The One-Sentence Model

A standardised link turns a package boundary into a transport contract. It does not turn it into an integration contract. Two chiplets can both expose a conforming PHY and remain unintegrable because their protocol semantics, management model, power and reset sequencing, security expectations, version profiles and verification collateral disagree — and none of those is visible at the wire.

So "UCIe makes chiplets plug-and-play" is not merely optimistic — it names the wrong layer. §5 is the contract the other layers imply, and most of it is not standardised by anything.

2. What This Chapter Owns

Three things are new here:

The integration contract (§5–§7) — the seven layers two suppliers must agree on, of which the link is one.

Version and capability negotiation done correctly (§8–§11), including why "use the highest supported version" is a bug and what a partial configuration commit does to two dies that disagree.

And the ecosystem's verification problem (§14–§16). A chiplet sold to integrators must ship with something; what that something is turns out to be the hardest unsolved part.

3. Sourcing and Evidence Date

4. Both Sides Conform, Neither Integrates

Start with the failure, because it makes the rest of the chapter necessary.

Three readings.

The link works perfectly and nothing else does. Every row below the second is invisible at the wire and fatal at integration.

The reset row is the sharpest. Two dies that each wait for the other to initialise first will never come up — 21.1's hang, caused by an unstated assumption on both sides rather than by a defect on either.

And no row here is a defect. Both suppliers built exactly what they specified. The gap is that nobody specified the agreement between them, which is what §5 is for.

5. The Chiplet Integration Contract

Three things to read.

The centre column is the transport contract; the right column is agreed per integration. A die-to-die specification addresses the first — and §4's failure lives entirely in the second.

The red nodes are where two suppliers have nothing forcing agreement. Each is a real engineering interface with real failure modes, and each is negotiated bilaterally today.

And ver spans everything. A chiplet sold to an integrator must arrive with something that lets the integrator check the agreement holds (§14) — and that collateral is currently the least standardised part of the whole picture.

6. Protocol Semantics Are Not Transport

Two dies can carry the same bytes and mean different things by them.

And the second row is the one that fails silently. 22.2 §13: if A assumes the Adapter's CRC and retry are in the path and B is running Raw Mode, the link works and is unprotected — data corruption with a legal protocol trace.

7. Management, Power and Reset

The three layers that make §4's chiplets fail to come up at all.

Two properties.

These are sequencing agreements, so they fail at bring-up rather than under load — which is the good news: 21.1's dependency ledger finds them, and they are deterministic.

And they are almost entirely absent from a transport specification, because they concern what the dies do around the link rather than on it.

8. Illustrative — Capability Descriptor

// ILLUSTRATIVE ONLY. What one chiplet must publish for another to decide
// whether integration is possible. Structured by §5's layers, deliberately —
// so a missing agreement is a missing FIELD rather than an unasked question.
typedef struct packed {
  // identity
  logic [15:0] vendor_id;
  logic [15:0] part_id;
  logic [7:0]  revision;
  logic [7:0]  chiplet_role;
 
  // TRANSPORT — the layer a link specification addresses
  logic [7:0]  link_spec_major;      // which revision — §9
  logic [7:0]  link_spec_minor;
  logic [7:0]  link_class_caps;      // symbolic classes, not UCIe widths (§3)
  logic        adapter_reliability;  // does it USE the adapter's CRC/retry?
 
  // PROTOCOL — §6
  logic [15:0] protocol_caps;        // one bit per protocol it can carry
  logic [7:0]  protocol_required;    // what it REQUIRES the peer to accept
  logic [7:0]  ordering_domains;     // how many it distinguishes
  logic        completion_guaranteed;
 
  // MANAGEMENT / POWER / RESET — §7
  logic [7:0]  mgmt_version;
  logic        reset_is_initiator;   // §4's deadlock, as one bit
  logic [7:0]  power_states_caps;
 
  // SECURITY — §12 (requirement, not a solution)
  logic [7:0]  security_profile;
  logic        requires_peer_attestation;
 
  // RESOURCES
  logic [15:0] max_outstanding;
  logic [15:0] max_payload;
} chiplet_capability_t;

Architecture. One record per chiplet, organised by §5's layers, so the structure itself enumerates what must be agreed.

State. A constant per chiplet plus a register holding the peer's copy.

Cycle/event behaviour. Exchanged once per agreement; re-exchanged on renegotiation — a die that changes its advertised capability mid-agreement is 21.6 §27's illegal configuration mutation.

Contract. The *_required fields are what make a mismatch detectable at bring-up rather than at runtime (22.3 §15). And reset_is_initiator is one bit that prevents §4's deadlock — two dies both advertising 1 is a detectable, reportable incompatibility rather than a silent mutual wait.

Failure. §10 and §11.

DV/debug. Both records belong in the snapshot (21.7 §9). In an interoperability matrix the failing pair is usually distinguished by one field — and without the record that comparison cannot be made at all.

9. Version Negotiation

The specification record shows revisions in 2022, 2023, 2024 and 2025 (§3). A chiplet designed against one revision may be integrated years later against a peer built to another — which is an engineering consequence, not a forecast.

10. Wrong RTL — Pick the Highest Version

// WRONG — each side independently selects the highest version it supports.
// Plausible, and it produces two dies running different rule sets.
assign active_version = (local_max > peer_max) ? local_max : peer_max;   // MAX

Worked. A supports up to revision 3; B supports up to revision 2.

Both sides select revision 3. B does not implement revision 3.

Four properties.

The expression is symmetric, which is what makes it look correct — both sides compute the same answer, and agreement feels like success.

They agree on a version one of them cannot honour. B then either fails on the first revision-3 behaviour or, worse, interprets it under revision-2 rules — 21.6 §33's wrong-revision failure, built into the negotiation.

min is the only correct reduction, and the argument is one line: neither side may assume the peer implements anything above what it advertised.

And this generalises past versions. Every capability reduction in §8 is an intersection; taking a union anywhere produces an agreement neither side can fully honour (22.1 §22).

11. Wrong RTL — Partial Configuration Commit

// WRONG — each side applies the negotiated configuration when it is ready.
// There is no barrier, so for a window the two dies disagree.
always_ff @(posedge clk or negedge por_n) begin
  if (!por_n)                 active_cfg_q <= CFG_DEFAULT;
  else if (negotiate_done_q)  active_cfg_q <= negotiated_cfg_q;   // local only
end

The window, worked.

Four properties.

For four cycles the two dies mean different things by the same bytes. Not a dropped packet — a misinterpreted one, which is far worse because it may be silently accepted.

The window is short, load-dependent and reproduces poorly — the hardest class (19.5 §39).

And the correct structure is an atomic commit with quiesce (21.6 §26): drain outstanding traffic, commit both sides against an agreed epoch, resume. The epoch is what makes it checkable:

// CORRECTED. Commit only at quiesce, and advance a shared epoch so any event
// can be attributed to the configuration that was live when it was issued.
always_ff @(posedge clk or negedge por_n) begin
  if (!por_n) begin
    active_cfg_q   <= CFG_DEFAULT;
    cfg_epoch_q    <= '0;
  end else if (cfg_commit_fire) begin        // asserted only when BOTH quiesced
    active_cfg_q   <= negotiated_cfg_q;
    cfg_epoch_q    <= cfg_epoch_q + 1'b1;
  end
end
 
// MANDATORY. English: the active configuration changes only at a commit, and
// only with nothing in flight. Fires at the cycle of the partial commit above.
a_cfg_atomic: assert property (
  @(posedge clk) disable iff (!por_n)
    $changed(active_cfg_q) |-> ($past(cfg_commit_fire) && ($past(inflight_q) == '0))
);
 
// MANDATORY. English: an event carrying a stale epoch is rejected, not applied.
a_stale_epoch_rejected: assert property (
  @(posedge clk) disable iff (!por_n)
    (rx_fire && (rx_epoch != cfg_epoch_q)) |-> rx_rejected
);

Architecture. Commit gated on mutual quiescence, with a monotonic epoch.

State. The active configuration and the epoch.

Cycle/event behaviour. cfg_commit_fire must be asserted only when both sides have quiesced — which requires a handshake, not a local decision.

Contract. inflight_q must count every outstanding obligation, not one class's (22.2 §14). A quiesce that drains one queue and not another commits with work still in flight under the old rules.

Failure. Without the epoch, a straggler from the previous configuration is applied under the new rules and the resulting misbehaviour is reported as a peer violation (21.6 §11).

DV/debug. The epoch in every trace event is what makes a cross-reconfiguration trace interpretable at all (21.7 §16).

12. Security and Trust

A standardised interface between independently sourced dies makes the package boundary a trust boundary, and that is an architectural change rather than a protocol feature.

13. Fault Containment

A reusable chiplet needs a health and isolation contract, or one supplier's fault becomes every integrator's package failure.

And the fourth row is the hardest to specify across suppliers, because it is a statement about semantic state — what outstanding work means after recovery — and that is precisely what a transport contract does not cover (21.4 §23).

14. Verification Collateral

19.6 covers reusable IP within one organisation. Across organisations the problem changes shape.

Two readings.

The reference model is the load-bearing item and the least likely to be shipped. Without it the integrator can only check that the chiplet agrees with itself — which two dies sharing a misinterpretation also do (21.6 §24).

And this is the ecosystem's genuinely unsolved problem. A conforming link is checkable; a conforming semantic contract requires collateral that no specification currently obliges anyone to provide.

15. Ecosystem Verification

Vendor A's die under test, vendor B's die as peer, and no shared assumption.

And 20.7's finding applies directly: compliance testing validates a device against a known-good reference. That establishes conformance to the reference — not that two arbitrary conforming dies will integrate, because §5's right-hand column was never in scope.

16. Supply-Chain Heterogeneity

And the last row is the durable one. A chiplet designed once may be integrated for years against peers built later — so version negotiation is not a bring-up detail, it is a product-lifetime requirement (§9).

17. Conceptual Scenarios

And the pattern across all four is §1's: the transport question is the same in each, and the hardest layer is different in each — which is why a single standard cannot make any of them plug-and-play on its own.

18. Wrong Abstraction — One Universal Chiplet Type

// WRONG — one transaction type carrying every optional field for every
// possible chiplet role. It looks like maximum reuse and it is the opposite.
typedef struct packed {
  logic [ID_W-1:0]     id;
  logic [ADDR_W-1:0]   addr;
  logic [3:0]          coherence_state;   // meaningless to a bridge chiplet
  logic [7:0]          tensor_shape;      // meaningless to an IO die
  logic [7:0]          device_class;      // meaningless to a compute tile
  logic [15:0]         optical_lambda;    // meaningless to almost everything
  /* ...and so on, for every role in the ecosystem... */
} universal_chiplet_txn_t;

Four properties.

Every chiplet pays for every other chiplet's fields in wire width, buffering and power.

Most fields are undefined for most roles, so their meaning becomes a convention rather than a contract — and conventions are what §4 is about.

Adding a role changes the type, which changes every chiplet that uses it. The abstraction that was supposed to enable independent evolution prevents it.

And the correct unit of reuse is a semantic contract per role (19.6): a memory-side interface, a bridge interface, an IO interface — each narrow, each fully defined, each independently versioned. Reuse comes from the roles being stable, not from one type covering all of them.

19. Common Misconceptions

"UCIe makes chiplets plug-and-play." §4: both sides can conform at the wire and disagree on protocol, management, reset, power, security and version.

"A standard PHY standardises the SoC." §5: the transport contract is one column; the integration contract has several.

"Vendor-independent chiplets eliminate integration verification." §15: they make it harder, because no shared assumption is safe and each side's model must be independent.

"All chiplets can share one universal transaction type." §18: everyone pays for everyone's fields, most are undefined for most roles, and adding a role breaks all users.

"Security comes automatically with standardisation." §12: a standard interface between independently sourced dies makes the boundary a trust boundary — that is a new requirement, not a provided solution.

"Future roadmap announcements are shipping evidence." 22.1 §5: roadmap is Level C. This chapter asserts no timeline at all.

"Chiplet reuse means parameterising one RTL block." §18, 19.6: reuse is a stable semantic contract plus collateral, not a wider parameter list.

"Version negotiation should choose the highest number." §10: both sides then agree on a version one of them cannot honour. min, always.

"More chiplets always improve yield and cost." Each split adds interfaces, package complexity, test cost and integration risk; the tradeoff has an optimum and it is not "more".

"The package network is the only bottleneck." 22.3 §9: memory service, the consumer, the external network and the software scheduler are all candidates.

20. Understanding Check

21. Module 22 Complete

And the through-line is one sentence. Every chapter asked what does this evidence actually establish — of a press release, a test chip, a roadmap, a topology, a benchmark, a conformance pass. The answer was consistently narrower than the claim being made, and knowing the gap is the transferable skill.

On the record itself, honestly: across five chapters and every source I could reach, no shipping product's die-to-die links are established as UCIe. What is established is a maintained specification, a cross-foundry test chip, a stated vendor intent, an announced optical component with seven ecosystem endorsements, and a broad founding consortium. That is an ecosystem forming, described accurately — and it is a more useful thing to have read than a confident story would have been.