Open Chiplet Ecosystems

Module 23 kept arriving at the same deciding variable: whether a boundary crosses an organisation. Module 24 takes that variable as its subject — starting with the question of who would have to agree to what.

1. The One-Sentence Model

An open chiplet ecosystem is not a technology — it is a set of roles, and a set of things each role must publish. A standard die-to-die link makes the boundary implementable by strangers. It does not make anyone willing to be the stranger — and the reasons are commercial, contractual and organisational at least as much as technical.

So the question this chapter asks is not "is the technology ready?" It is: when a die arrives from a supplier you have never worked with, what exactly did you buy, what did they publish, and who is responsible when the package does not work? §16 is that last question, and it is the one with the weakest answer.

2. What This Chapter Owns

22.5 established what must be agreed. This chapter is about who agrees, what they publish, and who is liable — a different subject, and deliberately a more accessible one:

The five roles (§4–§6) and the specific artefact each must produce.

What an integrator is actually buying (§7–§8) — which turns out to be far more than a die, and the gap between those two is where most of the difficulty lives.

And failure attribution (§16). When a two-supplier package does not work, the technical question of which die is hard and the contractual question of whose problem it is is harder — and no specification addresses it.

3. Sourcing

4. Five Roles

A vertically integrated product has one organisation doing all of this. An ecosystem splits it — and every split is a place an agreement must exist.

Three properties.

Only the integrator is accountable for the whole, and the integrator is frequently the party with the least visibility into any individual die (§7). That asymmetry is the ecosystem's central structural problem.

The standards body's role is narrower than people assume. It establishes that conforming implementations can interoperate — 20.7 — not that any two will, and not anything about the six non-transport agreements of 22.5 §5.

And the foundry is not a party to the die's behaviour at all. A die can be manufacturable and unintegrable; process and protocol are unrelated concerns.

5. The Ecosystem, Drawn

Three things to read.

Everything converges on the integrator, who owns the product and has the least visibility into any individual die.

The standards body reaches the suppliers and the integrator but not the product. It defines the boundary; it does not certify that a particular composition works (20.7).

And the muted path is the chapter's hardest section (§16). When the package does not work, something must flow back — and no specification defines what.

6. What a Supplier Must Publish

A die alone is not a purchasable component. This is the list, and most of it is not standardised by anything.

Three readings.

One row is standardised and ten are not. That ratio is the state of the ecosystem — and it is why "the standard exists, so the ecosystem can happen" does not follow.

Row 7 is the load-bearing one and the least likely to be supplied (22.5 §14). Without an independent reference model, an integrator can only check that a die agrees with itself — and two dies sharing a misinterpretation agree perfectly (21.6 §24).

And row 10 is the one a purchasing department asks about first. "How long will this be supported, and what is known-broken?" is a normal component question with no chiplet-specific answer yet.

7. What an Integrator Is Actually Buying

And the gap between the two columns is where integration risk lives. 23.2 §13's hidden assumption is the failure mode: an agreement that exists, matters, and was never written down — except now the two parties cannot even convene a design review to recover it.

8. Why the Marketplace Analogy Breaks

"Chiplet marketplace" invites a comparison with buying a component from a catalogue. Four ways it does not hold:

Two readings.

Row 1 is the deepest difference. A resistor's behaviour is complete in isolation. A chiplet's behaviour is only defined relative to a peer, so "does it work?" is not a question about the die.

And row 3 kills the substitutability that makes a marketplace valuable. 23.2 §10's P term: testing is proportional to pairings shipped, so a catalogue of N interchangeable chiplets is not what an integrator gets — they get N candidates, each needing verification against their specific composition.

9. Why Anyone Would Do This Anyway

The pressures are real, and they are the reason the question keeps being asked.

And rows 3 and 5 are the ones that make an ecosystem economically plausible rather than merely desirable. A specialised die is expensive to build once per integrator and cheap to build once per industry — 23.2 §10's linear-versus-quadratic argument, seen from the supply side.

10. Illustrative — a Machine-Readable Chiplet Descriptor

// ILLUSTRATIVE ONLY. §6's list, expressed as a machine-readable record. The
// point is not the encoding — it is that EVERY ROW of §6 needs a field, and
// a descriptor missing a row leaves that agreement implicit (23.2 §13).
typedef struct packed {
  // WHO
  logic [15:0] vendor_id;
  logic [15:0] part_id;
  logic [7:0]  silicon_revision;
 
  // LINK CONFORMANCE — the one row that is partly standardised (§6)
  logic [7:0]  link_spec_major;
  logic [7:0]  link_spec_minor;
  logic [7:0]  link_mode_caps;        // symbolic classes, not UCIe values (§3)
 
  // PROTOCOL SEMANTICS
  logic [15:0] protocol_caps;         // what it can carry
  logic [15:0] protocol_required;     // what it REQUIRES the peer to accept
  logic        adapter_reliability;   // does it rely on the adapter's retry?
  logic [7:0]  ordering_domains;
 
  // MANAGEMENT / RESET — 22.5 §7's deadlock, as fields
  logic [7:0]  mgmt_version;
  logic        reset_is_initiator;
  logic [15:0] reset_ready_timeout;
 
  // POWER
  logic [7:0]  power_state_caps;
  logic [15:0] power_seq_constraints;
 
  // SECURITY POSTURE — a REQUIREMENT statement, not a guarantee (22.5 §12)
  logic [7:0]  security_profile;
  logic        requires_peer_attestation;
 
  // LIFECYCLE — the row a purchasing department asks about first (§6)
  logic [15:0] errata_revision;
  logic [15:0] support_horizon_quarters;
 
  // COLLATERAL — what the supplier actually shipped (§15)
  logic        has_reference_model;
  logic        has_interface_monitor;
  logic        has_coverage_model;
} chiplet_descriptor_t;

Architecture. One record per purchasable die, structured by §6's list, so a missing agreement is a missing field rather than an unasked question.

State. A constant per die; the integrator holds one per candidate.

Cycle/event behaviour. Consumed at design time by an integrator's compatibility check (§11) and at bring-up by the negotiation (22.5 §8).

Contract. The three has_* fields at the bottom are unusual and deliberate: they describe what the supplier shipped, not what the die does. An integrator needs to know whether a reference model exists before committing to a die, because its absence changes the verification plan entirely (§15).

Failure. A descriptor covering only the link rows is §12 — and it is the shape a supplier naturally produces, because the link is the part with a specification to point at.

DV/debug. Both descriptors belong in a debug snapshot (21.7 §9). In an interoperability matrix, the failing pairing is usually distinguished by exactly one field — and §16's attribution problem is far more tractable when both descriptors are on the table.

11. Illustrative — the Integrator's Compatibility Check

// ILLUSTRATIVE ONLY (§10). What an integrator would run BEFORE committing to
// a pairing — with a distinct reason for every way it can fail, because
// "incompatible" is not a finding (22.1 §22).
typedef enum {
  COMPAT_OK,
  INCOMPAT_LINK_REVISION,
  INCOMPAT_PROTOCOL,
  INCOMPAT_RELIABILITY_OWNER,
  INCOMPAT_RESET_BOTH_INITIATOR,
  INCOMPAT_POWER_STATES,
  INCOMPAT_SECURITY,
  RISK_NO_REFERENCE_MODEL,
  RISK_SUPPORT_HORIZON
} compat_result_e;
 
function automatic compat_result_e check_pair(chiplet_descriptor_t a,
                                              chiplet_descriptor_t b);
  // Revision: agree the MINIMUM. Neither may assume the peer implements more
  // than it advertised (22.5 §10 — `max` is the classic bug here).
  if (min_revision(a, b) < REQUIRED_MIN_REVISION) return INCOMPAT_LINK_REVISION;
 
  // Capability INTERSECTION, never union.
  if ((a.protocol_caps & b.protocol_required) != b.protocol_required)
    return INCOMPAT_PROTOCOL;
  if ((b.protocol_caps & a.protocol_required) != a.protocol_required)
    return INCOMPAT_PROTOCOL;
 
  // Who owns reliability must AGREE. One side relying on the adapter's retry
  // while the other runs raw is 22.2 §13's silent unprotected link.
  if (a.adapter_reliability != b.adapter_reliability)
    return INCOMPAT_RELIABILITY_OWNER;
 
  // 22.5 §4's deadlock, caught as a field comparison rather than at bring-up.
  if (a.reset_is_initiator && b.reset_is_initiator)
    return INCOMPAT_RESET_BOTH_INITIATOR;
 
  if ((a.power_state_caps & b.power_state_caps) == '0) return INCOMPAT_POWER_STATES;
  if (a.requires_peer_attestation && (b.security_profile == '0))
    return INCOMPAT_SECURITY;
 
  // RISKS are not incompatibilities — they change the PLAN, not the answer.
  if (!a.has_reference_model || !b.has_reference_model)
    return RISK_NO_REFERENCE_MODEL;
  if (min_horizon(a, b) < REQUIRED_HORIZON) return RISK_SUPPORT_HORIZON;
 
  return COMPAT_OK;
endfunction

Architecture. A design-time check over two descriptors, with incompatibilities and risks distinguished — because they lead to different decisions.

State. None; a pure function of two records.

Cycle/event behaviour. Run at selection time, long before silicon.

Contract. Revision uses the minimum; capabilities use intersection. 22.5 §10's max bug is the canonical error, and it is symmetric — both sides compute the same wrong answer, which is what makes it feel correct.

Failure. Returning a single boolean collapses eight distinct findings into one symptom, so the integrator learns that a pairing does not work and not why — which is 22.1 §22's argument and directly worsens §16's attribution problem.

DV/debug. The two RISK_* results are the ones worth dwelling on: they do not block the pairing, they change the verification plan and the commercial terms. A pairing with no reference model on either side is buildable and is a different project (§15).

12. Wrong — the Link-Only Datasheet

// WRONG — a descriptor covering only the standardised row. It is what a
// supplier naturally produces, because the link is the part with a
// specification to point at.
typedef struct packed {
  logic [15:0] vendor_id;
  logic [7:0]  link_spec_major;
  logic [7:0]  link_spec_minor;
  logic [7:0]  link_mode_caps;
} link_only_descriptor_t;

What every omitted field costs:

Three properties.

The descriptor is accurate. Every field in it is true. It is the absence that causes the failures, and absence is invisible in review unless the expected list exists (§6).

It passes link conformance testing, because link conformance is exactly what it describes — which is 20.7's point: conformance to a boundary specification is not integrability.

And this is 23.2 §13's hidden assumption in ecosystem form — except worse, because the two parties are different companies and cannot convene the design review that would recover the missing agreement.

13. Assertions

// MANDATORY. Illustrative architectural properties (§3) — not normative.
 
// (1) THE NEGOTIATED CONFIGURATION IS WITHIN BOTH DESCRIPTORS.
// English: whatever the link agrees at bring-up must be something BOTH dies
// declared. Fires when negotiation produces a mode one side never claimed —
// the runtime symptom of 22.5 §10's `max` bug.
a_agreed_within_both_declared: assert property (
  @(posedge clk) disable iff (!rst_n)
    negotiation_done
      |-> ((agreed_mode & local_desc.link_mode_caps) == agreed_mode)
       && ((agreed_mode & peer_desc.link_mode_caps)  == agreed_mode)
);
 
// (2) RELIABILITY OWNERSHIP IS AGREED BEFORE TRAFFIC.
// English: both sides agree who provides integrity, before anything is sent.
// Catches §12's unprotected link at bring-up rather than at corruption.
a_reliability_owner_agreed: assert property (
  @(posedge clk) disable iff (!rst_n)
    traffic_enabled
      |-> (local_desc.adapter_reliability == peer_desc.adapter_reliability)
);
 
// (3) EXACTLY ONE RESET INITIATOR.
// English: of the two dies, exactly one initiates. Catches 22.5 §4's mutual
// wait as a checkable condition instead of a silent hang.
a_exactly_one_initiator: assert property (
  @(posedge clk) disable iff (!rst_n)
    bringup_start
      |-> (local_desc.reset_is_initiator ^ peer_desc.reset_is_initiator)
);
 
// (4) DESCRIPTORS ARE STABLE WHILE THE LINK IS LIVE.
// English: a die may not change what it advertises mid-agreement.
// 21.6 §27's illegal configuration mutation, at descriptor level.
a_descriptor_stable_while_live: assert property (
  @(posedge clk) disable iff (!rst_n)
    (link_live && $changed({local_desc, peer_desc})) |-> in_quiesce
);

Architecture. Four properties turning §6's agreements into checkable conditions.

State. The two descriptor registers and the negotiated configuration.

Sampled timing. Properties (1)–(3) sample at specific lifecycle events — negotiation completion, traffic enable, bring-up start — rather than every cycle, because that is when the conditions are meaningful. Sampling (3) continuously would fire before either descriptor is loaded.

Contract. Property (3) is an exclusive-or, deliberately: both-initiator deadlocks and neither-initiator also deadlocks. A design checking only the both-case leaves half the failure uncovered.

Failure if omitted. Without (2), §12's unprotected link ships and the first symptom is data corruption with a legal protocol trace (21.7 §32's physical-suspicion signature, produced by a configuration error).

DV/debug. These are also the right silicon registers (21.7 §9). In §16's attribution argument, a snapshot showing both descriptors and the agreed configuration is the single most useful artefact either party can produce.

14. What Exists Today, and What Is Argued

Separating observation from analysis, because this is a Foundation chapter and the distinction is the skill.

Three readings.

The top four rows are real and dated. An ecosystem is forming, and describing that accurately is more useful than either enthusiasm or dismissal.

The middle four are absences in my search, stated as such — not claims that they do not exist (22.1 §29).

And the last row is the honest frame for this chapter. The roles, artefacts and attribution problems are derived from what an ecosystem structurally requires, not observed in operation. That is legitimate analysis and it is Level E, and saying so is the difference between a useful chapter and a confident one.

15. Verification Becomes a Shared Problem

Two readings.

Row 1 is the requirement most often skipped. If the integrator uses the supplier's model to check the supplier's die, a shared misinterpretation is invisible — the model and the die agree by construction.

And row 5 is 20.7's finding, which matters more here than anywhere: compliance testing validates a device against a known-good reference implementation. That establishes conformance to the reference. It does not establish that two arbitrary conforming dies will integrate, because 22.5 §5's six non-transport layers were never in scope.

16. Failure Attribution

The hardest unsolved problem, and it is not technical.

A package containing dies from two suppliers does not work. Now what?

Four readings.

The technical difficulty is already understood (21.6, 21.7): a violation claim needs a rule, a revision, a mode, a trigger, an observation, and evidence that no legal exception applies. Module 21 built exactly that discipline.

What is new is that the claim now has a counterparty with an interest in the answer. Inside one company, a violation report starts an investigation. Across companies, it starts a negotiation — and the party with better instrumentation has an advantage unrelated to who is right.

Which makes 21.7's instrumentation a commercial asset, not just an engineering one. A supplier that ships a die with first-fault capture, a trace buffer and readable descriptors can demonstrate its die behaved correctly. One that cannot, cannot — regardless of the truth.

And this is the strongest practical argument in the chapter for 22.5 §14's collateral. A reference model is not only a verification aid; it is the artefact that makes a disagreement resolvable by evidence rather than by whoever argues longest.

17. Common Misconceptions

"The standard exists, so the ecosystem can happen." §6: one row of eleven is standardised. The link is necessary and is the smallest part of what must be published.

"A chiplet is a component like any other." §8: it works only in combination, its datasheet covers one of seven layers, and substitution requires re-verifying the pairing.

"Conformance testing means two conforming dies will work together." §15, 20.7: it validates against a reference, and the six non-transport agreements were never in scope.

"An open ecosystem means less verification." §15: independent models, pairing matrices and cross-company disagreement resolution — more, and distributed across parties who do not share tools.

"Failure attribution is an engineering problem." §16: the engineering part is understood. The unsolved part is who investigates, who pays, what evidence is shared and who arbitrates.

"A supplier's reference model is good enough to verify their die." §15: a shared model hides a shared misinterpretation. Independence is the point.

"Chiplet marketplaces exist today." §3, §14: I found no shipping multi-supplier chiplet product and no operating marketplace — a bounded statement about my search, not a claim that none exists.

"Standardising the link removes the need for a business relationship." §16: it removes the need for a shared specification. It does not remove the need to agree what happens when the package does not work.

18. Understanding Check

19. Summary

Five things.

An ecosystem is roles plus published artefacts (§4, §6), not a technology. One of eleven artefacts is standardised, and the link is the smallest part of what must be agreed.

The integrator owns the whole and sees the least (§5, §7) — a structural asymmetry that no specification addresses.

A chiplet is not a catalogue component (§8). It works only in combination, its datasheet covers one layer of seven, and substitution requires re-verifying the pairing.

Verification becomes distributed and independence becomes mandatory (§15). A shared model hides a shared misinterpretation, and conformance validates against a reference rather than against your peer.

And failure attribution is the hardest unsolved part (§16), because the technical question is understood and the questions of who investigates, who pays, what evidence is shared and who arbitrates have no framework — which is why instrumentation and collateral are commercial assets, not just engineering ones.

On evidence: an ecosystem is forming — a maintained specification, a broad consortium, demonstrated cross-foundry interoperability, announced independent components. I found no shipping multi-supplier chiplet product and no operating marketplace, and §14 separates what is observed from what this chapter argues.