UCIe Chiplet AI Accelerator Design: HBM4, Packaging and Bandwidth Math
The most important number on a modern AI accelerator is no longer a transistor count or a clock. It is a length: the millimetres of die edge you can spend on wires that leave the chip. A leading-edge scanner exposes roughly 26 mm by 33 mm, about 858 mm squared, and every accelerator that wants more silicon than that has to stitch dies together and feed them with memory through the same perimeter. A UCIe chiplet AI accelerator is the industry’s attempt to turn that stitching into a standard rather than a private trick.
This matters now because three things moved at once. The UCIe 3.0 specification doubled the planar data rate to 64 GT/s, HBM4 doubled the memory interface to 2,048 bits, and 5.5-reticle CoWoS-L packages entered volume production. Together they define how the next generation of GPUs and inference ASICs are built and where they will be constrained.
You will leave with the layered architecture of UCIe, the HBM4 numbers that matter, a worked bandwidth and energy budget you can reuse, and a decision framework for choosing interconnect and packaging.
What this covers: UCIe generations and layers, the physical layer and bump pitch, HBM4 per-stack math, 2.5D and 3D packaging (CoWoS, EMIB-T, hybrid bonding), a worked shoreline and power budget labelled illustrative, failure modes, and a practical checklist.
Context and Background
Chiplets are not new, but standardised ones are. For years, multi-die processors used proprietary die-to-die links: each vendor defined its own PHY, protocol and test flow, so a die from one company could never be dropped next to a die from another. That is fine when one firm designs both ends, as in a GPU built from two of its own compute dies. It breaks down the moment you want a third-party I/O die, a custom memory-side accelerator, or a hyperscaler’s in-house ASIC paired with a merchant chiplet.
Universal Chiplet Interconnect Express (UCIe) is the open answer. The consortium was founded in March 2022 and incorporated in June 2022, and by the time of its 3.0 presentation it counted more than 140 member companies. Its stated motivations are the ones every accelerator architect already feels: overcome reticle limits, reuse dies across products, improve yield with smaller dies, and mix process nodes so that each function uses the cheapest suitable technology.
Memory is the other half of the story. High Bandwidth Memory (HBM) stacks DRAM dies vertically and places the stack millimetres from the processor. We covered the economics of that supply chain in our analysis of the Micron HBM AI memory supercycle; this post looks at the interface and package physics instead. JEDEC published the HBM4 standard, JESD270-4, in April 2025. It doubles the channel count from 16 to 32 and moves to a 2,048-bit interface, with transfer speeds up to 8 Gb/s per pin and bandwidth up to 2 TB/s per stack, according to eeNews Europe’s coverage of the JEDEC release.
The two technologies solve different problems. HBM brings DRAM to the compute die at extreme bandwidth over a very short, very wide link. UCIe connects compute, I/O and accelerator dies to one another across a package. Both consume the same scarce resources: die-edge shoreline, interposer routing layers, and advanced-packaging capacity. Understanding that shared budget is the thesis of this article. If you also care about what happens after the package, our comparison of NVLink, InfiniBand and RoCE for GPU cluster networking picks up where the package edge ends.
Why one reticle is not enough
The reticle limit caps the area of a single exposure. Beyond cost, large monolithic dies suffer from defect-driven yield loss: the larger the die, the greater the chance that a random defect lands on it. Splitting a design into several smaller dies lets you test each one before assembly and discard bad ones, a practice known as known-good-die (KGD) screening. The consortium lists smaller dies and better yield, lower product cost through reuse, and process mix-and-match among its core motivations.
Splitting has a price. Every cut through a monolithic design turns an on-die wire bundle into a die-to-die link that costs area, energy and latency. The art of a chiplet accelerator is choosing cuts where the traffic is modest, or where the link is so wide and so efficient that the penalty disappears. That is exactly the territory UCIe targets.
A Reference Architecture for a UCIe Chiplet AI Accelerator
A UCIe chiplet AI accelerator is a system-in-package in which two or more compute dies are linked by UCIe on a silicon interposer or bridge, with HBM4 stacks attached through their own wide interfaces. The package substrate carries power and off-package I/O, while the interposer carries the dense die-to-die and die-to-memory wiring.

Figure 1: Reference package for a UCIe chiplet AI accelerator, showing compute dies linked by UCIe-A, HBM4 stacks on 2,048-bit interfaces, and the interposer or bridge layer that carries both.
Figure 1 shows the topology. Two compute dies sit side by side and talk over a UCIe-A link. Each also has direct HBM4 stacks on its far edges. All of those wires run through an interposer or an embedded bridge, which in turn sits on an organic substrate that routes power and the board-level links such as NVLink or PCIe. In a real product there are many more stacks and often more dies, but the pattern repeats.
The UCIe layer stack
UCIe is layered like PCIe, and deliberately so. The consortium describes three layers: a physical layer for die-to-die I/O, a die-to-die adapter for reliable delivery and multi-protocol support, and a protocol layer that carries PCIe, CXL or streaming traffic. Two internal interfaces separate them: the Raw Die-to-Die Interface (RDI) between adapter and PHY, and the Flit-Aware Die-to-Die Interface (FDI) between protocol and adapter.

Figure 2: The UCIe layer stack, with FDI and RDI as the reusable internal interfaces, sideband alongside the mainband, and a raw mode that bypasses the adapter.
The adapter does the unglamorous work that makes a package-level link trustworthy. Per the consortium’s presentation, it handles CRC and retry where applicable, link state management, parameter negotiation and configuration registers. The PHY handles link training, lane repair and reversal, scrambling, the analog front end and clocking, and the sideband channel. A separate raw mode lets a die bypass the adapter entirely and expose the PHY directly to something like a SerDes, which is also how the continuous-transmission usage in UCIe 3.0 works.
This layering has a practical consequence. Because FDI and RDI are standard, a team can buy a UCIe PHY from one vendor and a controller from another, or license the whole stack. It also means the protocol you run over the link is a choice. CXL and PCIe give you plug-and-play semantics for I/O attach, memory and accelerators, while the streaming mode carries a vendor’s own protocol. Many accelerator designs choose streaming with a proprietary network-on-chip extension, trading standard semantics for lower overhead.
Three physical flavours: S, A and 3D
UCIe defines three physical implementations, and picking among them is the central design decision.
- UCIe-S targets standard packages: 2D organic substrate routing, cheap, with the longest reach.
- UCIe-A targets advanced packages: 2.5D silicon interposers and bridges such as CoWoS and EMIB, with higher bandwidth density and better energy per bit.
- UCIe-3D targets vertical stacking with hybrid bonding, where bump pitches shrink to single-digit microns.
The consortium’s published key-metrics table gives the shape of the trade. All values below are from the UCIe 3.0 presentation, and the power-efficiency figures are targets rather than measured silicon.
| Characteristic | UCIe-S (2D) | UCIe-A (2.5D) | UCIe-3D |
|---|---|---|---|
| Data rate (GT/s) | 4 up to 64 | 4 up to 64 | up to 4 |
| Width per cluster | 16 | 64 | 80 |
| Bump pitch (um) | 100 to 130 | 25 to 55 | under 10 optimised, 10 to 25 functional |
| Channel reach (mm) | under 25 | under 2 | vertical |
| Power-efficiency target (pJ/b) | 0.5 up to 16 GT/s, 0.75 at 32 GT/s and above | 0.25 up to 12 GT/s, 0.3 for 16 to 32 GT/s, 0.5 at 48 GT/s and above | under 0.05 at 9 um, 0.01 at 1 um |
Two lessons jump out. First, reach and efficiency trade directly: the two-millimetre UCIe-A channel buys roughly half the energy per bit of the 25 mm UCIe-S channel at comparable speed. Second, 3D flips the economics. Because the wires are area-distributed rather than lined up along an edge, bandwidth scales with the inverse square of bump pitch, and the data rate can fall to a few GT/s so the circuits stay simple.
Generations: what each release added
The consortium’s timeline is short and regular. UCIe 1.0 arrived in March 2022 with the layered stack and the S and A flavours. UCIe 1.1 followed in August 2023. UCIe 2.0 came in August 2024, adding the 3D architecture and a manageability, test and debug framework. UCIe 3.0 arrived on 5 August 2025.
UCIe 2.0 is where two things changed the design conversation. It introduced UCIe-3D for hybrid bonding, which Converge Digest summarised as functional bump pitches from 10 to 25 microns down to as small as 1 micron. It also added the optional UCIe DFx Architecture (UDA), a management fabric in each chiplet for test, telemetry and debug. That second feature is easy to overlook and hard to live without: micro-bumps cannot be probed, so a package of dies from several vendors needs a standard way to test and repair links in assembly and in the field.
UCIe 3.0 doubled the planar speed. Per the consortium’s announcement, it supports 48 GT/s and 64 GT/s for UCIe-S and UCIe-A, doubling UCIe 2.0’s 32 GT/s, with runtime recalibration, a sideband reach of up to 100 mm, early firmware download over the Management Transport Protocol, priority sideband packets, and fast throttle and emergency shutdown signalling over open-drain pins. It remains fully backward compatible with all earlier versions. The specification is available to the public by request from the consortium.
What the 64 GT/s PHY actually does
Doubling the data rate is not free, and the presentation is candid about the machinery. The 48 and 64 GT/s modes keep NRZ unidirectional signalling and the same sideband, valid, track and data structure, but add a quarter-rate free-running forward clock, which means a 16 GHz clock at 64 GT/s. They require receiver termination for both S and A, a three-tap transmit feed-forward equaliser (one pre-cursor, one post-cursor), a first-order passive receiver CTLE and an optional one-tap DFE. The raw bit-error-rate target tightens to 1e-15 at 48 GT/s and 1e-12 at 64 GT/s, and transmit presets are chosen from a table of six during receiver deskew.
The stated goals are a linear bandwidth-density increase of 1.7 to 2 times and an areal increase of 1.3 to 1.6 times, at a power target of 0.5 to 0.75 pJ/b split roughly 40 percent transmit, 40 percent receive and 20 percent common circuits. For UCIe-S and UCIe-A the linear density rises 1.65 and 2 times respectively at similar power efficiency.
Synopsys, an IP vendor, adds the implementation view. In its analysis of the road to 64G UCIe IP, it notes that 64 Gbps is more power-hungry than 32 Gbps mainly because of the transmitter and receiver I/O, that advanced-package channels under 3 mm and organic-substrate channels under 5 mm allow lower-power drivers, and that a lightweight forward error correction scheme might compensate for relaxing jitter budgets. It also points to the bump map: in UCIe-A, receiver bumps sit behind transmitter bumps, forcing receive signals to route beneath the transmit bumps to reach the die edge, which adds crosstalk and inter-symbol interference at 48 and 64 GT/s. Synopsys announced a 64G UCIe IP tape-out on a 2 nm process in April 2026.
HBM4: The Memory Side of the Package
HBM4 moves from the 1,024-bit interface of earlier generations to 2,048 bits, doubling channels from 16 to 32, with two pseudo-channels per channel. JEDEC’s baseline is 8 Gb/s per pin, giving about 2 TB/s per stack. Vendors are shipping faster parts: Samsung’s February 2026 announcement describes mass-production HBM4 at a consistent 11.7 Gb/s, capable of up to 13 Gb/s, with a 4 nm logic base die and a 1c-class DRAM process.
The arithmetic is simple and worth memorising, because it governs everything downstream. Per-stack bandwidth equals interface width times per-pin rate divided by eight.
| Case | Width (bits) | Pin rate (Gb/s) | Per-stack bandwidth |
|---|---|---|---|
| HBM3E, 9.6 Gb/s | 1,024 | 9.6 | about 1.23 TB/s |
| HBM4 at the JEDEC baseline | 2,048 | 8 | about 2.05 TB/s |
| HBM4 at 11.7 Gb/s | 2,048 | 11.7 | about 2.99 TB/s |
| HBM4 at 13 Gb/s | 2,048 | 13 | about 3.33 TB/s |
Samsung’s own figure of a 3.3 TB/s maximum per stack, 2.7 times HBM3E, matches the last two rows, which is a useful sanity check that the standard’s arithmetic and the vendor claims agree. JEDEC also specifies 4-high through 16-high stacks with 24 Gbit or 32 Gbit dies, up to 64 GB per cube, and adds Directed Refresh Management (DRFM) for row-hammer mitigation plus improved RAS features. HBM4 controllers are backward compatible with HBM3 in the sense that one controller can serve both.
What the base die changes
The least appreciated HBM4 change is the base die. Every HBM stack has a bottom die that hosts the interface logic. In HBM4, vendors are building that die on logic process nodes rather than a DRAM process: Samsung cites 4 nm in-house, and TSMC has described foundry base dies for partners. A logic base die gives memory vendors the transistors to run a 2,048-bit PHY at double-digit Gb/s, and it opens the door to customisation: a hyperscaler can ask for extra logic in the base die.
That customisation matters to this article because it blurs the boundary between memory interface and chiplet interconnect. An HBM stack with a custom base die is, functionally, a chiplet with a memory-specific protocol. The question “why not carry memory traffic over UCIe?” is therefore live. The consortium itself has promoted UCIe for on-package memory, including at industry memory conferences. HBM4 today still uses the JEDEC interface rather than UCIe, so treat UCIe-attached memory as an option under discussion rather than the default.
A flagship data point: Rubin-class memory
Nvidia’s Rubin generation is the first mainstream design to pair two reticle-limited GPU dies with HBM4. According to secondary technical summaries, including Glenn Klockwood’s processor notes, the Rubin GPU carries 288 GB of HBM4 at 22 TB/s. We have not verified the stack count against an official datasheet, but eight stacks is the commonly reported configuration, and the numbers are self-consistent: 288 GB divided by eight is 36 GB per stack, which matches a 12-high stack of 24 Gbit dies, and 22 TB/s divided by eight is 2.75 TB/s per stack.
Working backwards, 2.75 TB/s over 2,048 pins implies roughly 10.75 Gb/s per pin. That is 34 percent above the JEDEC 8 Gb/s baseline, which fits press reports that Nvidia pushed HBM4 specifications upward during 2025. Treat the per-pin figure as inferred, not announced.
From Specification to Silicon: Worked Bandwidth, Shoreline and Energy Math
The spec tables are only useful once converted to a budget. This section builds one end to end. Everything derived below is illustrative arithmetic from published targets, not a measurement of any shipping product.
Step 1: how fast is one UCIe-A module?
A UCIe-A module has 64 data lanes. Synopsys quotes a 64-lane PHY at 64 Gb/s per lane as 4 Tb/s, with 4,096 data wires running at 2 GHz in the controller on a 256-byte datapath, inside a PHY only 388 micrometres wide. Convert it:
- 64 lanes x 64 GT/s = 4,096 Gb/s = 512 GB/s per direction.
- Both directions together: about 1 TB/s per module.
- Per millimetre of shoreline, one direction: 512 GB/s / 0.388 mm is about 1.32 TB/s/mm. Bidirectional, about 2.64 TB/s/mm.
That last number lines up with the consortium’s table, which lists 2,634 GB/s/mm of shoreline bandwidth for UCIe-A at 64 GT/s at 45 micrometre bump pitch, and 1,317 GB/s/mm at the top of the 4 to 32 GT/s range. The agreement across two independent sources tells us the table quotes bidirectional figures, a detail worth knowing when you compare against a vendor datasheet that quotes one direction.
At 32 GT/s the same module delivers 256 GB/s per direction, and the consortium’s UCIe-S example of a x16 module at 32 GT/s gives 512 Gb/s per direction, or 64 GB/s. A UCIe-A module is therefore 8x the raw bandwidth of a UCIe-S x16 module at the same rate.
Step 2: how much shoreline for a compute-die cut?
Suppose you split a design into two compute dies and the cut crosses 10 TB/s of traffic in each direction. This is a hypothetical target in the neighbourhood of what two-die GPUs advertise, not a vendor number.
- 10 TB/s per direction is 80 Tb/s.
- At 64 GT/s, one UCIe-A module gives 4.096 Tb/s per direction, so you need about 19.5 modules, call it 20.
- Twenty modules at 0.388 mm wide use about 7.8 mm of die edge. At 32 GT/s you would need 40 modules and 15.5 mm.
Now compare with the die perimeter. An 800 mm squared die might be 26 mm by 31 mm, so one 26 mm edge hosts a bit more than three times the shoreline you need at 64 GT/s. At 32 GT/s you would consume more than half of that edge before HBM or anything else gets a bump. This is the real case for 64 GT/s: not peak speed for its own sake, but the ability to cross a package-level cut with a fraction of the edge.
Step 3: what does the link cost in watts?
Using the consortium’s UCIe-A target of 0.5 pJ/b at 48 GT/s and above, and 0.3 pJ/b at 16 to 32 GT/s:
- 80 Tb/s per direction x 0.5 pJ/b = 40 W per direction, 80 W for both directions if both are saturated.
- At 32 GT/s and 0.3 pJ/b: 24 W per direction, 48 W both ways, but with twice the shoreline.
These are targets, and the transmit side often dominates because receiver power is partly idle when no data flows. Even so, the exercise exposes the energy-versus-edge tension: faster per-lane rates compress shoreline and cost more per bit, so the best choice depends on whether your constraint is die edge or package power. In an accelerator that burns on the order of a kilowatt, a few tens of watts for the on-package fabric is a design decision, not rounding error.
Step 4: the memory comparison
Take eight HBM4 stacks at 2.75 TB/s each, as in the Rubin-class example: 22 TB/s total. That is more than twice the 10 TB/s die-to-die cut above and is spread over the package perimeter via 8 x 2,048 = 16,384 data pins, before counting command, address, power and ground. The memory interface is the largest consumer of shoreline and bumps, which is why HBM stack count, not compute die count, usually sets the package size.
Energy per bit at the memory interface is not directly comparable: JEDEC specifies supply ranges (VDDQ options of 0.7, 0.75, 0.8 or 0.9 V and VDDC of 1.0 or 1.05 V) rather than a pJ/b target, and DRAM access energy dominates the interface term. Samsung reports a 40 percent improvement in power efficiency over HBM3E for its part, via low-voltage TSVs and power-distribution optimisation. We do not publish a pJ/b figure for HBM4 here because no standards-body number exists.
Step 5: yield, the reason for all of this
The motivation for splitting is yield. A first-order model puts die yield at exp(-D x A) where D is defect density and A is area. With an illustrative D of 0.1 defects per cm squared:
- One 800 mm squared die (8 cm squared): exp(-0.8) is about 45 percent.
- One 200 mm squared die (2 cm squared): exp(-0.2) is about 82 percent.
Four small dies tested individually and assembled from good ones waste far less silicon than one large die with the same total area, though assembly yield and KGD test cost eat part of the gain. Real defect densities are proprietary and process-specific, so use this only to understand the direction and rough magnitude of the benefit. Rebellions, for example, chose four 320 mm squared dies for its Rebel 100 accelerator rather than two reticle-size dies, a decision Tom’s Hardware’s ISSCC 2026 coverage attributes to ease of development and yield.
Step 6: bringing a link up
A UCIe link does not simply switch on. Both dies run a training sequence that discovers which lanes work, repairs broken ones, centres the data eye, and agrees on a protocol. The consortium’s slides show the high-speed portion: I/Q clock calibration happens in an RXCLKCAL phase, equalisation adjustments in RXDESKEW, and the transmitter preset is picked from six candidates using receiver eye margin, with the option to return to a data-centring state if more training time is needed.

Figure 3: Simplified UCIe link bring-up between two dies, from sideband initialisation through mainband repair and training, adapter parameter exchange and the ACTIVE state.
Figure 3 abstracts the sequence. The low-speed sideband comes up first and carries configuration traffic for everything that follows. The mainband then initialises, applies lane repair or reversal where needed, and trains at the target rate. Only after that does the adapter exchange parameters over the sideband and agree on the protocol and flit format. The practical implication for system designers is that link-up time and repair behaviour are part of boot, not afterthoughts, and that the sideband, which UCIe 3.0 extended to 100 mm reach for star topologies, is also the backbone for management.
Advanced Packaging: CoWoS, EMIB-T and Hybrid Bonding
UCIe-A and HBM4 both assume an advanced package. Without a silicon-class interposer or bridge you cannot route 2,048 HBM wires per stack or reach the 25 to 55 micrometre bump pitches the A flavour needs. The packaging choice therefore determines which interconnect you can use, how large the package can grow, and, increasingly, whether you can build it at all.
TSMC CoWoS variants
CoWoS stands for Chip on Wafer on Substrate. Chip-on-Wafer bonds logic and memory onto an interposer; Wafer-on-Substrate attaches that assembly to an organic package. A summary from Inside Deep Tech’s 2026 CoWoS guide gives three variants:
- CoWoS-S: a full silicon interposer with through-silicon vias, up to about 3.3 times the reticle area (roughly 2,700 mm squared).
- CoWoS-R: a polymer and copper redistribution-layer interposer rather than silicon, in volume since 2023.
- CoWoS-L: local silicon interconnect (LSI) bridges embedded in an RDL interposer, which lets the package grow past the silicon-interposer ceiling.
The same source reports a 3.5-reticle CoWoS-L in volume since 2024 and 5.5-reticle in production in 2026. Tom’s Hardware, in its EMIB-T coverage, cites a TSMC roadmap of 9.5 times reticle by 2027. We treat these roadmap figures as reported rather than confirmed from a TSMC primary document. Nvidia’s Blackwell and Rubin each combine two reticle-sized GPU dies with HBM, which is exactly the integration CoWoS-L exists to deliver.
The binding constraint is capacity. The same guide quotes TSMC’s chairman on the Q2 2026 earnings call saying packaging capacity is so tight that it limits customers’ growth. Tom’s Hardware reports TSMC expanded CoWoS from about 35,000 wafers per month at the end of 2024 to roughly 80,000 by the end of 2025. For a design team the lesson is blunt: a package you cannot get assembled is not a product, so packaging allocation belongs in the architecture review next to die area.
Intel EMIB-T as the alternative
Intel’s Embedded Multi-die Interconnect Bridge embeds small silicon bridges in an organic substrate, avoiding the cost and reticle limits of a full interposer. Standard EMIB had no through-silicon vias, which limited power delivery. EMIB-T adds them, plus integrated metal-insulator-metal capacitors and a ground grid. Per Tom’s Hardware, Intel’s published specification is a 45 micrometre bump pitch with a roadmap to 35 and 25 micrometres, roughly 0.25 pJ/bit efficiency, and UCIe-A interfaces at 32 Gb/s or higher per pin, with support for HBM3, HBM3E and HBM4 and a roadmap to HBM5.
The same article cites Bernstein estimates that EMIB costs in the low hundreds of dollars per chip versus roughly 900 to 1,000 dollars for CoWoS on a Rubin-class accelerator. Treat that as an analyst estimate, not a price list, but the direction is clear: bridges are cheaper per package because they use silicon only where wires are dense. The 0.25 pJ/bit figure is consistent with the consortium’s UCIe-A target of 0.25 pJ/b for rates up to 12 GT/s, although Intel’s number is quoted for its own roadmap.
3D stacking and hybrid bonding
UCIe-3D is the endgame of the roadmap. In 3D, die-to-die wires are distributed over the full overlapping area rather than along an edge, so wire count scales with the inverse square of pitch. The consortium’s targets show how steep that curve is: bandwidth density of about 4,000 GB/s per mm squared at 9 micrometre pitch and 300,000 GB/s per mm squared at 1 micrometre, with energy under 0.05 pJ/b at 9 micrometres and 0.01 pJ/b at 1 micrometre. Because the vertical channel is essentially zero length, the interface can run at up to 4 GT/s with no preamble or postamble on low-power entry and exit.
3D brings its own constraints, listed in the presentation: ESD protection falls to 5 V charged-device-model at introduction and lower beyond, wafer-to-wafer hybrid bonding may permit no ESD at all, and micro-bumps cannot be probed, which is why UCIe 2.0 invested in test and debug. Orientation options include face-to-face, face-to-back, back-to-back and multi-stack. For AI accelerators, the near-term use is memory or cache stacked on logic; this tracks with Tom’s Hardware’s mention of a 2026 d-Matrix design stacking an accelerator directly on custom DRAM. We have not verified the specifics of that product here.

Figure 4: Decision flow for picking UCIe flavour and packaging for an AI accelerator, driven by reticle need, die-to-die traffic, stacking and packaging capacity.
Decision matrix
| If your constraint is | Prefer | Why |
|---|---|---|
| Cost and long reach (under 25 mm) | UCIe-S on organic substrate | Largest bump pitch, no interposer, 0.5 to 0.75 pJ/b targets |
| Die-edge bandwidth, 2 mm reach | UCIe-A on CoWoS-S, CoWoS-L or EMIB-T | 25 to 55 um pitch and 0.25 to 0.5 pJ/b targets |
| Maximum density and lowest energy | UCIe-3D with hybrid bonding | Area-distributed wiring, under 0.05 pJ/b at 9 um |
| Package area beyond about 3 reticles | CoWoS-L or EMIB-T | Bridges avoid a single large interposer |
| Packaging supply risk | Dual-source design on bridges where possible | Capacity, not silicon, is the bottleneck |
Figure 4 encodes the same logic as a flow. Start by asking whether you need more than one reticle at all, since a monolithic die plus HBM remains simpler. Only then do traffic volume, stacking and packaging supply decide the flavour.
A Real Example: Rebellions Rebel 100
Few shipping or announced accelerators publicly advertise UCIe, because the interconnect sits inside the package and companies are free to disclose or not. ServeTheHome noted at Hot Chips 2025 that the consortium’s usual answer to “where are the products” is exactly that. Rebellions is an exception. Its Rebel quad-chiplet accelerator uses four compute dies, four HBM3E sites for 144 GB, and UCIe-A, on Samsung’s SF4X process with CoWoS-S and integrated silicon capacitors, per ServeTheHome’s report.
Tom’s Hardware, summarising the ISSCC 2026 paper, says each die is about 320 mm squared, that Rebellions built an internal two-dimensional mesh network-on-chip that extends across the UCIe links, and that it did not adopt CXL-based protocols, using its own configurable DMA subsystem instead. The article also notes the design does not use UCIe 1.0 to its full extent. That is the typical pattern: adopt the standard PHY and adapter for interoperability and tooling, then layer a proprietary fabric on top.
Rebellions’ performance claim against Nvidia’s H200 comes from the company via ISSCC coverage and should be read as a vendor claim until independently benchmarked. The architectural lesson stands regardless: four small dies, an open die-to-die PHY and a standard interposer package are enough to build a credible accelerator without a reticle-sized die.
Trade-offs, Gotchas, and What Goes Wrong
The standard removes some risk and adds others. These are the failure modes that matter in practice.
Interoperability is narrower than the logo suggests. UCIe interoperability is guaranteed for a defined set of parameters, and the consortium’s compliance work is an initial framework for physical, adapter and protocol testing. Two dies that both claim UCIe-A but chose different module widths, bump maps or protocol modes may not link. Many shipping designs are captive: both dies come from one vendor. Open chiplet marketplaces remain mostly a promise.
Bump maps are a package-level contract. Synopsys’ observation about receiver bumps routing under transmitter bumps shows how a physical-layer detail turns into a package-routing problem. A silicon interposer offers a limited number of signal layers; the CoWoS-S example cited in that article allows up to 8. Every extra signal layer consumed by die-to-die routing is one fewer for HBM or power.
Thermal and power coupling. Packing more silicon into a package with HBM stacks beside hot compute dies produces hot spots and thermal gradients. UCIe 3.0 added fast throttle and emergency shutdown precisely because chiplets from different vendors on different nodes each have their own junction limits. A shutdown path between dies is now a required piece of architecture, not a nice-to-have.
Test and yield compound. Splitting a design improves die yield but adds assembly yield: if any of N dies or any of M bonds fails, the package fails. Known-good-die screening cost and rework strategy decide whether the net result is positive. For 3D bonding, where micro-bumps cannot be probed, this is harder still.
Packaging capacity. Both Tom’s Hardware and Inside Deep Tech describe CoWoS capacity as the limiter. A design committed to CoWoS-L at 5.5 or 9.5 reticles competes for the same slots as every other flagship.
Latency and software. A die-to-die hop adds latency compared to on-die wires. Schedulers and compilers that treat the package as a flat mesh can hit unexpected bandwidth cliffs when traffic crosses a die boundary. If you compile for such hardware, model the cut explicitly. Memory pooling across devices raises related questions covered in our post on CXL memory pooling and tiering.
Anti-pattern: designing to the headline GT/s. A link specified for 64 GT/s that lands on a poor channel will train down or burn extra equalisation power. Budget to the channel, not the logo.
Fast-moving numbers. HBM4 pin speeds, stack heights and base-die features are moving quickly. Anything quoted from vendor press releases, including the figures in this article, should be re-checked against current datasheets before use in a design.
Practical Recommendations
If you architect accelerators, start from the cut rather than the interface. Identify the cheapest places in the dataflow to split and measure the actual traffic that would cross each one. Use the shoreline arithmetic in the worked section to convert that traffic into modules and millimetres. Then choose the flavour, not the other way round.
Choose UCIe-A over an advanced package when the cut needs multiple terabytes per second. Choose UCIe-S when traffic is I/O-class and cost dominates. Treat UCIe-3D as a roadmap item unless you already have hybrid-bonding access. Keep HBM stack count and package size under the same budget, since memory consumes more edge than the compute cut.
If you evaluate accelerators rather than build them, ask vendors which UCIe version and data rate the package uses, whether links are captive, and which package technology and supply path they depend on. Memory bandwidth per accelerator is only half the picture; package-level bandwidth and yield behaviour determine supply and price.
A short checklist:
- Quantify die-to-die traffic per cut in TB/s per direction before picking a PHY rate.
- Convert to modules and millimetres of shoreline at 32, 48 and 64 GT/s and compare against die perimeter.
- Budget interconnect energy at the consortium target pJ/b, then re-budget at 2x for margin.
- Verify HBM4 pin speed, stack height and base-die options with the vendor, not the press release.
- Secure packaging capacity (CoWoS-L, EMIB-T or OSAT) alongside wafer allocation.
- Plan test: UDA, lane repair, KGD screening and thermal shutdown paths.
- Re-verify every figure here against the current UCIe specification and vendor datasheets.
Frequently Asked Questions
What is UCIe and why does it matter for AI accelerators?
UCIe, Universal Chiplet Interconnect Express, is an open standard for die-to-die links inside a package, defined by a consortium founded in 2022. It specifies a physical layer, a die-to-die adapter and protocol mappings for PCIe, CXL or streaming. For AI accelerators it lets designers split large designs across smaller dies, reuse dies across products and mix process nodes, while using a common PHY and tooling rather than a proprietary link.
How fast is UCIe 3.0?
UCIe 3.0, released in August 2025, supports 48 GT/s and 64 GT/s for UCIe-S and UCIe-A, doubling the 32 GT/s of UCIe 2.0. A 64-lane UCIe-A module at 64 GT/s moves 4,096 Gb/s, or 512 GB/s, per direction. It is fully backward compatible with earlier versions, and also adds runtime recalibration, longer sideband reach and extra manageability features.
What is the difference between UCIe and HBM4?
They solve different problems. HBM4 is a JEDEC memory standard (JESD270-4) with a 2,048-bit interface per DRAM stack, delivering 2 TB/s at the 8 Gb/s baseline. UCIe is a die-to-die interconnect for linking logic chiplets. Accelerators typically use both: UCIe or a proprietary link between compute dies, and HBM4 interfaces from compute dies to memory stacks.
What is the difference between UCIe-S, UCIe-A and UCIe-3D?
UCIe-S is for standard organic packages, with 100 to 130 micrometre bump pitch and reach under 25 mm. UCIe-A is for advanced 2.5D packages such as CoWoS and EMIB, with 25 to 55 micrometre pitch, reach under 2 mm and higher density. UCIe-3D is for hybrid-bonded vertical stacks, with pitches under 10 micrometres optimised, and the lowest energy per bit.
How much bandwidth does one HBM4 stack provide?
At JEDEC’s 8 Gb/s per-pin baseline across 2,048 pins, one stack gives about 2 TB/s. Vendor parts run faster: at 11.7 Gb/s the same interface yields roughly 3 TB/s, and Samsung quotes up to 3.3 TB/s at 13 Gb/s. A GPU with eight stacks at those speeds reaches tens of terabytes per second of aggregate memory bandwidth.
Is CoWoS or EMIB better for chiplet accelerators?
Neither wins universally. CoWoS, in S, R and L variants, is TSMC’s proven high-volume platform but capacity is tight and cost is high. EMIB-T embeds silicon bridges in an organic substrate, trading some maturity for lower reported cost and a scaling path to very large packages. Pick based on your foundry, packaging supply, required package area and whether the bridge or interposer matches your UCIe-A bump pitch.
Further Reading
- Micron and the HBM AI memory supercycle: the supply and economics view of the memory behind this interface.
- CXL memory pooling, tiering and Type 3 devices on Linux: how the protocol UCIe can carry behaves at system scale.
- NVLink vs InfiniBand vs RoCE for GPU cluster training: what happens once traffic leaves the package.
- UCIe 3.0 specification announcement, UCIe Consortium: the consortium’s own summary of the release.
- JEDEC HBM4 coverage at eeNews Europe: channel count, pin speed and voltage options for JESD270-4.
By Riju — about
