Intel EMIB

Chapter 6.2 established what a silicon interposer buys and what it costs. The density is real. So is the cost: a large piece of manufactured silicon spanning the whole die complex, with vertical structures through it, added to a package that still needs an organic substrate underneath for power and for reaching the board.

Now look at where the density is actually needed. In most multi-die systems, dense wiring is required between specific pairs of neighbouring dies — compute to system die, system die to memory controller, accelerator to its host. Between everything else, ordinary substrate routing is entirely adequate, because the traffic is modest and the connection count is low. A full interposer serves the whole area at the density the worst pair requires.

That observation is the entire idea behind the embedded bridge, and it produces an architecture with a very different shape — one whose consequences reach much further into RTL than the interposer's did.

1. The One-Sentence Model

EMIB puts silicon only where fine-pitch die-to-die wiring is actually needed, embedding small local bridges inside an otherwise organic package.

The architectural contrast is worth stating as a pair, because the whole chapter lives in the gap between them:

Everything in this chapter follows from the row in bold. Density becomes local, and locality is not a detail — it turns package adjacency into a hard architectural constraint that the digital design has to encode, verify, and debug against.

2. The Physical Structure

Working from the substrate up, as described in Intel's technology material and in IEEE packaging publications:

• An organic package substrate, built as Chapter 6.1 described: core, build-up layers, vias, delivering power and routing globally.
• A cavity formed in the substrate's upper build-up region.
• A small silicon bridge die placed into that cavity and embedded — encapsulated with dielectric, with the substrate's build-up layers continuing above and around it.
• Fine-pitch connections landing from the dies above onto the bridge's surface. Reported EMIB generations use bump pitch on the order of 55 µm, with a second generation scaled to about 45 µm and further scaling described as a roadmap target.
• The dies themselves, mounted above, each straddling the bridge region so that both land on the same bridge.

The bridge is a piece of silicon carrying interconnect patterned with semiconductor back-end-of-line processing — Intel and IEEE sources describe line-and-space geometry far finer than organic laminate can achieve. It is doing exactly what an interposer's routing layers do. It is simply small, and it is inside the substrate rather than on top of it.

Two structural facts to fix now, because §3 and §8 both depend on them:

1. The bridge is not underneath the whole package. It occupies a local region spanning the boundary between two neighbouring dies.
2. Classic EMIB carries no through-silicon vias. Intel's material is explicit that eliminating the TSVs and the large interposer silicon is a central point of the approach. The bridge routes laterally only; everything vertical — power, board-bound signals — goes through the surrounding organic substrate.

3. Why Avoiding a Full Interposer Matters

The benefits follow structurally, and they should be stated conditionally rather than as slogans:

• Far less manufactured silicon routing area. A bridge spanning one die boundary is a small fraction of the area of an interposer spanning the whole complex. Silicon area is the dominant cost term in the interposer approach, so reducing it is significant.
• No TSVs required in the classic structure. Intel's material identifies eliminating TSVs and specialised interposer silicon as a source of reduced complexity and cost.
• Global routing stays in the substrate, which is mature, high-volume, panel-scale manufacturing — and which had to exist regardless.
• The dies do not all have to share one silicon structure, which decouples the package's overall size from the size limit of a lithographically patterned interposer.

The honest qualifier: none of that is a universal cost ruling. Embedding silicon in a substrate cavity is itself a specialised process with its own yield and assembly considerations, and whether a bridge package or an interposer package is cheaper depends on the number of dense interfaces, their placement, the die count, the process generation, and the volume. What is defensible and general is the shape of the trade — bridges pay for density per interface, interposers pay for density per area — and which is cheaper follows from how many interfaces you need and how spread out they are.

4. Locality Is the Price

This is the section the chapter exists for.

A bridge connects specific nearby dies. It provides no routing between dies it does not span. There is no global dense fabric — outside the bridge regions, the package is an organic substrate with all of Chapter 6.1's limits intact.

An embedded-bridge architecture turns adjacency into a first-class system constraint.

On an interposer, the question "can these two dies have a wide link?" is a routing-resource question — usually yes, at some cost in area and congestion. On a bridge package, the same question is binary: either a bridge spans that boundary or it does not. If it does not, no amount of routing effort creates one, because the dense medium is simply not present there.

That binary character is what makes this an RTL-visible property rather than a physical-design detail. Routing resource is a gradient you can negotiate; a missing graph edge is a fact you must design around.

5. Floorplanning Becomes Tightly Coupled

If Die A must communicate with Die B through a bridge, then:

• They must be physically positioned so that both overlap the same bridge region — which means adjacent, in a specific relative orientation, at a specific separation.
• Their PHY placements must align. The bridge lands under a particular area of each die, so the D2D PHY on each die has to be at the edge that faces the bridge. This is a die-floorplan constraint originating in a package decision.
• The substrate must support the bridge landing — the cavity, the surrounding build-up routing, and the power delivery around it all have to work at that location.
• Every additional bridge multiplies these constraints, because each one pins another pair of dies into a specific geometric relationship.

The result is a genuine co-design problem. The logical architecture ("compute talks to system, accelerator talks to system") and the package floorplan ("these two overlap bridge A, these two overlap bridge B") are the same decision expressed twice, and they must be made together or one of them will be wrong.

6. The Package as a Graph

The cleanest way to hold all of this — and the way that transfers directly into RTL — is as a graph.

• Vertices are dies.
• Edges are bridges.
• Not every pair has an edge. That is the entire point.

A representative shape:

Compute 0  ──[Bridge A]──  System Die  ──[Bridge B]──  Accelerator
                                │
                           [Bridge C]
                                │
                          Memory Controller

Read off the consequences immediately:

• Compute 0 ↔ System is a direct, dense, single-hop path.
• Compute 0 ↔ Accelerator has no edge. Whatever the block diagram drew, the package does not provide it.
• Anything reaching the memory controller from Compute 0 passes through the system die.
• The system die is on every path, which makes it the aggregation point, the bottleneck candidate, and the fault-concentration point simultaneously (§9).

7. The Bridge Graph Becomes RTL

The graph is a package fact. Encode it as one.

// Illustrative package-to-RTL configuration — not UCIe normative signal naming.
package brg_topology_pkg;
 
  localparam int NUM_DIES = 4;
 
  typedef logic [NUM_DIES-1:0] neighbor_mask_t;
 
  //  bit index:            3=accel  2=memctl  1=system  0=compute0
  localparam neighbor_mask_t NEIGHBOR_MASK [NUM_DIES] = '{
    /* 0 compute0 */ 4'b0010,   // bridge A → system only
    /* 1 system   */ 4'b1101,   // bridges A, B, C → compute0, memctl, accel
    /* 2 memctl   */ 4'b0010,   // bridge C → system only
    /* 3 accel    */ 4'b0010    // bridge B → system only
  };
 
endpackage

Architecture. Three bridges were placed, each spanning one die boundary. The mask is a transcription of where they physically are — nothing more, nothing invented.

State. None. This is elaboration-time configuration, and deliberately so: bridge placement is fixed at package design, so making it a localparam means an illegal assumption is a compile-time or simulation-time failure rather than a silicon mystery.

Cycle behaviour. Read combinationally wherever a destination is selected.

Contract. Whatever chooses a next hop — a router, an arbiter, an address decoder in the system fabric — must consult this before it commits. Notice that the mask is expressed in die identities, not bridge identities, bump locations, or lane numbers. The fabric may know who it can reach; it must not know how the wiring is built. Module 5's layering discipline is not suspended because we moved into packaging.

Failure. If the fabric assumes full connectivity, it will select a destination with no physical edge. The request leaves and nothing arrives.

Route selection then reduces to a single combinational check:

// Illustrative — direct-path legality, derived from bridge placement.
logic direct_route_ok;
assign direct_route_ok = NEIGHBOR_MASK[src_id][dst_id];

Three architectural outcomes are possible when direct_route_ok is low, and which one applies is a product decision, not a property of bridges:

1. Route indirectly through an intermediate die, if the architecture contains a die that forwards traffic (§9).
2. Reject the configuration at boot, if the software model expected a path that the package does not provide.
3. Report the destination unreachable, if the fabric exposes reachability to software.

What is never acceptable is the fourth option — accept the request and let it disappear.

8. The Wrong Version, and What It Looks Like in Silicon

The mistake is easy to make because it is the natural thing to write:

// WRONG architectural assumption — assumes a fully connected package.
assign direct_route_ok = (src_id != dst_id);

This says: any destination that is not me is directly reachable. On a monolithic die with an on-chip network that is very nearly true. On an interposer it is often approximately true. On a bridge package it is false by construction, because the whole design intent was to place dense silicon in some boundaries and not others.

The failure signature is deceptively benign. Every endpoint initialises. Every bridge that exists trains cleanly. The router accepts the request without complaint, because from its perspective the request was well formed. The transaction is issued toward a path that has no physical existence, and then:

• nothing arrives at the destination,
• no error is raised by any layer, because no layer observed a violation,
• the requester's timeout eventually fires — or, if there is no timeout on that path, the transaction never completes and a resource is held forever.

This is why the assertion matters more than the check:

// Illustrative — every transmitted hop must correspond to a physical bridge.
property p_selected_neighbor_exists;
  @(posedge clk) disable iff (!rst_n)
    tx_valid |-> NEIGHBOR_MASK[LOCAL_ID][tx_next_hop];
endproperty
 
a_selected_neighbor_exists :
  assert property (p_selected_neighbor_exists)
  else $error("Die %0d selected next hop %0d with no bridge between them.",
              LOCAL_ID, tx_next_hop);

What physical fact it encodes: that a specific pair of dies overlaps a specific embedded bridge. What bug it catches: any routing decision — from a route table, an address decode, a load-balancing choice, or a debug backdoor — that assumes connectivity the package does not have. Why it belongs in digital verification: because the mechanical fact is invisible to every other check. Simulation models an ideal channel and will happily deliver a packet across a link that does not exist in the package.

9. Bandwidth Has a Shape Now

If the only dense path between two dies goes through a third, that third die is not a detail:

• Latency rises by whatever the forwarding die costs — receive, decide, queue, retransmit — on top of a second link traversal.
• Its resources are consumed by traffic that is not addressed to it: buffers, arbitration slots, and outbound link bandwidth all get spent on pass-through.
• It becomes a contention point. Compute 0 → memory and accelerator → memory both traverse it, so they interfere with each other in a way the logical block diagram never suggested.
• It concentrates faults. If the hub die is down, every path is down, whether or not the endpoints are healthy.

This reconnects directly to the I/O and system-chiplet material earlier in the curriculum. A central system die in a bridge package is the routing hub, the bandwidth aggregation point, the potential bottleneck, and the single point of failure — all four at once, and all four because of where the bridges were placed.

10. Power and Thermal Are Not Solved by Bridges

A bridge solves a local signal-density problem. It solves nothing else, and one property makes this sharper than for an interposer.

Because classic EMIB has no TSVs through the bridge, power cannot travel vertically through it. Current destined for the die area above a bridge has to be delivered by the surrounding substrate and routed around the embedded silicon. That is a real constraint, and it is exactly the constraint that motivated a later variant: Intel's EMIB-T, which adds through-silicon vias through the bridge specifically to give a direct vertical power path, along with in-bridge capacitance. The lesson generalises past the product name:

A structure optimised for lateral signal density can obstruct vertical power delivery, and the fix is a different structure — not a different RTL parameter.

Everything else from Chapter 6.1 and 6.2 still applies unchanged. The substrate still carries global power and global routing. Dies placed close still couple thermally, and bridges require them to be close. Cooling is still a package-level problem shared across every die. Nothing about embedding silicon in a cavity changes any of that.

11. Assembly, Test, and the Configuration Space

At the level an architect needs — and no further, because manufacturing detail here is vendor-specific and changes:

• More attachments, more ways to be wrong. Multiple dies attach to a substrate that also contains embedded silicon, and each attachment must land accurately on it.
• Bridge alignment and interconnect quality matter, because fine-pitch connections have little tolerance.
• Known-good-die practice remains essential. Chapter 1.3's argument does not weaken; a bad die discovered after assembly still costs the whole package.
• Package-level test still exists, because assembly can fail in ways die-level test cannot see.

The consequence that reaches RTL is product configuration. A package family may ship with different die populations — with or without the accelerator, with one memory controller or two — and each variant is a different graph.

// Illustrative package-to-RTL configuration — not UCIe normative signal naming.
// Discovered or strapped at boot; not a compile-time constant.
logic [NUM_DIES-1:0]  die_present_q;      // which dies this SKU actually has
logic [NUM_LINKS-1:0] bridge_link_en_q;   // which bridged links are in use

Architecture. The bridge placement is fixed in the substrate, but which dies are populated and which links are brought up varies by SKU and by bring-up outcome. Those are runtime facts, so unlike §7's mask they get registers.

State. Two masks, written once during boot or configuration and stable thereafter.

Cycle behaviour. Sampled by link bring-up sequencing and by routing legality checks after configuration completes; not modified during normal operation.

Contract. Bring-up logic must not attempt to train a link toward an unpopulated die. The fabric must not route toward one. Software's topology view, if exposed, must be derived from these rather than assumed.

Failure. If bridge_link_en_q enables a link whose far endpoint is not populated, bring-up will drive a link into a void: training runs, times out, retries, and burns bring-up time on an error that is not an error — the die was never supposed to be there.

The corresponding invariant:

// Illustrative — an enabled bridged link requires both of its endpoints.
generate
  for (genvar L = 0; L < NUM_LINKS; L++) begin : g_bridge_endpoints
    property p_bridge_endpoints_present;
      @(posedge clk) disable iff (!rst_n)
        bridge_link_en_q[L] |-> die_present_q[LINK_ENDPOINT_A[L]] &&
                                die_present_q[LINK_ENDPOINT_B[L]];
    endproperty
 
    a_bridge_endpoints_present :
      assert property (p_bridge_endpoints_present)
      else $error("Bridge link %0d enabled with an absent endpoint.", L);
  end
endgenerate

Physical fact encoded: a bridge is only useful if silicon is populated at both of its ends. Bug it catches: a configuration path — fuse, strap, firmware table, test override — that enables a link for a SKU that does not have the die. Why it belongs in digital verification: because the resulting symptom is a link-training failure, which every instinct will send you to investigate as a PHY or channel problem, when the actual defect is one bit in a configuration mask.

12. Verification Across the Configuration Space

Package modularity is where architecture turns into verification combinatorics. The test plan needs entries that a single-configuration testbench will never produce:

• Each legal bridge graph the product ships, exercised with real traffic on every edge.
• Missing optional chiplet — the accelerator-absent SKU is a different graph, not the same graph with one endpoint quiet.
• Disabled bridge link, with a populated die at both ends, to prove that disabling is clean rather than merely untested.
• Indirect routing, if the architecture supports it — including that the forwarding die's own traffic still makes progress under pass-through load.
• Concentrated traffic at the hub, since a die on every path is the natural hotspot and the natural place for fairness and deadlock bugs.
• Illegal configuration rejection — enabling a link toward an absent die must be detected and reported, not attempted.
• Reset of one bridged endpoint while its neighbour stays up, which is Chapter 5.5's three-way reset problem instantiated across a package boundary.

The organising idea: the package defines the configuration space; DV proves digital correctness across it. A testbench hard-coded to the maximum configuration verifies exactly one point in that space, and it is usually not the point that ships first.

13. Debug Order for a Bridge Package

The single most useful habit in a bridge-based system: when one die-to-die pair works and another does not, ask topology questions before analogue questions.

In order:

1. Do the two dies share a bridge at all? Check the package floorplan, not the block diagram. If there is no edge, everything downstream is irrelevant.
2. Is the correct bridge enabled? Check bridge_link_en_q or its equivalent against the intended configuration.
3. Are both endpoints populated? Check die_present_q against the SKU.
4. Do the die identifiers agree between the fabric's route table, the configuration masks, and the package documentation? Off-by-one in die numbering produces exactly this symptom.
5. Only now, look at the PHY, the channel, and the package signal integrity.

Steps 1–4 take minutes and are done from configuration state. Step 5 takes days and needs lab equipment. The ordering is not fussiness; it is the difference between a morning and a week.

14. Comparing the Three Structures

Everything from 6.1 through 6.3, in one place — qualitative, because the quantitative answer depends on the design:

The last row is the one to remember. Each structure has a characteristic architectural mistake, and knowing which mistake a package invites tells you what to check first.

15. Common Misconceptions

"EMIB is a small full interposer." Structurally it is embedded inside the substrate rather than mounted on it, and classic EMIB carries no TSVs. Functionally the difference is decisive: an interposer offers routing everywhere, a bridge offers it only across the boundary it spans (§2, §4).

"A bridge package has dense routing everywhere." It has dense routing in the bridge regions and Chapter 6.1's laminate everywhere else (§4).

"Bridge topology does not affect RTL." It determines which destinations are reachable, which is exactly what routing and address-decode logic must respect (§7).

"Every die can directly reach every other die." Only bridged pairs can. That assumption compiles, simulates perfectly, and fails silently in silicon (§8).

"The organic substrate becomes irrelevant." It carries all global routing, all power delivery, all external connections, and physically contains the bridges (§2, §10).

"Bridges remove power and thermal constraints." They address local signal density only. Classic EMIB's TSV-free structure actually constrains vertical power delivery — the reason a TSV-bearing variant exists (§10).

"An enabled logical link proves a physical bridge exists." A configuration bit is a piece of state, not evidence about the substrate. That is the exact gap the endpoint-presence assertion closes (§11).

"Bridge-connected products have no topology verification problem." They have the industry's clearest one, because each SKU is a different graph and the space needs deliberate coverage (§12).

16. Understanding Check

17. Summary and What Comes Next

An embedded bridge is a small silicon die placed in a cavity in the organic substrate, carrying fine-pitch interconnect between two dies mounted above it. It delivers interposer-class connection density across one die boundary, using a small fraction of the silicon area a full interposer needs, while the organic substrate continues to handle all global routing and all power delivery. Classic EMIB carries no TSVs — which is part of its cost argument and, as the TSV-bearing variant shows, part of its power-delivery limitation.

The durable idea is the trade: dense silicon exists locally, not globally. From that one property everything else follows. Adjacency becomes binary rather than negotiable. The package becomes a graph in which not every pair has an edge. Floorplanning and logical architecture become a single co-design decision, reaching down into where each die places its D2D PHY. A hub die on every path becomes bottleneck, aggregation point, and fault concentration simultaneously.

And the digital bridge is the strongest in this module so far: the physical graph becomes a neighbour mask, runtime population becomes present and enable registers, and both become assertions — a hop must correspond to a real bridge, and an enabled link must have both endpoints populated. The mistake those assertions catch is the natural one to write, src_id != dst_id, which is correct on a monolithic die, roughly true on an interposer, and false by construction here. It compiles, it simulates perfectly, and it loses traffic in silicon with no error anywhere.

Chapters 6.1, 6.2, and 6.3 have each described a physical structure. The remaining question is architectural rather than physical: given these structures, how do you reason about a whole system of active dies side by side — the traffic graph, the floorplan, the bandwidth budget, the power and thermal envelope, the configuration state, and the verification space — as one design problem?

• 6.4 — 2.5D Packaging — the complete architectural class: mapping a communication graph onto package geometry, budgeting bandwidth symbolically, reading congestion in waveforms, and telling physical, topological, and capacity failures apart.

Browse the full path on the UCIe tutorials index.