HBM 메모리 컨트롤러 분석 — Bank·Row·Column·Address Mapping·Scheduling

#한 줄 요약

**“메모리 컨트롤러가 bank parallelism을 짜내는 정도가 sustained BW의 80~95%를 결정합니다.” — bank·row·column 계층, command scheduling, address XOR mapping, per-bank refresh가 모두 컨트롤러의 책임입니다. 같은 HBM3 stack이라도 *컨트롤러 설계가 미숙하면 효율이 50%*로 떨어집니다.

Ch 6에서 HBM의 전력과 열을 봤습니다. 이번 장은 컨트롤러가 HBM을 어떻게 보는지입니다. DRAM 명령 인터페이스, bank scheduling, address mapping은 NPU/GPU 설계의 차별화 지점이기도 합니다. NVIDIA·AMD·Google·Rebellions가 같은 HBM3 stack을 쓰면서도 다른 효율을 내는 이유가 컨트롤러 IP에 있습니다.

#컨트롤러가 보는 HBM

컨트롤러 입장에서 HBM3 stack 1개는 다음 주소 공간입니다.

1
HBM3 stack 주소 계층
2

3
stack (1024-bit)
4
├── Channel 0 .. Channel 15  (16 channel)
5
│   └── Pseudo Channel 0, 1
6
│       └── Bank Group 0 .. 3 (HBM3)
7
│           └── Bank 0 .. 3
8
│               └── Row 0 .. 32767  (16 Gb DRAM 기준)
9
│                   └── Column 0 .. 1023
10
│                       └── prefetch 8 byte burst
11

12
주소 비트:
13
[Channel : 4][PC : 1][BankGroup : 2][Bank : 2][Row : 15][Column : 6][Byte : 6]
14
                                                                       ↑
15
                                                              burst boundary

총 bank 수는 16 channel × 2 PC × 4 BG × 4 bank = 512 bank입니다. 512 outstanding request가 이론상 동시 가능합니다.

#DRAM 명령 인터페이스

컨트롤러가 HBM에 보내는 기본 명령은 다음과 같습니다.

1
HBM3 commands
2

3
  활성화
4
  ACT  (Activate)        : row를 sense amp에 올림
5
  PRE  (Precharge)       : row를 닫고 bit line 충전
6
  PREA (Precharge All)   : 모든 bank precharge
7

8
  데이터
9
  RD   (Read)            : column 읽기 (burst 8)
10
  RDA  (Read + AutoPre)  : 읽고 자동 precharge
11
  WR   (Write)           : column 쓰기
12
  WRA  (Write + AutoPre) : 쓰고 자동 precharge
13

14
  Refresh
15
  REFab (All-bank)       : 모든 bank refresh
16
  REFsb (Single-bank)    : 한 bank만 refresh
17
  REFpb (Per-bank)       : 지정 bank refresh
18

19
  Mode
20
  MRS   (Mode Register)  : config 변경
21
  ZQCAL (impedance cal)  : on-die termination 조정
22
  RFM   (Refresh Mgmt)   : Row Hammer 대응

명령 사이에는 minimum timing constraint가 있습니다.

1
주요 timing parameter (HBM3, 3.2 GHz clock)
2

3
tRCD  (ACT → RD/WR latency)         : 15 ns (~48 clock)
4
tRP   (PRE → ACT latency)            : 15 ns (~48 clock)
5
tRAS  (ACT → PRE 사이 최소)          : 32 ns
6
tWR   (WR → PRE recovery)            : 18 ns
7
tRC   (ACT → ACT 같은 bank)          : tRAS + tRP = 47 ns
8
tCCD_L (RD → RD same bank group)     : 4 clock
9
tCCD_S (RD → RD different BG)        : 2 clock  ← 빠른 인터리브 가능
10
tFAW  (4개 row activation 윈도)      : 30 ns

핵심 통찰은 tCCD_L < tCCD_S입니다. 다른 bank group끼리 인터리브하면 명령 발행 간격이 2 clock까지 줄어 bus utilization이 최고치가 됩니다.

#Scheduling — Open vs Closed Page

같은 row를 계속 열어 둘지(Open) *바로 닫을지(Closed)*가 핵심 정책 선택입니다.

Open Page Policy — 같은 row를 열어 두고 여러 column을 연속 read. row hit이면 tCL만 필요. row miss 시 PRE → ACT로 새 row 진입.

1
ACT row=R
2
RD col=0
3
RD col=1
4
RD col=2
5
RD col=3
6
RD col=7
7
PRE
8
ACT row=R'

• 장점: row hit 비율이 높으면 latency 짧음
• 단점: row miss 시 tRP + tRCD = 30 ns 추가

Closed Page Policy — 한 번 읽고 바로 auto-precharge로 닫음. row buffer locality가 없을 때 단순.

1
ACT row=R + RD col=0 + auto PRE
2
ACT row=R + RD col=1 + auto PRE
3
ACT row=R + RD col=2 + auto PRE

• 장점: row buffer locality 없을 때 simple
• 단점: row hit 가능성 버림

대부분 컨트롤러는 Adaptive Page Policy를 씁니다. 최근 access history를 보고 open할지 close할지 결정합니다.

1
Adaptive page policy 예
2

3
queue를 본 시점에 같은 row 추가 access가 있으면:
4
  open page 유지
5
없으면:
6
  RDA/WRA로 auto precharge
7

8
NVIDIA H100, AMD MI300X 모두 adaptive 사용

#Bank parallelism — 인터리브의 핵심

컨트롤러가 bank parallelism을 짜내는 방식이 *효율의 80%*를 결정합니다.

• Bad — 같은 bank만 hit. 매번 PRE를 기다려야 하고 나머지 511 bank가 idle → BW utilization 6 %.
• Good — 라운드 로빈. 모든 bank가 pipeline으로 동작 → BW utilization 90 %+.

이를 가능하게 하려면 address-to-bank mapping이 균등해야 합니다.

#Address mapping — XOR hash

linear mapping(상위 비트 = bank)은 연속 access에서 bank conflict 다발입니다.

1
Linear mapping (나쁨)
2

3
address = 0x0000_0000 → bank 0
4
address = 0x0010_0000 → bank 1  (1 MB step)
5
address = 0x0020_0000 → bank 2
6
...
7

8
연속 메모리 sweep(matrix scan):
9
  addr[0..N]이 모두 bank 0  ← 한 bank만 hit!

해결책은 XOR hash mapping입니다.

XOR mapping

1
bank_index = addr[bits low] XOR addr[bits mid] XOR addr[bits high]

이 방식의 효과:

• 연속 access가 자동으로 bank 분산
• adversarial pattern을 만들기 어려움
• stride access (matrix column scan)도 분산

1
// 의사 코드: HBM3 컨트롤러 address mapping
2
uint64_t addr;  // 입력 byte address
3

4
// burst boundary 무시
5
uint64_t base = addr >> 5;  // 32 byte burst
6

7
// XOR로 channel 계산 (4 bit)
8
int ch = (base >> 4) & 0xF;
9
ch ^= (base >> 12) & 0xF;
10
ch ^= (base >> 20) & 0xF;
11

12
// XOR로 bank 계산 (4 bit)
13
int bank = (base >> 8) & 0xF;
14
bank ^= (base >> 16) & 0xF;
15

16
// row, column 분리
17
int row = (base >> 12) & 0x7FFF;
18
int col = base & 0x3F;

실제 GPU/NPU 컨트롤러의 XOR pattern은 비공개 IP입니다. workload-specific tuning이 들어가서 AI training pattern에 특히 최적화되어 있습니다.

#Per-bank refresh — bandwidth 보호

전통적인 *all-bank refresh(REFab)*는 모든 bank를 350 ns 동안 stall시킵니다. bus가 통째로 멈춥니다.

1
REFab의 비용
2

3
각 REFab: 350 ns × bus 정지
4
64 ms / 3.9 μs = 16384 REFab per cycle
5
total stall: 16384 × 350 ns = 5.7 ms / 64 ms = 8.9%
6

7
→ 8.9% bandwidth loss

*per-bank refresh(REFpb)*는 한 bank만 refresh합니다. 다른 bank는 계속 일합니다.

REFpb는 한 번에 한 bank만 refresh합니다. 나머지 bank는 그동안에도 active 상태 유지.

• bandwidth loss: 8.9 % / 16 banks ≈ 0.6 %
• 조건: 컨트롤러가 bank별 refresh schedule을 추적해야 함
• HBM3에서 표준 지원

NVIDIA·AMD 컨트롤러는 REFpb를 기본으로 합니다. AI training cluster에서 *0.6 vs 9 %*의 효율 차이가 수십억 원 단위입니다.

#Read-write turnaround

같은 bus 위에서 Read 후 Write나 Write 후 Read는 turnaround penalty가 있습니다.

Turnaround 비용

queue에서 RD/WR가 섞이면 turnaround가 빈번해집니다. batch grouping이 효율적입니다.

좋은 컨트롤러는 RD batch + WR batch 형태로 grouping해 turnaround를 최소화합니다.

queue가 R W R W R W R W로 도착해도 컨트롤러가 R R R R / W W W W / R R R R로 묶어 turnaround를 N번 → 2번으로 줄입니다.

#ECC 처리

HBM3 on-die ECC는 base die가 처리하지만, 컨트롤러도 추가 ECC를 둘 수 있습니다.

NVIDIA H100은 system-level ECC를 on으로 출하합니다. 데이터센터 신뢰성을 위해서입니다.

#Outstanding request queue

컨트롤러는 수십 개의 outstanding request를 동시에 추적해 bank 별로 schedule합니다.

FR-FCFS는 First-Ready, First-Come-First-Served입니다. 같은 row에 있는 request가 우선 처리됩니다.

큐 깊이가 32~64 per bank에 달합니다. AI workload의 outstanding miss 수가 수천에 달하기 때문에 queue가 깊어야 합니다.

#NPU vs GPU 컨트롤러 차이

같은 HBM3을 쓰지만 NPU와 GPU의 컨트롤러는 최적화 방향이 다릅니다.

1
NVIDIA GPU 컨트롤러 (H100)
2

3
- generic workload 대응 (graphics, HPC, AI)
4
- adaptive page policy (다양한 access pattern)
5
- L2 cache 큼 (50 MB), MSHR 수천 개
6
- cache miss → controller로 lat masking
7

8
AMD MI300X 컨트롤러
9
- AI focused
10
- 8 stack × 64 channel parallelism
11
- Infinity Fabric로 cache coherent
12

13
Google TPU 컨트롤러
14
- systolic array에 맞춘 access pattern
15
- predictable strided access
16
- prefetch 기반 latency hiding
17

18
Rebellions Atom (Korean NPU)
19
- transformer-specific access
20
- attention KV cache locality 최적화
21
- per-tile address remap
22

23
Sapeon X330 (SK Telecom NPU)
24
- inference 전용
25
- weight streaming 우선
26
- DRAM-side compression 옵션

같은 HBM3 stack에서도 컨트롤러 IP의 차이가 *workload별 효율 5~15%*를 만듭니다.

#AXI4-Stream wrapper

NPU·FPGA 설계에서 HBM 컨트롤러를 AXI-Stream으로 추상화하는 경우가 많습니다.

Xilinx HBM Controller IP가 AXI-Stream wrapper로 32-channel access를 제공합니다. 각 channel은 256-bit로 동작하고 내부적으로 16개 HBM channel로 분산됩니다.

1
Xilinx Alveo U55C (16 GB HBM2)
2

3
User logic ──► AXI4 [256-bit × 32 master]
4
                       │
5
                       ▼
6
              HBM Controller IP
7
                       │
8
                       ▼
9
              16 HBM channels × 2 stack

#자주 하는 실수

#”address mapping은 컨트롤러 IP가 알아서 한다”

기본 mapping은 generic입니다. workload-specific tuning을 하면 5~10% bandwidth 추가가 가능합니다. AI training cluster에서 큰 효과입니다.

#bank 수가 많으면 무조건 좋다고 가정

bank가 늘어나면 컨트롤러 큐가 깊어져야 하고 scheduler logic이 복잡해집니다. 큐 자체가 die area를 차지합니다. HBM3의 512 bank가 현재 GPU에서 fully utilize되지 않습니다.

#REFab과 REFpb를 비슷하게 가정

8.9% vs 0.6% bandwidth loss는 15배 차이입니다. 컨트롤러가 REFpb를 지원하지 않으면 AI training의 단가가 크게 달라집니다.

#”open page가 항상 좋다”

random access workload에서는 closed page가 빠릅니다. workload별 page policy 선택이 5~10% 차이를 냅니다. Adaptive가 가장 안전합니다.

#ECC overhead를 무시

system-level ECC를 on하면 bus utilization에서 *12.5%*가 redundancy로 쓰입니다. 그러나 off하면 수일 단위 training에서 bit flip이 모델을 망칠 수 있습니다. 데이터센터 표준은 항상 ECC on입니다.

#정리

• HBM3 컨트롤러는 512 bank를 동시 추적하며 FR-FCFS scheduling으로 동작합니다.
• bank parallelism이 *sustained BW의 80~95%*를 결정합니다.
• address XOR mapping은 연속 access도 자동으로 bank 분산시킵니다.
• open vs closed page policy는 workload pattern에 따라 adaptive로 선택해야 합니다.
• REFpb는 REFab 대비 8.3% bandwidth를 절약합니다. AI training에서 반드시 사용입니다.
• RD/WR turnaround penalty는 batch grouping으로 최소화합니다.
• NVIDIA·AMD·Google·Korean NPU(Rebellions, Sapeon)는 같은 HBM3를 쓰지만 컨트롤러 IP의 차이로 workload별 효율이 5~15% 갈립니다.
• Xilinx 같은 FPGA 솔루션은 AXI-Stream wrapper로 32 master를 HBM channel에 매핑합니다.

#다음 편

Ch 8: NPU·GPU에서의 활용에서는 LLM weight·activation·KV cache가 HBM에 어떻게 자리잡는지를 봅니다. 시리즈의 마무리입니다.

#관련 항목

• Ch 5: 대역폭 계산과 병목 분석
• Ch 6: 열 설계와 전력 관리
• Ch 8: NPU·GPU 활용
• CXL Ch 4: CXL.mem — 외부 메모리 컨트롤러
• BoW Ch 4: BoW Memory — 메모리 트랜잭션의 일반론