2.5D Packaging

Three chapters have each described a physical structure. An organic substrate is a coarse routing fabric that every package needs anyway. A silicon interposer moves routing into a semiconductor-patterned medium across a broad area. An embedded bridge does the same thing locally, where it is needed, and nowhere else.

This chapter is not a fourth structure. It is the architecture that uses them — the design problem you actually face when several active dies sit side by side in one package and have to behave like one system. That problem is not "which packaging technology should we buy". It is a simultaneous decision about traffic, geometry, bandwidth, power, heat, configuration, and verification, in which every one of those constrains the others. Getting it right is the difference between a chiplet product and a collection of dies that happen to share a substrate.

This is the chapter where the whole module becomes usable.

1. What 2.5D Actually Means

2.5D integration keeps active dies side by side while using an intermediate high-density package fabric to make them behave like one tightly integrated system.

Both halves matter, and the second is the one people drop.

"Multiple dies in one package" has existed for decades — multi-chip modules, system-in-package, memory and logic sharing a substrate. What distinguishes 2.5D is the integration fabric: an intermediate structure dense enough that die-to-die connection stops being a peripheral interface and starts being an architectural resource, wide enough and short enough to carry the kind of traffic that used to be internal to a die.

So the useful taxonomy, with its honest caveat:

2. A System to Reason About

Everything below refers to one hypothetical package, so the reasoning stays concrete:

• Compute 0 and Compute 1 — general-purpose compute chiplets, coherent with each other and with memory.
• System / I/O die — external interfaces, platform functions, and the fabric that ties the package together.
• Accelerator — a domain-specific engine with high operand bandwidth and looser latency tolerance.
• Memory A and Memory B — high-bandwidth memory structures placed in-package.
• Package fabric — interposer, bridges, or both, plus the organic substrate underneath.

This is a plausible shape, not a product. The point is that every architectural decision in the rest of the chapter can be traced to a specific pair of dies in it.

3. Start With the Graph, Not the Floorplan

The most common process failure in 2.5D design is starting from a package drawing. The correct starting point is the traffic graph: who talks to whom, and with what character.

Read that table as an architecture brief, because it is one. It says: memory adjacency matters more than anything else for both compute and the accelerator. Compute-to-compute is small but latency-critical, so it wants a short direct path even though it needs few lanes. Accelerator-to-memory needs enormous width but will tolerate depth, so it can absorb pipelining that compute coherence cannot.

Characterise every edge before placing anything. Bandwidth alone is not enough — an edge that is wide and latency-tolerant and an edge that is narrow and latency-critical want completely different physical treatment, and confusing them produces a floorplan that is defensible on a spreadsheet and wrong in silicon.

This is the same analysis the System Partitioning chapter used to decide where to cut. Now it decides where to place, which is the same information used twice.

4. Floorplanning Is Graph Embedding

Here is the chapter's central mental model.

2.5D package design is, in large part, the problem of embedding a communication graph into physical geometry.

You have a graph with weighted, characterised edges. You have a plane, dies with finite perimeter, a fabric with finite routing resource, and a thermal and power envelope. Embedding means assigning positions such that heavily weighted edges become short and directly connected, while the total demand on every shared resource stays inside what exists.

That framing immediately explains why the problem is hard:

• A plane has limited adjacency. A die has four edges; each edge can face one neighbour well. A vertex with five high-weight edges cannot have all five neighbours adjacent — the graph does not embed, and something must be sacrificed.
• Edges compete. Two long routes crossing the same region consume the same fabric resource. Placement that is locally optimal for one edge can starve another.
• The objective is multi-dimensional. Short routes are good for bandwidth and energy, and bad for heat when both endpoints are hot. The bandwidth-optimal and thermal-optimal embeddings are frequently different.
• Some edges are not negotiable. A latency-critical coherence path that ends up multi-hop may simply miss its performance target, at which point the partition was wrong, not the floorplan.

5. Physical Distance Is Not Logical Distance

Two independent quantities are easy to conflate, and conflating them produces wrong conclusions in both directions:

• Logical distance — how many hops a transaction takes through the system's routing structure.
• Physical distance — how far the signals actually travel through package structures.

They come apart routinely:

• One hop, long route. Two dies at opposite corners of a large package with a direct connection: logically adjacent, physically far. That route is long, lossy, energy-expensive, consumes fabric resource across everything between them, and may not support the per-lane rate a short route would.
• Two hops, short routes. Two dies connected through a central hub, each hop across a facing edge: logically farther, physically much shorter, cheaper per bit — but paying a full store-and-forward traversal in latency and consuming the hub's resources.

Neither is universally better, and the edge character from §3 decides:

• Latency-critical, narrow (coherence) → minimise logical distance. Extra hops are the expensive term; a slightly longer direct route is usually the right trade.
• Bandwidth-hungry, latency-tolerant (accelerator operands) → minimise physical distance and maximise available width. Depth can be pipelined away; missing conductors cannot.

Latency budgets are spent in hops. Bandwidth and energy budgets are spent in millimetres. Optimise the one that the edge actually cares about.

6. Standard Package Versus Advanced Package in UCIe

UCIe defines two physical operating envelopes because package technology genuinely changes the channel, and a single set of electrical assumptions cannot cover both a laminate route across a large package and a micro-bumped route across a bridge.

The values above are as published by the UCIe Consortium and its members; check them against the specification revision you are designing to, because packaging-facing parameters are exactly the kind that move between revisions.

What matters more than the table is the structure of the distinction:

UCIe's two package tracks share the same architecture, the same layering, and the same protocols. What differs is the bump map and PHY organisation — the physical design point — not the stack above it.

That is a deliberate and important property. It means system architecture, validation strategy, and software are reusable across package classes, and it is the practical payoff of the layering discipline Module 5 spent three chapters establishing. It also means the choice is genuinely an architecture choice rather than a lock-in: a design can target a different package class without redesigning its Protocol Layer.

And read the reach numbers together with the lane counts, because they explain each other. The advanced-package track gets four times the lanes per module and an order of magnitude less reach. Those are the same fact: fine pitch and dense routing only exist in a medium that also constrains you to short distances. You are not choosing between "more bandwidth" and "less bandwidth". You are choosing between "wide and short" and "narrower and far", and which one your system can use is decided by the floorplan in §4.

7. Package Assumptions Propagate Upward

A physical package decision does not stay physical. Suppose the available die-to-die bandwidth on an edge comes in below what the architecture assumed:

• Buffers fill more often, because the drain rate is lower than the fill rate more of the time.
• Backpressure propagates further, and Chapter 5.5's analysis applies directly: a full buffer at the link becomes a stall in the fabric, then in the producer.
• Quality-of-service stops being optional. With headroom, arbitration policy barely matters; without it, a fair-looking arbiter can starve latency-critical traffic behind a bulk stream.
• The partition itself may be invalid. If the edge cannot carry what the partition requires, the cut was in the wrong place — and no amount of RTL tuning fixes a cut.

If latency rises instead:

• Coherence round trips cost more, and a protocol that tolerated a short on-die traversal may not tolerate a package traversal plus a hop.
• Outstanding-transaction limits bind sooner, because the bandwidth-delay product grew while the tracking structures did not.
• Tightly coupled partitions miss targets even with adequate bandwidth, because they were coupled by latency, not throughput.

Physical package assumptions are load-bearing for the upper architecture. When they change, re-derive the partition — do not patch the RTL.

8. Budget Bandwidth Symbolically

Do not use invented numbers for this, ever. Use the relationships, then substitute values from your own specification revision, PHY datasheet, and traffic analysis.

For a single link:

B_link = lanes × rate_per_lane × efficiency

where efficiency accounts for everything the payload does not get: protocol and flit overhead, encoding, error-detection fields, and any framing or training the link periodically inserts. Take that factor from the specification revision you are implementing — it is a protocol property, not a constant, and guessing it is how bandwidth plans acquire a comfortable-looking margin that does not exist.

For the system, every physical edge must satisfy:

Σ demand(traffic crossing this edge) ≤ B_link × utilisation_ceiling

Three points people get wrong:

1. Average demand is not the requirement. Traffic is bursty. An edge provisioned for the mean is saturated for a large fraction of real operation, and saturation is where latency stops being linear.
2. The utilisation ceiling is well below one. As offered load approaches capacity, queueing delay grows sharply, so a link "at 95 % capacity" is not 5 % from trouble — it is already in the regime where latency is dominated by queueing rather than transfer. Provision headroom deliberately and write down the number you chose.
3. Simultaneity, not sum. The question is not whether every flow fits on average; it is whether the flows that are simultaneously active fit. Compute-to-memory and accelerator-to-memory both peaking at once through a shared hub is the case that matters, and it never appears in a per-flow spreadsheet.

Then the honest step: write the result down as an architectural assumption, name the edge, name the assumed peak demand, and name the utilisation ceiling. When silicon behaves differently, that document is what makes the difference between diagnosing an architecture and guessing.

9. Describing the Package to the RTL

Chapters 6.2 and 6.3 introduced adjacency and presence separately. A whole 2.5D system needs them together, in one descriptor.

// Illustrative package-to-RTL configuration — not UCIe-defined configuration.
package pkg25d_cfg_pkg;
 
  localparam int NUM_DIES = 6;
 
  typedef struct packed {
    logic       present;          // is this die populated in this SKU?
    logic [7:0] neighbor_mask;    // which dies share a physical link with it
    logic [7:0] link_width_code;  // encoded routed width of its links
  } chiplet_cfg_t;
 
  // Expected topology for this SKU — the package's claim about itself.
  localparam chiplet_cfg_t EXPECTED_CFG [NUM_DIES] = '{ /* ... per SKU ... */ };
 
endpackage

Architecture. The package floorplan produced three facts per die: whether it is there, what it can reach, and how wide those reaches are. Keeping them in one structure means the system has exactly one description of the package instead of four that can disagree.

State. EXPECTED_CFG is elaboration-time — the SKU's intended topology. The discovered topology, populated during bring-up, is real state.

Cycle behaviour. Discovered values are written once as links come up, then stable. Nothing here changes during steady-state traffic.

Contract. Routing, bandwidth accounting, power management, and any software-visible topology view all read from this one descriptor. Note what is absent: no bump maps, no interposer layer indices, no bridge identifiers, no per-lane health. §14 explains why that omission is load-bearing.

Failure. With several independent copies of "what the package looks like" — one in the router, one in the PHY configuration, one in firmware — they drift, and the resulting bug is a disagreement between two correct-looking modules.

DV. Sweep the descriptor. It is the single parameter that defines a configuration, which makes it the natural axis for the configuration coverage in §12.

10. Detect Mismatch Instead of Hanging

A configured topology and a discovered topology are two different things, and the gap between them is where silicon bring-up goes wrong.

// Illustrative — topology agreement check at end of bring-up.
logic topology_valid;
assign topology_valid = (expected_neighbor_mask == discovered_neighbor_mask);

Real discovery is more involved than one comparison — links come up at different times, some are optional, and some mismatches are legal for a degraded SKU. The point is not the expression; it is the principle:

The digital system should detect a package or configuration mismatch and report it, rather than proceed on a false assumption and hang later.

The difference in debug cost is enormous. A mismatch reported at bring-up names the disagreeing bit. The same mismatch left undetected surfaces hours later as a transaction that never completed, on a link that trained perfectly, with no error counter anywhere.

Two assertions make the routing consequences executable:

// Illustrative — no traffic may be routed toward an unpopulated die.
property p_no_route_to_absent_chiplet;
  @(posedge clk) disable iff (!rst_n)
    route_fire |-> die_present_q[route_dst];
endproperty
 
a_no_route_to_absent_chiplet :
  assert property (p_no_route_to_absent_chiplet)
  else $error("Routed toward die %0d, which is not populated.", route_dst);

Physical fact encoded: this SKU does not contain that die. Bug caught: an address decode, route table, or software topology view that reflects the maximum configuration rather than the populated one. Why it is digital verification's job: the symptom in silicon — a transaction that vanishes on a healthy link — is indistinguishable at the waveform level from several unrelated failures, so catching it in simulation is worth days.

// Illustrative — a route may only use a link that is enabled and physically present.
property p_route_uses_enabled_link;
  @(posedge clk) disable iff (!rst_n)
    route_fire |-> link_enable_q[selected_link];
endproperty
 
a_route_uses_enabled_link :
  assert property (p_route_uses_enabled_link)
  else $error("Route selected link %0d, which is not enabled.", selected_link);

Physical fact encoded: the set of links this configuration actually brought up. Bug caught: the classic degraded-mode defect — a link is disabled after a bring-up failure and the routing logic, which computed its decision from static topology, keeps selecting it. Why it belongs here: disabling a link is easy; making every consumer of that link agree it is disabled is where the bug lives.

11. Insufficient Bandwidth Has a Digital Signature

This section is the most practically valuable in the chapter, because it connects package engineering to something you can actually see on a waveform.

The package has no RTL. But underprovisioned package bandwidth shows up digitally, in a specific and recognisable way: at the ingress queue of the inter-die interface.

// Illustrative — inter-die ingress occupancy with a congestion watermark.
localparam int DEPTH          = 32;
localparam int HIGH_WATERMARK = 24;
 
logic [$clog2(DEPTH+1)-1:0] ingress_occ_q;
logic                       congestion;
logic [15:0]                congested_cycles_q;
 
always_ff @(posedge clk or negedge rst_n) begin
  if (!rst_n) begin
    ingress_occ_q      <= '0;
    congested_cycles_q <= '0;
  end else begin
    // occupancy moves only on an actual enqueue/dequeue, never on both
    if (push && !pop)      ingress_occ_q <= ingress_occ_q + 1'b1;
    else if (pop && !push) ingress_occ_q <= ingress_occ_q - 1'b1;
 
    if (congestion && !(&congested_cycles_q))
      congested_cycles_q <= congested_cycles_q + 1'b1;
  end
end
 
assign congestion = (ingress_occ_q >= HIGH_WATERMARK);

Architecture. The package edge has finite bandwidth. Something has to absorb the mismatch between what the producer offers and what the link drains, and that something is a queue. Its occupancy is therefore a direct measurement of whether the link is keeping up.

State. An occupancy counter and a saturating counter of congested cycles. The second exists because instantaneous congestion is normal and sustained congestion is a finding — one is a burst, the other is a bandwidth shortfall.

Cycle behaviour. Occupancy changes only on an enqueue without a dequeue or vice versa; simultaneous push and pop leave it unchanged, which is the standard trap in occupancy counters and worth writing explicitly.

Contract. Flow control reads occupancy to assert backpressure. Performance monitoring reads the congested-cycle counter. Neither knows anything about the package — they observe its consequences.

Failure. With no such counter, a bandwidth shortfall is invisible in RTL. The design is functionally perfect and the product misses its performance target, and the investigation starts by looking for a bug that does not exist.

DV. Run traffic at the architecturally assumed demand from §8, not at whatever the testbench happens to generate, and check that sustained congestion stays inside the budget. This turns a bandwidth assumption into a regression-checkable property, which is the only way an architecture assumption survives contact with a schedule.

Physical underprovisioning leaves a digital signature. Learn to read it and package bandwidth stops being someone else's mystery.

12. Reading the Waveform

The signature is distinctive enough to name:

• Error counters are clean. CRC is not firing; there is nothing wrong with the data.
• Training is stable. The link came up and stayed up; no retrains, no recoveries.
• Ingress occupancy repeatedly reaches or approaches full, and stays there under sustained load rather than spiking and draining.
• Backpressure is asserted a large fraction of the time, and the stall propagates upstream into the producer.
• Latency grows with offered load, superlinearly, in the way queueing delay does.

This is not a PHY correctness bug, and it is not an RTL bug. The link is doing exactly what it was built to do, at exactly the rate it was built for. The demand exceeds it.

A clean link that is always full is not broken. It is too small — and that is an architecture finding, not a debug finding.

Chase this as a functional bug and you will spend weeks confirming that everything works. The correct response is to go back to §8, compare the measured demand against the assumed demand, and determine which one was wrong — because either the traffic analysis underestimated the load, or the floorplan gave that edge less width than the analysis required.

13. Power and Heat Are Shared, Not Per-Die

Two package-level resources are shared across every die, and neither is visible in any one die's design.

Thermal coupling. The dies that most want to be adjacent are frequently the ones that most heat each other. Compute, accelerator, and memory placed close — exactly what §4's embedding wants — means each raises its neighbours' operating temperature, memory placed beside a hot compute die may have its own thermal constraints tightened, and the cooling solution is a single shared path. The architectural consequence, without inventing a single temperature: sustainable performance states can be coupled across dies, and placement is a thermal decision at the same time it is a bandwidth decision.

Power delivery. Every die draws current through a shared PDN — board, substrate, and whatever vertical structures the package uses. That network has limits, and multiple dies demanding peak current simultaneously is precisely the case it is least able to serve. So the package may be unable to support every die at maximum activity at once, whatever each die's individual specification says.

Package power is a shared system resource, not each chiplet's independent problem. A per-die power budget that sums to more than the package can deliver is not a conservative plan; it is an unenforceable one.

And this is where a physical envelope becomes digital arbitration:

// Illustrative package-level power arbitration — not UCIe behaviour.
logic compute_boost_req, accel_boost_req;
logic package_power_budget_ok;   // from platform power management
 
// The accelerator may boost only if the package envelope allows it.
assign accel_boost_grant   = accel_boost_req   && package_power_budget_ok;
assign compute_boost_grant = compute_boost_req && package_power_budget_ok;

Architecture. The PDN and thermal solution impose a package-wide ceiling. Requests from independent dies must be arbitrated against a shared budget rather than granted locally.

State. A budget-available indication maintained by platform power management, plus per-requester grant state in the real version.

Cycle behaviour. Requests are sampled and granted on a much slower timescale than data transfer — power states change over microseconds and longer, not per cycle.

Contract. Each die's performance-state logic must treat its boost as conditional. A die that boosts on its own authority has assumed a resource it does not own.

Failure. Two dies boosting simultaneously on independent local decisions can exceed what the package can deliver, producing voltage droop that presents as marginal links, correctable errors, or instability under specific workloads — a failure whose cause is in a different die from its symptom.

DV. Test simultaneous requests from multiple dies explicitly, including the case where the budget is withdrawn while a boost is active. Note this is not UCIe behaviour — it is system architecture, and inventing a specification citation for it would be worse than having no citation at all.

14. Keep Physical Detail Out of the Upper Layers

A caution, because this chapter has been pushing package facts into RTL and it would be easy to overshoot.

The Protocol Layer must not know about bridge identifiers, bump locations, interposer route indices, or lane health. Those live in the Physical Layer and the package configuration, exactly where Module 5 put them. What the system routing layer may know is logical connectivity — which destinations exist and are reachable — because that is a system property expressed in die identities, not a manufacturing detail.

The line is easy to state and easy to violate:

The test is a thought experiment: if the package were respun with the same logical topology but different physical construction, how much RTL changes? If the answer is anything above the Physical Layer, a physical detail has leaked upward, and the next package generation will cost far more than it should.

15. Fault Containment Is a Product Decision

One chiplet fails to initialise. What happens?

The available answers are all legitimate, and which one applies is architecture, not physics:

1. The product fails. Simple, entirely defensible for a system whose function requires every die.
2. Degraded operation. The system runs with reduced capability, if — and only if — the architecture was designed for it, software can discover it, and the reduced configuration was verified.
3. The chiplet is disabled and its work is refused, with a defined error rather than a hang.
4. Traffic is rerouted, which requires alternate paths to exist physically and the routing structure to support them.

Do not assume option 2 exists. Degraded mode is a large amount of design and verification work — discovery, software contract, a different route graph, a different bandwidth budget, and its own coverage — and a system that has not done that work does not get it by accident.

This is exactly why two masks are needed rather than one:

// Illustrative package-to-RTL configuration — not UCIe normative signal naming.
logic [NUM_DIES-1:0] die_present_q;   // physically populated and detected
logic [NUM_DIES-1:0] die_enabled_q;   // the system chooses to use it

Architecture. Present is a fact about the package. Enabled is a decision by the system. They differ constantly in practice: a die present but disabled by binning, by a bring-up failure, by a product SKU decision, or by a debug override.

State. Two masks. die_present_q is written by discovery; die_enabled_q by policy. die_enabled_q ⊆ die_present_q is the invariant that ties them.

Cycle behaviour. Both settle during bring-up. die_enabled_q may change later if the system supports disabling a die at runtime.

Contract. Routing consults enabled. Discovery and diagnostics consult present. Confusing the two produces the two classic bugs: routing to a die that is present but deliberately not in use, and reporting a die as missing when it is merely disabled.

Failure. With a single mask, "not present" and "not in use" become indistinguishable, and every diagnostic that depends on the difference — which is most of them — becomes unreliable.

16. The Configuration Space, and How Not to Drown In It

2.5D multiplies configurations: chiplet count, topology, link widths, package class, optional accelerators, memory population, degraded links. The Cartesian product is large, most of it is unreachable, and testing it blindly is both impossible and pointless.

Test equivalence classes instead — representative points chosen because each exercises a distinct behaviour:

Two of those deserve emphasis. Degraded must test the transition, because the steady degraded state usually works and the moment of degradation usually does not. And illegal is the one teams skip, on the reasoning that it cannot happen — but the check that rejects it is code, and untested code that only ever runs during a failure is code that fails during a failure.

The strategy in one line: the package defines the space; equivalence classes define the coverage; the assertions in §10 hold everywhere in between.

17. Measuring Configuration Coverage

Assertions prove invariants hold in the configurations you ran. Coverage tells you which configurations you actually ran — a different question, and the one that is usually unanswered.

// Illustrative configuration coverage — not UCIe-defined.
covergroup cg_package_cfg @(posedge cfg_sample);
  cp_present_count : coverpoint present_count {
    bins minimum   = {MIN_DIES};
    bins mid[]     = {[MIN_DIES+1 : NUM_DIES-1]};
    bins maximum   = {NUM_DIES};
  }
  cp_link_width : coverpoint active_link_width {
    bins narrow = {[1 : MAX_LANES/4]};
    bins mid    = {[MAX_LANES/4 + 1 : MAX_LANES-1]};
    bins full   = {MAX_LANES};
  }
  cp_degraded : coverpoint any_link_degraded;
  cp_congested : coverpoint sustained_congestion;
 
  // The interesting question is not each axis alone.
  x_width_by_congestion : cross cp_link_width, cp_congested;
endgroup

What it measures. Which package configurations the regression actually visited, and — through the cross — whether narrow-link configurations were ever driven hard enough to congest.

Why the cross is the valuable part. Hitting "narrow width" and hitting "congested" separately proves very little; a narrow link that was never loaded and a full-width link that was loaded tell you nothing about the case that ships. Bugs concentrate where a constrained configuration meets real load, and the cross is what shows whether you have been there.

Why it belongs in a packaging chapter. These coverpoints are not RTL properties. They are the package's degrees of freedom, made measurable. A regression that reports 100 % functional coverage on one configuration has measured one point of a space the product ships across.

18. Three Failure Classes, and How to Tell Them Apart

This is the section to keep. Nearly every inter-die problem falls into one of three classes, each with a distinct evidence signature and a completely different first move.

Three discriminators do almost all the work:

1. Do error counters move? If yes, it is class A. Physical problems corrupt; configuration and capacity problems do not.
2. Does light load fix it? If yes, it is class C. Capacity failures are load-dependent by definition; the other two are not.
3. Is the failure scoped to a destination or to a link? A destination that fails across a working link is class B — no physical mechanism produces that pattern.

19. Common Misconceptions

"2.5D just means multiple dies in one package." Multi-chip packages are decades old. 2.5D is defined by the dense intermediate fabric that makes die-to-die connection an architectural resource rather than a peripheral interface (§1).

"Logical topology and physical floorplan are separate concerns." In a 2.5D package they are the same object viewed twice. Every logical edge is a physical route with a length, a width, and a claim on shared resource (§4).

"If every UCIe link meets spec, system bandwidth is sufficient." Per-link compliance says nothing about aggregate demand, simultaneity, or burst behaviour. A system of compliant links can be badly underprovisioned (§8).

"Advanced packaging removes backpressure." It raises the ceiling. Backpressure is what happens when demand exceeds the ceiling, wherever the ceiling is (§7, §11).

"More routing density means any topology is practical." A plane has limited adjacency, dies have four edges, and routes compete. Some graphs do not embed at any density (§4).

"Package power is each chiplet's independent problem." It is a shared resource with a package-wide ceiling, which is why boost decisions may need arbitration across dies (§13).

"Thermal placement is mechanical engineering's concern." It constrains adjacency, which constrains the graph embedding, which constrains the architecture — and it can make performance states mutually exclusive (§13).

"A clean PHY means a slow system must be an RTL bug." The third possibility is the common one: correct RTL on a correct link that is too small for the demand. Sustained ingress occupancy tells them apart in minutes (§11, §12, §18).

"Verification only needs one package configuration." Each configuration is a different route graph, a different bandwidth budget, and a different set of reachable destinations. One configuration verifies one point (§16).

"The package is frozen once RTL architecture starts." The traffic graph and the floorplan are one decision. Freezing either without the other guarantees rework (§4).

"Standard-package and advanced-package UCIe are the same physical design point." They share architecture, layering, and protocols, and differ in bump map and PHY organisation — 16 lanes at roughly 100–130 µm reaching about 25 mm, against 64 lanes at roughly 25–55 µm reaching about 2 mm (§6).

20. Understanding Check

21. Summary and What Comes Next

2.5D integration keeps active dies side by side and uses a dense intermediate fabric to make them behave like one system. The fabric is the definition; the die count is not.

The chapter's central model is that floorplanning is graph embedding. Characterise every edge of the traffic graph by bandwidth and latency sensitivity and character, then embed that graph into a plane with limited adjacency, finite routing resource, a power envelope, and a thermal envelope. Latency-critical narrow edges want minimum logical distance; bandwidth-hungry tolerant edges want minimum physical distance. Those are different optimisations and the edge decides which applies.

UCIe's two package tracks are the same architecture at two physical design points: 16 lanes at roughly 100–130 µm reaching about 25 mm, against 64 lanes at roughly 25–55 µm reaching about 2 mm. Wide-and-short or narrower-and-far — and the floorplan decides which one you can use. Because only the bump map and PHY organisation differ, everything above stays reusable, which is the layering discipline paying for itself.

Bandwidth is budgeted symbolically — B_link = lanes × rate_per_lane × efficiency, with efficiency taken from your specification revision — against simultaneous peak demand and a deliberate utilisation ceiling, never against averages. Then the digital bridge, which is the most useful thing in this chapter: the package's facts become one topology descriptor; presence and enablement are separate masks because a die present and a die in use are different things; routing legality becomes assertions; the configuration space becomes equivalence classes and coverage; and package bandwidth becomes ingress queue occupancy, which is how an architecture assumption becomes something a regression can check.

Above all, the triage: error counters moving means physical; light load fixing it means capacity; one destination failing on a working link means topology. Two cheap questions, asked in the right order, redirect most inter-die investigations before the expensive work starts.

2.5D removes distance in the plane by placing dies close and wiring them densely. There is a further step, which removes the horizontal distance almost entirely:

• 6.5 — 3D Packaging — stacking active dies vertically, where the connection is direct rather than lateral, and where power delivery and heat removal become the dominant constraints.

Browse the full path on the UCIe tutorials index.