3. HBM协议栈：DRAM Core、Bank Group、Channel、Pseudochannel架构
好，咱们今天聊聊HBM的协议栈。说白了，就是HBM这颗“内存芯片”内部到底是怎么组织的。你想想看，一个HBM2E的带宽能到460GB/s，这背后靠的就是一套精巧的层级架构。
我个人习惯把HBM的存储架构想象成一个“超级仓库”。DRAM Core是货架，Bank Group是分区，Channel是传送带，Pseudochannel是传送带上的快速通道。嗯，咱们一层层拆开看。
3.1 DRAM Core：最底层的存储单元
DRAM Core就是那个“货架”。它由无数个存储单元（1T1C，一个晶体管加一个电容）组成。每个单元存1bit数据。
这里有个关键点：DRAM Core的访问速度其实很慢。为什么？因为电容会漏电，需要定期刷新。我在项目中遇到过，如果刷新策略没调好，整个系统的有效带宽会直接打七折。
核心参数：
- Row（行）：水平方向，通常8K-32K行
- Column（列）：垂直方向，通常1K-4K列
- Page Size（页面大小）：Row × Column，典型值2KB-8KB
访问DRAM Core时，你得先激活（ACTIVATE）一行，然后才能读写列。这个“行激活”操作很耗时，大概要十几纳秒。所以，尽量连续访问同一行，别老换行——这是优化HBM性能的第一条铁律。
3.2 Bank Group：并行性的第一层
一个DRAM Core太大了，如果只有一个“货架”，大家排队等，效率太低。所以HBM把DRAM Core切分成多个Bank Group。
每个Bank Group内部有4个Bank。Bank Group之间可以并行操作。什么意思？就是你可以同时给Group A发一个读命令，给Group B发一个写命令，互不干扰。
| 层级 | 数量（典型HBM2E） | 并行能力 |
|---|---|---|
| Bank Group | 8个 | 不同Group可并行 |
| Bank per Group | 4个 | 同一Group内串行 |
| Total Banks | 32个 | 最多8个Bank并行（不同Group） |
我曾经调试过一个带宽瓶颈问题，发现所有请求都打到了同一个Bank Group上。嗯，这就是典型的“Bank Group冲突”。解决办法？把数据散列到不同的Bank Group里。说白了，就是让每个Group雨露均沾。
3.3 Channel：真正的数据高速公路
Channel是HBM和外部（比如CMN-HNI）通信的接口。每个Channel有独立的命令总线和数据总线。
HBM2E通常有8个Channel，每个Channel位宽128bit。8个Channel加起来就是1024bit，也就是128字节。这就是为什么HBM带宽那么恐怖——一次能传128字节！
避坑指南：
我曾经以为Channel之间完全独立，结果发现它们共享同一个DRAM Core阵列。如果你在Channel 0和Channel 1同时访问同一个Bank Group，还是会冲突。所以，Channel是逻辑上的独立，物理上还是要看Bank Group的分布。
每个Channel内部有自己的命令队列。HBM协议支持多种命令：
- ACT：激活行
- RD/WR：读/写列
- PRE：预充电（关闭行）
- REF：刷新
命令之间有时间约束，比如tRCD（行激活到列访问的延迟）、tCL（列访问延迟）。这些时序参数直接决定了你能跑多快。
3.4 Pseudochannel：HBM的“隐藏技能”
Pseudochannel（伪通道）是HBM2E引入的一个概念。它把一个Channel从逻辑上分成两个独立的子通道。
为什么需要这个？你想想看，一个Channel 128bit宽，如果你只访问其中64bit，剩下的64bit就浪费了。Pseudochannel允许你独立控制每个64bit子通道的命令和地址。
注意：
Pseudochannel不是物理上的独立通道。它只是把命令/地址总线分时复用。所以，两个Pseudochannel不能同时发送命令，但可以一个发命令、另一个传数据。嗯，这里要注意，时序上要错开。
我建议在低功耗场景下多用Pseudochannel。为什么？因为你可以只激活一个Pseudochannel，另一个保持休眠。带宽需求低的时候，功耗能降30%以上。
3.5 架构总览：一张图说清楚
下面我用一张SVG图把整个层级关系画出来。你一看就明白了。
从这张图你能看到，HBM的架构是层层嵌套的。最上层是Channel，往下是Pseudochannel，再往下是Bank Group，最底层是DRAM Core。每一层都提供了不同的并行度。
3.6 实战中的协同设计要点
好了，理论讲完了。咱们说说实战中怎么用这些知识。
- 地址映射策略：我建议把连续地址映射到不同的Channel和Bank Group上。比如，地址bit[6:4]选Channel，bit[9:7]选Bank Group。这样能最大化并行度。
- 命令调度：HBM的命令队列深度有限。我曾经遇到过命令队列满导致stall的情况。解决办法是提前预判，把ACT命令提前发出去，让数据准备好。
- 刷新管理：DRAM Core需要定期刷新。8K行的话，64ms内要刷完所有行。我建议把刷新操作分散到空闲周期里，别集中刷，否则带宽会断崖式下跌。
- Pseudochannel利用：如果你的数据宽度小于64bit，果断用Pseudochannel。另一个Pseudochannel可以干别的事，或者休眠省电。
核心总结：
HBM的带宽不是凭空来的。它靠的是Channel的宽位宽、Bank Group的并行度、Pseudochannel的灵活性。你设计CMN-HNI接口时，一定要理解这层架构。否则，你写的调度逻辑再漂亮，到了HBM这里也会被“打回原形”。
嗯，今天就聊到这儿。记住一句话：HBM的每一层都有它的脾气，摸透了，你就能榨干它的每一分带宽。