Tharunya Yogananda and Wantong Li of the University of California, Riverside posted a November 2026 arXiv preprint modeling four ways to split an HBM4 controller between host processor and base die.

Moving controller functions into the memory stack, and replacing the wide host interface with a narrow die-to-die (D2D) link, would free host die area and edge space for compute. According to the abstract1, replacing the wide interface with a D2D link saves 61% of host shoreline and 16.85 mm² of host area per stack.

The saving has a latency cost. A provisioned D2D link preserves per-stack bandwidth but adds about twice its one-way delay to unloaded latency, the abstract says. The paper is titled "Beyond Host-Side Control: HBM Controller Partitioning Across Host and HBM Base Dies." Its reported results come from simulation and modeling. The figures in this article are those stated in the abstract. The arXiv comments field lists acceptance to the IEEE International 3D Systems Integration Conference (3DIC). That is the authors' own listing and does not verify peer review.

Background

HBM4 allows the base die of a memory stack to be built in a logic process that can hold more complex controller functions next to the DRAM, the authors write. Some custom HBM designs already use that logic to replace the wide interface with a narrow D2D link, according to the paper's introduction2. The authors say industry disclosures report the outcome of those designs without a function-level placement comparison, and they describe theirs as the first systematic quantitative study of function-level placement.

The introduction also gives reasons the question is sharper for taller stacks. It says taller stacks run hotter and hold more banks, so they refresh more often and carry more maintenance per channel. It adds that several compute dies may share one stack, which a controller inside the stack could serve.

Four placements

The authors divide the controller into five components: front end, transaction queues and data buffers, scheduler, maintenance engine and error-correction (ECC) logic. They evaluate four placements:

  • P0: the host holds the complete controller and the wide interface.
  • P1: refresh and RowHammer-protection maintenance move to the base die, and the wide interface stays.
  • P2: a narrow D2D link replaces the wide interface, and the base die holds the scheduler, data buffers and maintenance engine.
  • P3: the base die holds the complete controller.

P2 and P3 carry the same link traffic and differ in how area and power divide between the two dies, according to the paper.

Results and conditions

The abstract reports that maintenance moves to the base die with no bandwidth cost and frees host command slots, and that the freed share grows with stack height. It says the D2D link dominates the added base die area and power. It also says the base die runs cooler under streaming when link energy is below 0.4 pJ/bit. Shared control delivers up to 1.72x the throughput of static partitioning between two requestors, the abstract says; the comparison is between two requestors.

The area and shoreline savings depend on modeling choices described in the paper's experimental setup2. The authors synthesize controller logic in a 45-nm library and project area and power toward a 14-nm node. They take the wide HBM4 PHY and D2D module areas from bump-limited footprint estimates. They simulate one 64-bit channel with two pseudo-channels and scale stack quantities to 32 channels.

Temperature is not simulated directly. The paper computes peak DRAM temperature as a loaded host-controller baseline plus the base die's power change multiplied by a thermal resistance, and it sweeps both inputs over published ranges for each stack height.

The paper is arXiv v1; the arXiv page lists no independent review or replication.