Intel Meteor Lake Case Study

26.1 read an architecture that disaggregates by replication. This one disaggregates by function — and almost every conclusion changes.

1. The One-Sentence Model

Meteor Lake splits a client SoC into four dissimilar tiles — compute, graphics, SoC and I/O — stacked on a base die by 3D packaging, so each function can sit on the process that suits it and the parts that must stay awake can be separated from the parts that should sleep.

Two things make this a different chapter from 26.1. The dies are not alike, so there is no "add another one" scaling knob — the partition is a functional decision. And the packaging is 3D rather than side-by-side, which changes the cost of a die boundary and therefore changes which boundaries are worth having at all (25.2 §7).

2. What This Chapter Owns

22.1 covered Intel's relationship with the standard. This chapter covers one architecture — and it owns four things the curriculum has not yet examined in a real product:

Functional partition (§6–§7) — what happens when the dies are all different, and what that costs.

3D packaging as an architectural input (§8) — why the base die changes the calculus rather than merely the assembly.

Power-state contracts (§9–§12) — the hardest boundary contracts here are not about data at all, and this is the chapter that says so.

And the two-architecture synthesis (§16) — 26.1 and this chapter as two answers to different pressures, which is Module 26's actual point.

3. Sourcing

4. Claim-vs-Evidence

Four readings.

Rows 1–6 are the architecture, and they are solid enough to reason from. The decomposition and the packaging approach are Intel-stated; that is all §6–§9's analysis needs.

Row 7 is the most architecturally interesting and the weakest-evidenced. Intel describes the intent — an SoC tile that lets the machine do useful low-power work while the compute tile idles. I take the intent as stated and treat every mechanism as unknown (§3), because the intent alone is enough to derive §10's contract.

Rows 8–10 stay attributed. A secondary number repeated without its source becomes a fact by erosion, which is exactly what 23.1 §13's comparison conditions exist to prevent. §8's argument is written so it does not depend on the specific figures.

And the last row stays empty on purpose. 22.1 §4 established Pike Creek as an interoperability test chip — a genuine, dated, Intel-described milestone, and not a production deployment.

5. The Arrangement

Four things to read.

No two tiles are the same kind of thing. Compare 26.1 §5, where the compute dies are identical. Here every boundary was drawn where one specific function ends — so each boundary needs its own justification, and §7 is that audit.

Everything sits on the base tile. It is drawn as a substrate rather than a peer, because that is the architectural point: the boundaries exist in three dimensions, which changes what they cost (§8).

The SoC tile is the odd one. It is not a single function — it is an aggregate of NPU, media and display, and §9 argues that the aggregation is deliberate and is the most interesting decision in the whole partition.

And there is no scaling knob. You cannot add a fifth compute tile the way 26.1 §6 adds a spoke. Functional disaggregation buys different things, and §6 is the trade.

6. Replication vs Function

Three readings.

Row 3 is where the reuse arguments diverge, and it is subtle. Replication reuses a die across products in one generation — one CCD, many SKUs. Functional partition reuses a tile across generations — an I/O tile whose interfaces are stable can survive a compute-tile node transition unchanged. Both are 25.2 §8's reuse argument, on different axes.

Row 4 is the stronger claim for functional partition. 26.1 gets two process choices; functional partition can in principle get one per function — and analogue-heavy I/O, dense cache, and leading-edge logic have genuinely different node preferences (25.2 §5).

And row 7 is the cost nobody puts on a slide. A functional partition is a product-defining decision. Changing it means redrawing boundaries, renegotiating contracts and respinning multiple tiles — so a wrong functional split is far more expensive than a wrong die count (25.10 §5's irreversible rows).

7. Auditing the Partition

Run 25.7 §6's scorecard on each boundary. This is what the framework is for.

Three readings.

Rows 1 and 2 are the textbook-good cuts. Leading-edge logic on one side, mature analogue on the other — that is process affinity doing exactly what 25.2 §5's argument predicts, and it is why "separate the I/O" appears in almost every chiplet architecture including 26.1's hub.

Row 3 is the questionable one, and saying so is the analysis. Graphics and compute share memory, so this boundary carries traffic with real coupling — 25.7 §10's dependency-depth test applies, and this is the boundary where a 3D package's low per-bit cost (§8) matters most.

And row 4 is the one that changes the kind of contract. The other three boundaries are about moving data. This one is about who is awake — which is a class of contract this curriculum has not yet examined, and §10–§12 are it.

8. Why 3D Packaging Changes the Argument

Every chiplet argument in this curriculum has an implicit cost term: what a die crossing costs in energy, latency and bandwidth (25.2 §7). Change that term and the conclusions move.

Three readings.

This is the whole reason Meteor Lake's partition can be functional rather than traffic-driven. A side-by-side organic-substrate boundary makes you cut where traffic is thin. A dense 3D boundary lets you cut where the architecture wants to cut — which is what makes a graphics/compute split (§7 row 3) thinkable at all.

The figures stay attributed (§4 rows 8–9). Secondary reporting gives a bump pitch and a per-bit energy for Foveros; I quote them as reported, and this section's argument holds for any sufficiently dense 3D boundary rather than depending on either number.

And the caution is 24.4 §11's. Cheap crossings do not make partitioning free. Every boundary still needs a contract, an owner, a reset scope, a recovery model and a verification story (25.10 §6) — the physics gets cheaper; the engineering does not.

9. The Low-Power Island

Intel describes the SoC tile as enabling useful low-power operation while the compute tile idles (§4 row 7, Level D — intent as stated, mechanisms unknown). That single architectural intent explains the partition better than any bandwidth argument.

Three readings, and this is the chapter's central idea.

The aggregation is not miscellany — it is a power domain. NPU, media and display look unrelated by function and are tightly related by duty cycle: all three do sustained work while cores should be asleep. That is a partition criterion this curriculum has not used before, and it is a good one.

It also explains a boundary that bandwidth cannot. Nothing about traffic volume says "put the NPU with the display engine". Power state does (25.7 §6's scorecard is broader than its bandwidth row).

And it raises the hard question. If a tile can be powered down while its neighbours run, then "is my peer awake?" becomes a question every transaction implicitly asks — and §10 is what that demands.

10. Power-State Contracts

This is where the framework meets something new. Every contract in Modules 21–25 assumed both sides were powered.

Three readings.

Row 5 is the one that produces silent hangs. If a tile can enter a low-power state while it still owes a response, the requester waits indefinitely and the link looks perfectly healthy — exactly 25.9 §5's pattern where a trained link proves nothing about traffic, with power state as the new hiding place.

Row 4 is 25.3 §14's question in a new domain. Link recovery asked "does my obligation survive?" Power transition asks the same thing about a deeper state change — and the answer must be a stated contract rather than an implementation accident.

And row 3 is the debug requirement. A wake with no timeout and no named error is the worst possible failure mode: it looks like a performance problem for as long as anyone is willing to look. A bounded wake with E_WAKE_TIMEOUT is a five-minute diagnosis (25.9 §11).

11. Wrong RTL — Wake as an Assumption

// WRONG. ILLUSTRATIVE. A plausible mistake: the requester asserts a wake
// request and then issues, trusting that a wake "obviously" completes before
// the transaction arrives. Written by someone whose previous SoC had a single
// always-on power domain, where this was true.
always_ff @(posedge clk or negedge rst_n) begin
  if (!rst_n) begin
    wake_req_q <= 1'b0;
    issue_q    <= 1'b0;
  end else begin
    if (need_peer && !wake_req_q) wake_req_q <= 1'b1;
 
    // BUG 1: issues on the REQUEST, never on an acknowledgement of readiness.
    // BUG 2: no timeout — if the peer never becomes ready, this waits forever
    //        with no error and no evidence.
    // BUG 3: nothing prevents the LOCAL side from dropping wake_req while a
    //        transaction is still outstanding at the peer.
    issue_q <= wake_req_q && txn_pending;
 
    if (!need_peer) wake_req_q <= 1'b0;   // BUG 3, concretely
  end
end

Architecture. A wake request and an issue, with no acknowledgement between them — a request-and-hope boundary.

State. Two flops. The missing state is the whole problem: there is no record of the peer's readiness, so the design cannot distinguish "asked" from "ready".

Event. issue_q rises one cycle after wake_req_q regardless of the peer.

Contract. It violates §10 rows 1, 3 and 5 simultaneously: no shared state, no bounded wake, no obligation guard.

Failure — the timeline.

Root cause. A power-state boundary was treated as a data-flow boundary. valid && ready handshakes protect against a busy peer; they do not protect against an absent one (25.6 §9) — readiness to accept and being powered are different facts, and this RTL has only one signal for both.

DV/debug. The symptom is the worst kind: a hang with a healthy link, no error bit, and a peer that is idle and looks innocent. A 25.9 §12 counter walk finds it immediately — requests issued by the requester will exceed requests observed at the peer, and the first divergence is the cycle the peer was still waking.

12. Corrected — an Explicit Power Handshake

// CORRECT. ILLUSTRATIVE (§11). The power state becomes an explicit, bounded,
// observable protocol: request -> acknowledged-ready -> issue, with a timeout
// that produces a NAMED error, and an obligation guard that prevents sleep
// while anything is owed.
typedef enum logic [2:0] {
  PS_OFF, PS_WAKE_REQ, PS_READY, PS_ACTIVE, PS_SLEEP_REQ, PS_WAKE_FAIL
} pstate_e;
 
pstate_e     pstate_q;
logic [15:0] wake_timer_q;
logic [15:0] owed_q;            // outstanding obligations AT THE PEER
logic [2:0]  last_fail_cause_q;
logic        last_fail_valid_q;
 
always_ff @(posedge clk or negedge rst_n) begin
  if (!rst_n) begin
    pstate_q          <= PS_OFF;
    wake_timer_q      <= '0;
    owed_q            <= '0;
    last_fail_valid_q <= 1'b0;
    last_fail_cause_q <= '0;
  end else begin
    // ONE signed next-state expression, so an issue and a completion in the
    // same cycle net correctly (25.6 §10, 26.1 §12).
    owed_q <= owed_q + 16'(issue_fire) - 16'(complete_fire);
 
    unique case (pstate_q)
      PS_OFF:      if (need_peer) begin
                     pstate_q     <= PS_WAKE_REQ;
                     wake_timer_q <= '0;
                   end
 
      // Bounded, and failure is NAMED rather than silent (§10 row 3).
      PS_WAKE_REQ: if (peer_ready) begin
                     pstate_q <= PS_READY;
                   end else if (wake_timer_q == WAKE_TIMEOUT) begin
                     pstate_q <= PS_WAKE_FAIL;
                     if (!last_fail_valid_q) begin      // sticky FIRST (21.7)
                       last_fail_valid_q <= 1'b1;
                       last_fail_cause_q <= CAUSE_WAKE_TIMEOUT;
                     end
                   end else begin
                     wake_timer_q <= wake_timer_q + 16'd1;
                   end
 
      PS_READY:    pstate_q <= PS_ACTIVE;                // issue permitted here
      PS_ACTIVE:   if (want_sleep) pstate_q <= PS_SLEEP_REQ;
 
      // The obligation guard. Sleep is NOT entered while anything is owed —
      // this is the row-5 failure of §10, made structurally impossible.
      PS_SLEEP_REQ: if (owed_q == '0)      pstate_q <= PS_OFF;
                    else if (!want_sleep)  pstate_q <= PS_ACTIVE;
 
      PS_WAKE_FAIL: if (diag_clear)        pstate_q <= PS_OFF;
      default:                             pstate_q <= PS_WAKE_FAIL;
    endcase
  end
end
 
// Issue is permitted ONLY from an acknowledged-ready state. This is the fix
// for §11's BUG 1, expressed as a property rather than as a comment.
// MANDATORY. English: no transaction is issued unless the peer has
// acknowledged readiness this cycle.
a_no_issue_unless_ready: assert property (
  @(posedge clk) disable iff (!rst_n)
    issue_fire |-> (pstate_q inside {PS_READY, PS_ACTIVE})
);
 
// MANDATORY. English: the boundary never enters a powered-down state while an
// obligation is outstanding at the peer. Catches §11's orphaned response.
a_no_sleep_while_owed: assert property (
  @(posedge clk) disable iff (!rst_n)
    (pstate_q == PS_OFF) |-> (owed_q == '0)
);
 
// MANDATORY. English: a wake attempt always terminates — either the peer
// becomes ready, or a NAMED failure is recorded. Catches the unbounded stall
// that §11's timeline ends in.
a_wake_terminates: assert property (
  @(posedge clk) disable iff (!rst_n)
    (pstate_q == PS_WAKE_REQ) |-> ##[1:WAKE_TIMEOUT+1]
      (pstate_q inside {PS_READY, PS_WAKE_FAIL})
);

Architecture. Six states, one timer, one obligation counter, one sticky first-failure record — the smallest structure that satisfies all six rows of §10.

State. pstate_q is the shared power state; owed_q is the obligation count at the peer, which is the number that makes row 5 enforceable rather than aspirational.

Event. Issue is permitted only from PS_READY/PS_ACTIVE. PS_SLEEP_REQ is a waiting state, not a transition — it is where the obligation guard lives.

Contract. WAKE_TIMEOUT must come from the peer's stated worst-case wake time (25.10 §6's versioned contract), not from measurement. A timeout tuned until it stops firing is a timeout that cannot detect the bug it exists for (21.6 §29).

Failure. The remaining risk is a mutual wake dependency: two tiles each in PS_WAKE_REQ waiting for the other. The timeout bounds it and names it — which is why §10 row 2 asks who may initiate, and why an architecture needs a wake ordering rather than a symmetric one.

DV/debug. last_fail_cause_q sticky-first (21.7 §14) and owed_q readable are the two facts that turn §11's 400-cycle mystery into a register read. CAUSE_WAKE_TIMEOUT plus a non-zero owed_q names both the failure and the boundary.

13. Illustrative — Making the Duty Cycle Observable

// ILLUSTRATIVE (§11). If the whole point of the partition is that compute can
// sleep while the SoC tile works (§9), then the architecture's PRIMARY success
// metric is a duty cycle — and it must be measurable in silicon, not inferred
// from a power meter.
localparam int N_DOMAIN = 4;                    // compute, gfx, soc, io
 
logic [47:0] awake_cycles_q  [N_DOMAIN];
logic [47:0] wake_events_q   [N_DOMAIN];
logic [31:0] wake_lat_max_q  [N_DOMAIN];
logic [47:0] blocked_sleep_q [N_DOMAIN];        // cycles held awake by owed_q
 
always_ff @(posedge clk or negedge rst_n) begin
  for (int d = 0; d < N_DOMAIN; d++) begin
    if (!rst_n || diag_clear) begin
      awake_cycles_q[d]  <= '0;
      wake_events_q[d]   <= '0;
      wake_lat_max_q[d]  <= '0;
      blocked_sleep_q[d] <= '0;
    end else begin
      if (domain_awake[d])   awake_cycles_q[d] <= awake_cycles_q[d] + 48'd1;
      if (wake_edge[d])      wake_events_q[d]  <= wake_events_q[d]  + 48'd1;
      if (wake_done[d] && (wake_latency[d] > wake_lat_max_q[d]))
        wake_lat_max_q[d] <= wake_latency[d];
      // The diagnostic that names §12's guard as the cause of lost sleep.
      if (want_sleep_d[d] && !domain_asleep[d]) blocked_sleep_q[d] <= blocked_sleep_q[d] + 48'd1;
    end
  end
end

Architecture. Four numbers per power domain: time awake, wake count, worst wake latency, and cycles that wanted sleep but could not have it.

State. Sixteen counters. Cheap, and they answer the only question this architecture's premise raises.

Event. blocked_sleep_q counts while sleep is requested and not achieved — which distinguishes "nothing wanted to sleep" from "something prevented it".

Contract. wake_lat_max is the number that validates or refutes WAKE_TIMEOUT (§12). A measured maximum near the timeout is a contract that is about to be violated in the field.

Failure. Without blocked_sleep_q, a residency regression looks like a software problem. With it, §12's obligation guard becomes visible as the cause — and then the question becomes why is something always owed, which is answerable.

DV/debug. wake_events high with awake_cycles low is thrash: waking and sleeping repeatedly, paying wake energy without doing work. That is a real product bug that no functional test fails, and it is invisible without these counters.

14. Why This Is Not a UCIe Deployment

Three statements, each bounded.

Meteor Lake's tile-to-tile interfaces are not established as UCIe (§3, §4). Intel's UCIe interoperability milestone is Pike Creek, described by Intel as the world's first UCIe interoperability test chip — Intel UCIe IP on Intel 3 with Synopsys UCIe IP on TSMC N3, at Intel Innovation 2023 (22.1 §4). A test chip and a proof point, with no production claim.

A chiplet product is not evidence of UCIe (22.1 §12). This architecture is a strong demonstration of disaggregation, and disaggregation predates the standard by years.

And Pike Creek is worth more than a product claim would be (22.1 §31). What UCIe promises is interoperability across vendors and process nodes (23.2 §9). Two independent IP implementations on two different companies' processes interoperating is a direct test of exactly that promise — which is a more meaningful data point about the standard than one vendor's internal tile boundary would be.

And the honest position on internal boundaries (23.2 §8): tiles designed together, by one company, on one schedule, in one package are precisely where co-design wins and a standard's decisive advantages are absent. A candidate who says that has understood the trade.

15. What the Public Record Cannot Tell You

And the point stands from 26.1 §19: the framework tells you what to ask even where the answer is not public. Naming the state-retention question about a power boundary in a documented architecture is understanding the documentation does not contain.

16. Two Architectures, One Framework

Four readings, and this is Module 26's actual thesis.

There is no general chiplet architecture. Two of the industry's most sophisticated products reached opposite partitions — and both are right, because the pressures differ. A server part optimises core count and memory uniformity; a client part optimises power and battery. 25.7 §6's scorecard is the same; the inputs are not.

Row 5 is the most useful row in the table. The hardest contract is not the same in both. Coherent traffic on one; who is awake on the other. An engineer who assumes the hard problem is always bandwidth will miss the actual risk in half the architectures they see.

Row 9 is the row to keep saying out loud. Neither is established as a UCIe deployment — and that has not made either one less instructive. The framework reads architectures; it does not require them to use a particular link.

And the framework survived contact with both. Boundary contracts, ownership, dependency depth, retention across state change, observability, first-divergence debug — every one applied to both architectures without modification, which is the only real test a framework gets.

17. Common Misconceptions

"Meteor Lake uses UCIe." §3, §14: not established. Intel's UCIe interoperability milestone is Pike Creek, an interoperability test chip (22.1 §4).

"Chiplets means one design pattern." §16: EPYC replicates and centralises; Meteor Lake splits by function and duty cycle. Opposite partitions, both sound.

"Disaggregation is mainly about yield." §7, §9: yield is real (25.2 §4), but here the decisive criteria are process affinity per function and power.

"The SoC tile is where the leftovers went." §9: NPU, media and display share a duty cycle — sustained work while cores sleep. The aggregation is a power domain, not a junk drawer.

"3D packaging just makes assembly denser." §8: it changes what a crossing costs, which changes where you are willing to cut — a partitioning input, not an assembly detail.

"A valid && ready handshake protects the boundary." §11: it protects against a busy peer, not an absent one. Readiness to accept and being powered are different facts.

"Power management is a firmware concern." §10, §12: obligation-survival across a power transition is a hardware contract — owed_q is why sleep is refusable at all.

"The secondary bump-pitch and pJ/bit numbers are established." §3, §4: Level D, attributed — and §8's argument is written not to depend on them.

18. Understanding Check

19. Summary

Five things.

Four dissimilar tiles on a base die (§5): compute, graphics, SoC, I/O — disaggregation by function, not replication, so there is no scaling knob and the partition is product-defining.

3D packaging is an architectural input (§8). Cheaper crossings let you cut where the function boundary is rather than where traffic is thin — and every boundary still needs a contract, an owner and a recovery model.

The SoC tile is a power domain, not a miscellany (§9). NPU, media and display share a duty cycle: sustained work while cores sleep.

Which makes the hardest contract here a power-state contract (§10–§12) — bounded wake, named timeout, and no sleep while an obligation is owed. 26.1's hardest contract was coherent traffic. They are not the same problem.

And neither architecture is established as a UCIe deployment (§14, §16) — which has not made either less instructive, because the framework reads architectures rather than links.