The UCIe Consortium

Chapter 3.3 argued for a single shared die-to-die contract and listed what it must define. It left out the part that determines whether such a contract can exist at all: somebody has to own it. A specification of this kind is not a document that gets written once. It has to be argued into existence among parties with conflicting interests, revised on a cadence, kept precise enough to prevent the compliant-but-incompatible failure of Chapter 3.2, and — critically — kept neutral enough that competitors will build silicon against it.

That is an institutional problem, and this chapter treats it as engineering infrastructure rather than corporate history. The test of whether you have understood it is not whether you can list member companies. It is whether you can explain how a governance decision becomes a line in someone's RTL.

1. Why a Contract Needs an Owner

Consider what Chapter 3.3's specification actually requires on an ongoing basis.

Someone must decide what goes in the mandatory baseline — a decision that raises the cost of entry for every implementer and therefore has real commercial consequences for participants with different product portfolios. Someone must resolve ambiguity, because §11 of Chapter 3.2 showed ambiguity produces compliant-but-incompatible implementations, and ambiguity is only discovered when independent teams implement the text. Someone must decide what a new revision may break, knowing deployed silicon cannot be patched. Someone must define what conformance means, and what claiming it entitles you to say.

None of those are authoring tasks. They are arbitration tasks: decisions among parties who each have a stake in the outcome and who cannot all get what they want. And they recur, because the specification keeps evolving.

A multi-company hardware standard needs governance because independently shipped silicon must stay compatible across companies and across time — and neither happens without someone empowered to decide.

2. Why One Company Cannot Credibly Own It

This deserves care, because the point is structural rather than a criticism of any company.

A vendor-controlled interface can be technically excellent — Chapter 3.1 established exactly that, and a company that has built several generations of die-to-die links has expertise a new committee lacks. The difficulty is not competence. It is dependency.

If one company controls the specification, then for everyone else: revision direction is set by a party whose roadmap may not match theirs; the controlling vendor has earlier and better knowledge of coming changes; features that matter to its product family are likely to be prioritised over features that matter to yours; and continued access rests on a relationship that can change.

Now weigh that against what adoption costs. Building a die against an interface is a multi-year commitment with mask costs, verification programmes, and product plans attached. A competitor asked to make that commitment against a specification a rival controls is being asked to accept a strategic dependency, not just a technical one — and will reasonably decline or hedge.

Neutral governance is what removes that objection. It does not make the specification better; it makes it adoptable by parties who compete with each other. That is a different property, and for an ecosystem standard it is the binding one.

Note the honest corollary: this is why Chapter 3.1's AIB example is not simply a story about openness. Intel made AIB royalty-free and contributed it to CHIPS Alliance — genuinely opening it. But openness of licensing is not the same as neutrality of governance, and neither is the same as covering the full stack of agreement. Ecosystem standards need all three.

3. What the UCIe Consortium Is

The factual layer. Everything in this section was verified against the Consortium's own published material rather than recalled — see the note at the end of the section.

The UCIe (Universal Chiplet Interconnect Express) Consortium was formed in 2022 by a group of semiconductor, packaging, foundry, and cloud companies, and incorporated as a formal organisation later that year, at which point it opened for broader membership. It describes its purpose as building an open ecosystem of chiplets for on-package innovations.

Its membership is tiered, and the tier names are worth knowing because they map onto the arbitration problem in §1:

The Promoter members listed by the Consortium span the disciplines the standard has to satisfy — semiconductor vendors, IP suppliers, foundries, packaging and assembly, and cloud and platform operators: AMD, Alibaba Cloud, Arm, ASE, Google Cloud, Intel, Meta, Microsoft, NVIDIA, Qualcomm, Samsung, and TSMC.

That composition is the substantive point, not the names. A die-to-die standard has to be simultaneously implementable in silicon, manufacturable by foundries, assemblable in real packages, and useful to the platform operators who buy the resulting systems. A specification written only by chip designers would under-constrain packaging; one written only by packaging houses would under-constrain protocol behaviour. The membership composition is a structural answer to the four-layer problem of Chapter 3.2 — each layer needs someone in the room who has to live with the decision.

The specification has moved through several revisions since the organisation formed — 1.0, then 1.1, then 2.0, and currently 3.0 — with 2.0 notably adding manageability and 3D packaging support. What each revision contains belongs to later modules; what matters here is the cadence, which is roughly annual and which tells you something important: this is a live specification with an ongoing revision process, not a document that was published once.

Source note: membership tiers, the Promoter list, the current specification revision, and the Consortium's stated purpose were taken from the UCIe Consortium's own website; the formation and incorporation timeline and the 2.0 revision content from the Consortium's own announcements. Membership lists and revision status change over time — treat the specific names and version above as current-as-published rather than permanent, and check the Consortium directly for anything load-bearing.

4. How a Governance Decision Reaches Your RTL

This is the section that makes the chapter matter to an engineer, and the causal chain is short.

A working group identifies a need — a capability the specification lacks, or an ambiguity that produced incompatible implementations. A proposal is developed and evaluated by members. If accepted, it appears in a specification revision. Implementers then adopt that revision, and compatibility with earlier revisions becomes a question the specification has to have answered.

By the time it reaches you, that decision has become:

• A mandatory behaviour your design must implement to claim conformance.
• An optional capability you must decide whether to build — a cost/benefit judgement with interoperability consequences.
• A revision number your design must report, and must interpret from a partner.
• A compatibility expectation about how you must behave toward an older or newer partner.
• A deprecated behaviour you must stop relying on, or must continue to support for existing partners.
• A test requirement your verification plan has to cover.

Those flow directly into RTL, verification plans, firmware, and compliance activity. Which yields the takeaway:

Standards governance ultimately becomes design requirements. A decision made in a working group is, eventually, a line you have to write.

Where revision compatibility is concerned, the shape of that requirement is worth seeing even though the actual rules come from the specification:

// Illustrative compatibility logic — NOT UCIe normative behaviour.
// Real revision-compatibility rules are defined by the specification;
// this only shows the shape such a check takes in hardware.
localparam logic [7:0] LOCAL_MAJOR = 8'd3;
localparam logic [7:0] LOCAL_MINOR = 8'd0;
 
logic [7:0] remote_major_q, remote_minor_q;   // captured during bring-up
logic       revision_compatible;
 
assign revision_compatible =
    (remote_major_q == LOCAL_MAJOR) &&
    (remote_minor_q <= LOCAL_MINOR);

Three things to take from it, and the third is the important one.

There is state. Revision information from the partner has to be captured during bring-up and held, which means bring-up must include an exchange for it — connecting straight back to Chapter 3.2's point that reset and bring-up are part of the contract.

There is a policy encoded in comparison. The expression above happens to say "same major, and minor no newer than mine" — a plausible policy and entirely an invention of this example. Whether a newer minor revision must be tolerated, whether major revisions can interoperate at a reduced capability, and what happens on mismatch are all specification decisions, and getting them from anywhere other than the specification is how an implementation becomes silently incompatible.

The check must gate something. A compatibility result nobody acts on is decoration. In practice it feeds the same kind of guard as Chapter 3.2's capability intersection:

// Illustrative property: do not operate a link across an
// incompatible revision pairing.
property p_no_enable_on_incompatible_revision;
  @(posedge clk) disable iff (!rst_n)
    link_enable |-> revision_compatible;
endproperty
assert property (p_no_enable_on_incompatible_revision);

That is deliberately all the code this chapter contains. A governance chapter does not need more, and padding it with RTL would misrepresent what the subject is.

5. Membership, Compliance, and Interoperability Are Three Things

A distinction worth being strict about, because the three are routinely conflated in marketing and they mean genuinely different things.

Membership is an organisational relationship: a company has joined the Consortium at some tier, giving it defined participation rights. It is a statement about the company, not about any product. A member may ship no UCIe silicon at all.

Compliance is a claim about a specific implementation: that it conforms to the behaviour the specification defines. It is about a product, evaluated against a document.

Interoperability is a claim about a pairing: that this implementation works with an independently developed one. Chapter 3.2 showed exactly why this does not follow automatically from compliance — where the specification permits two readings, two implementations can each be compliant with different readings and fail to work together.

The dependency runs one way and imperfectly: membership does not imply compliance; compliance is intended to predict interoperability and does so only as well as the specification is precise. Which is why precision in specification work is not pedantry — it is the mechanism by which compliance becomes a useful proxy for interoperability, and it is why interoperability activity exists as something separate from conformance checking.

6. Common Misconceptions

7. Understanding Check

8. Summary and What Comes Next

A shared contract needs an owner because the work is ongoing arbitration: setting the mandatory baseline, resolving ambiguity that only independent implementation reveals, deciding what a revision may break when deployed silicon cannot be patched, and defining what conformance means. Those are decisions among parties with competing interests, and they recur.

One company cannot credibly own it — not for lack of competence, but because adoption means accepting a strategic dependency on a party whose roadmap, information advantage, and priorities differ from yours, in exchange for a multi-year silicon commitment. Neutral governance does not improve the specification; it makes it adoptable by competitors, which is the property an ecosystem standard actually needs.

The UCIe Consortium was formed in 2022 and incorporated later that year, with a tiered Promoter / Contributor / Adopter membership; its Promoter tier deliberately spans semiconductor vendors, IP suppliers, foundries, packaging and assembly, and cloud and platform operators — a structural answer to the fact that a die-to-die standard must be implementable, manufacturable, assemblable, and useful all at once. The specification has moved through 1.0, 1.1, 2.0, and currently 3.0 on a roughly annual cadence, which marks it as a live process rather than a published artefact.

For engineers, the chain is short: governance decisions become design requirements — mandatory behaviours, optional capabilities, revision numbers to report and interpret, compatibility expectations, deprecations, and test requirements. And three claims must be kept apart: membership is about a company, compliance is about an implementation, and interoperability is about a pairing — with compliance predicting interoperability only as well as the specification is precise.

Module 3 has now covered why proprietary links could not become a foundation, what interoperability actually demands, why a shared contract is the only thing that scales, and who keeps that contract neutral and evolvable. One question remains before the curriculum turns to UCIe's architecture itself:

• 3.5 — The Ecosystem Vision — what kind of chiplet ecosystem all of this machinery is meant to enable, and what has to be true for it to work.

Browse the full path on the UCIe tutorials index.