HBM

# HBM Base-Die Logic and DRAM Interface

An HBM stack isn't just DRAM dies stacked on top of each other — sitting at the bottom of every stack is a base die, built on a logic process rather than a DRAM process, whose job is to translate between the host's wide, high-speed HBM interface and the internal signaling the DRAM dies actually use, acting as the stack's single point of contact with the outside world. The DRAM dies stacked above the base die are optimized purely for memory cell density and retention, built on a specialized DRAM process node. The base die, by contrast, is fabricated on a logic process more similar to what a CPU or GPU uses, because its job isn't storing bits — it's routing requests, managing the through-silicon-via connections up into the DRAM dies above it, and presenting one unified interface to the host processor so that the host never has to talk to eight or more separate DRAM dies individually.

Putting the base die on a logic process rather than a DRAM process is a deliberate specialization: logic processes are built for fast, complex switching circuitry, which is exactly what request routing, TSV multiplexing, and interface-protocol logic need, while DRAM processes are optimized for dense, low-leakage storage cells and would make poor logic circuitry. Building the base die on the same process as the DRAM dies above it would force an unfavorable compromise — either the DRAM dies suffer from a process not optimized for cell density and retention, or the base die's logic suffers from a process not optimized for fast switching. Splitting the stack into DRAM-process memory dies and a logic-process base die lets each layer use whichever fabrication process actually suits its job, at the cost of needing a separate die design, separate process line, and a hybrid-bonding or TSV-based interconnect scheme to join the two process families into one stack.

Two Process Families, One Stack each layer uses the process that actually suits its job DRAM dies — DRAM process base die — logic process base die: TSV routing, request translation, unified host interface DRAM dies: pure storage — host never talks to them directly combining process families requires hybrid-bonding/TSV interconnect Specialization at each layer is the point — unification happens at the base die.

Because the base die is the single physical and electrical gateway for every signal entering or leaving the stack, it also increasingly absorbs functions that used to live on the host processor side of the interface — error correction, built-in self-test, and in the most advanced designs even basic in-stack computation close to the memory. Concentrating these functions in the base die, right at the boundary between the DRAM dies and the host, means they can run with minimal added latency compared to handling them on the host side across a slower external interface, and it keeps the DRAM dies themselves simple and process-optimized purely for storage rather than diluting that process with circuitry it was never designed to support efficiently.

The vertical thermal gradient discussed in the previous round explained why DRAM dies at different heights in the stack need different refresh treatment; the base die is the component that actually has to implement and coordinate that per-die refresh scheduling, along with everything else the host expects from a single, simple-looking HBM interface — making the base die the stack's least glamorous but most architecturally central component.

Take HBM further

Ask the copilot about this term, or have our engineers assess it against your process.

Ask CFSGPT about this → Request a technical assessment → Open the CFS app