白话 HBM 第一季第一篇：3D 堆叠架构 TSV 与 Microbumps 互连

Ne0inhk

15 Mar 2026 — 22 min read

前言：

为什么内存颗粒越来越贵？

最近两件科技热门大事：一个是 AI 大模型的疯狂爆发，另一个就是随之而来内存颗粒价格的史诗级暴涨。

如果你关注过 NVIDIA 的 H100 或 B200 这些“算力怪兽”GPU，你会发现它们抢手的核心原因，除了那颗强大的 GPU 核心，更在于旁边那几颗不起眼的黑色方块——HBM (High Bandwidth Memory)。它现在已经成了AI 芯片的“硬通货”，不仅产能被抢空(三天一失火，五天一地震)，价格更是水涨船高。

那么，到底什么是 HBM？它作为内存，和我们在电脑里插的 DDR、手机里用的 LPDDR 到底有什么区别？

说白了，它们都是存储数据的“仓库” (DRAM)，核心的基本单元都是电容和晶体管，都要不停地刷新（Refresh）来保住数据。但它们的“建房子”方式完全不同：

DDR/LPDDR 像是“平房”或“别墅”：它们平铺在主板上，为了承载更多，拼命扩展平房面积（提高频率）。但受限于主板的布线空间，单层面积虽然大，但立体空间利用率却很小（通常只有 32 或 64 bit）。这适合 CPU 这种需要快速响应、但数据量没那么恐怖的场景。
HBM 则是市中心的“摩天大楼”：HBM 也就是我们今天要讲的主角，它不走“摊大饼”的路线，而是搞 3D 堆叠。它利用 TSV（硅通孔）技术，把一层层的内存芯片像盖楼一样垂直叠起来，然后在楼层之间打通成千上万部“垂直电梯”。这就是 HBM 的架构精髓： HBM 一口气修了 32 层大楼，拥有1024bit（HBM3支持最大1024bit——16channel * 64bit）。

为什么 AI 非要用 HBM？

现在的 AI 大模型参数动辄几千亿，计算量大得吓人。GPU 的计算核心就像一个大胃王，传统的 DDR 就像是用小勺子喂饭，根本喂不饱，GPU 大部分时间都在饿着肚子等数据。

而 HBM 凭借那 1024 条车道的恐怖位宽，就像是直接拿消防栓管子往 GPU 嘴里灌数据。只有这样，才能跟得上 AI 时代的算力需求。正因为这种“不可替代性”，HBM 才成了限制 AI 算力的最大瓶颈，也成了最近内存涨价的幕后推手。

在这个系列中，我们将剥开 HBM 高昂价格的外衣，从工程视角，深入到底层物理架构和数字逻辑，看看这座“摩天大楼”到底是怎么盖起来的，作为检验者，该从何验证。目录如下：

第一篇，我们就从3D 堆叠技术讲起 (本篇前3节是物理工艺层面的拆解，后3节为逻辑层面)。

本文部分图片由AI生成，请注意甄别~~

1. 概述：打破“内存墙”的 KGSD 形态

在摩尔定律放缓、算力需求却呈指数级爆炸的今天，传统的存储架构正面临严峻的“内存墙（Memory Wall）”挑战。GDDR 显存试图通过极高的频率（20Gbps+）来换取带宽，但随之而来的是难以遏制的功耗与发热；DDR 内存受限于 PCB 板级布线的密度极限，通道位宽难以突破 64-bit。

HBM (High Bandwidth Memory) 的诞生，本质上是一场“空间换时间”的革命。它不再执着于在平面上提升单根信号线的速度，而是通过 3D 垂直堆叠 技术，增加 channel 数量来拓宽最大单次传输数量——1024 bit 。

1.1 KGSD：已知合格堆叠芯片

在 JEDEC JESD235 标准中，HBM 被定义为 KGSD (Known Good Stacked Die)。

术语详解：

Known Good (已知合格)：指在进行昂贵的 3D 堆叠封装之前，每一层 DRAM 裸片（Die）都必须经过极其严格的晶圆级测试（Wafer Sort/Probe），确保是 100% 的良品。因为一旦堆叠完成，中间只要有一层是坏的，整个昂贵的 HBM 堆栈就报废了（且不可拆解）。
Stacked Die (堆叠裸片)： 指其物理形态不再是封装好的黑色芯片颗粒，而是直接裸露的硅片（Die）进行垂直键合。

1.2 物理载体：2.5D 封装与 Interposer

HBM 无法直接焊接在普通的 PCB 主板上，因为 PCB 的布线工艺（蚀刻精度在毫米/亚毫米级）无法支撑 HBM 所需的微米级高密度互连。因此，HBM 必须依赖 2.5D 封装技术（如台积电的 CoWoS）。

术语详解：Interposer (硅中介层)

介绍：这是一个位于 HBM/GPU 和底部基板之间的一层薄薄的硅片。它没有晶体管，但内部通过半导体光刻工艺制造了极其密集的金属走线，称为 RDL (Redistribution Layer，重布线层)。
作用：它是 HBM 的“物理底座”。HBM 的 1024 根数据线正是通过 Interposer 上的微米级走线，横向连接到旁边的 Host (GPU/ASIC) 芯片上。

1.3 堆叠高度与容量密度

如果说 TSV 是大楼的电梯，那么 "N-Hi" 就是这座大楼的层数。经常在听到的 "HBM3E 12-Hi"，指的就是由 12 层 DRAM Core Die 堆叠而成的颗粒。

层数的进化 (Stacking Height)：

初期 (HBM1/2)： 主要是 4-Hi 或 8-Hi。那时候就像盖普通居民楼，层数不多，工艺相对宽松。
主流 (HBM3/3E)： 已经全面普及 8-Hi 和 12-Hi。
未来 (HBM4)： 正在向 16-Hi 甚至更高发起挑战。

物理极限的挑战 (Z-Height Constraint)：

或许你会问：“为什么不直接堆 100 层？” 因为标准限制了总高度。为了适配 GPU 的散热器和封装标准，HBM 封装后的总厚度是有严格限制的（通常在 720um 左右）。这就逼迫晶圆厂练就了绝技——晶圆减薄。为了在同样的高度里塞进 12 层甚至 16 层，每一层 DRAM Die 都要被打磨得薄如蝉翼。稍有不慎，晶圆就会碎裂或卷曲，这也是 HBM 良率低、价格贵的核心原因之一。

容量密度的飞跃 (Density)：

堆叠层数越多，单颗 HBM 的容量就越大（即 Density）。

8-Hi HBM3： 单颗容量通常为 16GB。(单层密度为16GB / 8 = 2GB，16Gb)
12-Hi HBM3E： 单颗容量达到了 24GB。
16-Hi HBM4： 预计单颗容量将突破 36GB - 48GB。 这对 AI 意味着什么？ 一块 B200 GPU 周围贴了 8 颗 HBM3E (12-Hi)，总显存容量就能达到 192GB。这意味着它能一次性装下参数量更大的大模型，减少了 GPU 和 CPU 之间慢吞吞的数据搬运，效率直接起飞。

2. 垂直互连核心：TSV (Through-Silicon Via) 信号通路

如果说 Interposer 解决了 HBM 与外部的连接，那么 TSV 就是 HBM 内部的灵魂。在前端架构师的眼中，TSV 不仅仅是物理连线，更是一条贯穿所有 Core Die 的全局总线。

2.1 什么是 TSV？

TSV (Through-Silicon Via，硅通孔) 是一种穿透硅晶圆的垂直互连技术。

技术原理：

传统的芯片只有表面一侧有金属连线。而 TSV 工艺是在硅片上打出成千上万个直径仅为数微米的深孔，并在孔内填充铜、钨等导电金属，使得信号可以直接从芯片的正面“穿透”传导至背面。

前端视角：

共享总线拓扑。在 HBM 堆叠中（例如 8-Hi 堆叠），8 层 Core Die (颗粒) 在垂直方向上是对齐的。贯穿它们的 TSV 形成了一条共享总线。

信号广播： 当底部的 Base Die 驱动命令信号（Command）时，该信号会沿着 TSV 瞬间同时到达第 1 层至第 8 层 Core Die。
负载效应： 前端设计必须考虑这条总线的容性负载。堆叠层数越高（如 HBM3E 的 12-Hi/16-Hi），TSV 上的寄生电容就越大，这直接限制了信号传输的最高频率，也对驱动能力提出了极高要求。

2.2 信号分类与 TSV 分布

一个 HBM 堆栈中包含数千个 TSV，它们分工明确：

数据 TSV (DQ/DQS)： 负责传输海量的读写数据。
命令/地址 TSV (Row/Col Command)： 负责传输控制指令。
电源/地 TSV (VDD/VSS)：这是极其关键的设计。 HBM 的电流密度极高，大量的 TSV 被用作电源通道，以降低 IR Drop（电压降），确保每层芯片都能获得稳定的电压。

3. 微缩接口：Microbumps (微凸块) 阵列

TSV 解决了“穿透”问题，而 Microbumps 解决了层与层之间的“粘连”与电气导通问题。

3.1 从 C4 Bump 到 uBump

在传统的倒装芯片（Flip-Chip）封装中，使用的是 C4 Bump，直径通常在 100um 左右。而 HBM 为了在极小的面积内引出上千个信号，使用了 Microbump (uBump)。

3.2 信号定义与前端映射

对于前端设计人员，Microbump 阵列直接对应着 HBM PHY 的引脚定义（Pinout）。

中心信号区： 大部分数据和命令信号集中在芯片中央。
屏蔽与隔离： 高速信号的 Microbump 周围通常会环绕接地（VSS）Bump，起到电磁屏蔽作用，减少串扰（Crosstalk）。

4. 逻辑中枢：Base Die (Logic Die) 的深度剖析

这是本篇的重点部分。HBM 之所以能工作，不仅靠堆叠，更靠最底层的 Base Die (可以理解为颗粒的TOP层总线管理，DDR没有)。

Base Die 是 HBM 区别于普通 3D DRAM 的核心特征。 它通常采用逻辑工艺（Logic Process）制造，而非 DRAM 工艺。它充当了 HBM 堆栈的网关、路由器和大脑。

4.1 物理层接口 (PHY Interface)

HBM 标称的 1024-bit 数据接口，物理上是由 Base Die 驱动的。

设计逻辑：

DRAM Core Die 的工艺擅长做高密度的电容（存储），但不擅长做高速、大电流的 IO 驱动电路。因此，HBM 架构将 外部接口驱动 (PHY IO) 全部移到了 Base Die 上。

信号流向：

Write: SoC (DDRC) -> Interposer -> Base Die (RX 接收 -> Retiming 重整 -> TX 驱动) -> TSV -> Core Die (颗粒)。
Read: Core Die -> TSV -> Base Die (RX 接收 -> Retiming 重整 -> TX 驱动) -> Interposer -> Host。

Retiming (重定时)：

实质就是时序对齐。由于信号经过长距离传输（相对微观尺度）会有衰减和抖动。Base Die 会利用内部的时钟树，对信号进行整形和重新对齐，确保传给上层 Core Die 的信号是干净、时序精准的。

4.2 寻址逻辑：SID (Stack ID)

既然 TSV 是共享总线，当 Host 发送一个“写”命令时，所有 8 层 Core Die 都收到了，怎么确保只有第 3 层写入，而其他层忽略？

这就涉及到了 HBM 独特的 SID (Stack ID) 机制。

硬件编码：

在堆叠制造时，通过改变层间 Microbump 的连接方式，物理上赋予每一层 Core Die 一个唯一的二进制 ID（例如 000, 001, ... 111）。

片选逻辑 (Chip Select Logic)：

前端控制器发出的地址中，包含 Bank Address。
HBM 内部逻辑会将高位的 Bank 地址映射为 SID。
比较器： 每一层 Core Die 内部都有一个数字比较器。它将总线上的目标 SID 与自己的硬件 SID 进行比对。
- Match: 激活输入/输出 Buffer，响应命令。
- Mismatch: 保持 Z 高阻态，就像自己不存在一样。

4.3 修复与测试中枢 (Repair & DFT)

Base Die 是 HBM DFT (Design for Test) 的核心。

IEEE 1500 控制器： HBM 没有引脚可以接传统的探针测试，必须通过 IEEE 1500 协议（一种片上测试标准）进行访问。Base Die 内部集成了 1500 Slave 控制器。
Lane Repair Crossbar： HBM 有 1024 根数据线，断几根在所难免。Base Die 内部有一个巨大的数字交叉开关矩阵（Crossbar Switch）。如果发现 TSV #5 坏了，可以通过烧写 Fuse（熔丝），命令 Crossbar 自动将数据流从 TSV #5 切换到备用的 Redundant TSV 上。这一切都是在 Base Die 的数字逻辑中完成的。

5. 通道架构：1024-bit 的高速车道

HBM 的“高带宽”并非来自单根线的极高速度，而是来自“车道数量”。

5.1 通道独立性 (Channel Independence)

HBM3 将 1024-bit 的总位宽划分为 16 个物理通道 (Channels)，而且可以开启伪通道 (Pseudo channel, PC)模式，单个 Channel 可以分为2个独立的 Pseudo channel (PC)，DQ各32bit，因此HBM3拥有独立的32个 Pseudo channel。

设计哲学： HBM 不像 DDR 那样是一个单一的 64-bit 设备，它是 16 个独立的 64-bit Memory 被封装在了一起。
完全隔离： 每个 Channel 的 PC0 和 PC1 ，拥有完全独立的时钟（CK）、命令（Cmd）、地址（Addr）和数据（DQ）。这意味着：你可以让任意 Channel 的 PC0 执行写操作，同时让其他任意 PC 执行刷新（Refresh），互不干扰。这对于 GPU 这种需要大规模并行吞吐的应用至关重要。

5.2 AWORD 与 DWORD 分离

为了进一步提升效率，HBM 在协议层和物理层都采用了 Row/Col 分离架构。

AWORD (Address Word)： 专门的总线，只传输激活（Activate）和预充电（Precharge）Row 命令。
DWORD (Data Word)： 专门的总线，只传输读（Read）和写（Write）Column 命令。
优势： 在传统 DRAM 中，Row 和 Col 命令共用一条总线，发 Row 命令时就不能发 Col 命令（产生 Bubble）。HBM 这种分离设计允许 Row 命令和 Col 命令在同一时钟周期内并行发送，极大提升了总线利用率。

6. 验证视角：驾驭“怪兽”的艺术 (Subsystem & SoC Level)

讲了这么多物理结构，对于身处芯片设计公司（Fabless）的验证工程师来说，我们的战场并不在 HBM 颗粒内部（那是颗粒厂商的事），而在 SoC 内部。我们的 DUT 是 HBM Memory Controller (MC) 和 PHY。

对于子系统验证的基本框架，可继续沿用DDR/LPDDR的验证框架，如下：

以下是 HBM 子系统级验证的部分复杂验证点：

6.1 协议握手与固件协同：黑盒

HBM 的 PHY 通常是一个高度封装的“黑盒”，内部往往自己配置有初始化(initialization)和训练(training)用的引擎(engine)，用户仅需要打开特定指令即可。这使得验证的重心从物理层时序转移到了DFI 协议的交互与固件的协同。

核心点：DFI 总线控制权的“踢皮球”

HBM 的训练过程中，PHY 会频繁地要求接管地址和命令总线（因为它要自己发 Pattern 给颗粒，不需要 Controller 干预）。这在 DFI 协议中体现为 PHY 主动发起的 Update 请求。
DFI 细节： 关注 dfi_phyupd_req (PHY Update Request) 和 dfi_phyupd_ack 的握手。

风险：

当 Controller 正在疯狂发读写命令时，PHY 突然拉高 dfi_phyupd_req 说“我要训练了，把总线给我”。
这时 Controller 必须立刻暂停当前传输，排空流水线，然后回 ack。
HBM 的特殊性： 由于 HBM 通道多、频次高，这种“业务流”与“训练流”的冲突概率极高，非常容易导致死锁。

6.2 复杂的时序要求

虽然 HBM 把物理通道切得很碎（32个独立 PC），但每一个 PC 本质上还是一颗标准的 DRAM。它依然受限于电容充放电和读写放大器的物理特性，也就是我们熟悉的 tRCD (行激活时间)、tCL (列潜伏期)、tRP (预充电时间) 等 JEDEC 时序参数。

然而，HBM 对这些时序的敏感度远超 LPDDR/DDR。

差异点：

DDR 如果调度不好，浪费几个周期可能只损失几 Byte 数据。但 HBM 拥有 1024-bit 位宽，浪费一个时钟周期（Bubble），就意味着损失 128 Bytes 的带宽。在 AI 训练这种争分夺秒的场景下，这是不可接受的。

核心点 1：读写切换的效率损失

DRAM 的数据总线是双向的（半双工），读和写不能同时进行。

时序约束： 从写（Write）切换到读（Read），中间必须等待 tWTR (Write to Read Delay) 时间，这期间总线是空闲的。
调度策略： HBM Controller 不会来一个命令发一个，而是采用 “读写分组” (Read/Write Grouping) 策略。它会囤积一批写命令一口气发完，再切换方向一口气发读命令，从而将 tWTR 带来的总线空闲（Bubble）分摊到最小。
验证策略： 构造“读写交替”的 Worst Case 流量。检查 Controller 的 Reordering（乱序）逻辑 是否生效，能否自动将读写命令聚类？如果波形上全是密密麻麻的 Turnaround Gap，说明 Controller 的调度策略一般。

核心点 2：Bank Group 的“无缝”拼接 (tCCD_S vs tCCD_L)

HBM 为了提速，引入了 Bank Group (BG) 架构。

时序约束：
- 连续访问同一个 BG，中间必须等待较长的 tCCD_L（Long）。
- 连续访问不同 BG，中间只需要等待极短的 tCCD_S（Short）。
调度策略： Controller 必须具备极强的地址感知能力。它需要动态调整命令顺序，尽量让连续的命令打在不同的 Bank Group 上（Ping-Pong 操作），以维持数据总线的 100% 占空比。
验证策略： 验证 Controller 的 Arbiter（仲裁器）。如：当同时有“访问 BG0”和“访问 BG1”的请求时，Arbiter 是否优先选择了“访问 BG1”来填补 tCCD_L 的等待间隙？

核心点 3：写后读 (Read-After-Write, RAW) 的数据一致性 这是逻辑正确性的底线。

场景： 既然 Controller 会为了性能搞“乱序执行”，那么如果 CPU 先发了一个 Write (Addr=A)，紧接着发了一个 Read (Addr=A)，而 Controller 为了凑 Bank Group 居然把 Read 提前执行了，那读回来的就是旧数据（脏数据）。（这个场景，AXI这边发出的命令肯定有先后顺序，但是到controller内部，可能会被放到并列队列里，这样controller就会有可能为了性能，而做出错误判断。）
验证策略： 必须在 Scoreboard 中严格检查 Data Coherency（数据一致性）。Controller 内部必须有冒险Check 逻辑：对于地址发生碰撞（Collision）的命令，绝对禁止乱序，必须强制插入等待，严格遵守先写后读。

因此，HBM 的时序验证不仅仅是检查有没有违规报 Violation，还涵盖了验证 Controller 的调度管理。

6.3 性能验证：如何喂饱 32 张嘴？

HBM3 最大的架构特点就是拥有 32 个伪通道 (Pseudo Channels)，对接16个 DFI 接口，32个 AXI 接口。相比于 LPDDR 只有 2-4 个通道，HBM 的通道数量是一个数量级的飞跃。验证的核心挑战不在于“通不通”，而在于“满不满”。因此需要关注：

地址哈希 (Hashing) 的均衡性：SoC 发出的连续 AXI 流量，经过 Controller 的 Hash 算法后，必须均匀地“洒”向 32 个通道。
验证策略： 需要通过 Performance Monitor 统计每个 PC 的带宽利用率。如果 Hash 算法设计得很烂，导致流量全挤在 PC0-PC3，而 PC4-PC31 在围观，那么 HBM 的高带宽优势就会瞬间崩盘。
Bank Conflict 与 QoS：构造极端的 Traffic Pattern（例如频繁访问同一 Bank 的不同 Row），制造 Bank Conflict。检查 Controller 的 Reordering (乱序) 能力和 QoS (服务质量) 调度策略，确认在高压下高优先级的 Read 请求是否会被 Block 住。

6.4 可靠性 (RAS)：不仅纠错，还要报警

HBM 主要服务于 AI 和 HPC 场景，这些场景对数据错误是零容忍的。因此，RAS (Reliability, Availability, Serviceability) 是 HBM 验证中比重极高的一环。

Poison 传播机制

这是 AI 芯片的关键特性。如果 HBM 颗粒内部读出了不可修正的错误（UE），Controller 绝不能仅仅是丢弃或“装死”。

验证策略：在 VIP 端注入 UE 错误，验证 Controller 是否能通过 AXI 总线返回一个 Poison / Slave Error 响应。必须确保这个“有毒”的标记能一路传导给 GPU/CPU 核心，防止 AI 模型用错误的数据训练出荒谬的结果。

Sideband(Mac) ECC

验证 Controller 能否通过 DFI 接口上的 Sideband 信号，校验出传输链路上 Data/ECC 的 1bit/2bit 翻转，并触发对应的纠错或中断上报逻辑，这里可以用 VIP 的 callback 来注错。

此外还包括 On-Die Ecc 和 CA/DQ Parity 的错误检测，Controller 内部错误计数器和中断是否及时与有效。

6.5 流量控制：在大坝决堤前关闸

HBM 的物理侧数据速率极高（6.4Gbps+），而 SoC 内部总线频率通常较低。这中间巨大的带宽差全靠 Controller 内部的异步 FIFO 在扛。

阈值 & 反压

验证策略： 在数据吞吐量打满（100% Load）且 HBM 正在执行 Refresh（无法响应读写）的极端工况下，检查 Controller 内部的 FIFO 是否会 Overflow。
反压机制：当 FIFO 快满时，Controller 能否及时拉低 AXI 的 READY 信号，让 SoC 端的 Master 暂停发数？如果反压逻辑慢了一拍，数据就会直接丢失，造成致命的系统错误。

对于验证工程师，HBM 不是一个简单的存储器，而是一个高并发、高延迟、带智能固件的独立子系统，目标是确保 SoC 的逻辑（MC）能合理指挥这个32 PC 和 1024 bit 的大内存。

写在最后

笔者刚做HBM不久，和大家同步学习，若读者发现文中逻辑有问题，请果断指出！共同进步！谢谢支持！

下期预告：HBM 通道架构 —— Pseudo Channel

1024-bit 位宽并非是大家同步走的大马路，那样一旦堵车全线瘫痪。下篇将展开讲解HBM 如何利用 Pseudo Channel（伪通道）技术，把这 1024 条车道切分成 32 个独立运行的超高速马路，实现“Channel A 在写数据，Channel B 在刷新”，互不干扰，榨干每一滴带宽。

谢谢支持，敬请期待！