Files
kernbench2/docs/adr-ko/ADR-0017-dev-cube-noc-and-hbm-connectivity.md
T
ywkang 168b0c89f0 ADR: translate adr-ko/ to Korean, fix ADR-0013 slug, refine Status check
Follow-up to the bilingual-structure commit: docs/adr-ko/ now holds
only Korean versions (24 files translated from English placeholders),
ADR-0013 slug uses kebab-case in both folders, and the verify tool
allows translated parenthetical commentary in the Status block.

- Translate 24 English files in docs/adr-ko/ to Korean. The previous
  bilingual-structure commit had left these as English copies because
  their source content was already English; this commit fulfills the
  policy that docs/adr-ko/ contains only Korean.
- Rename ADR-0013 in both adr/ and adr-ko/ from
  ver-verification_strategy.md to ver-verification-strategy.md
  (kebab-case consistency with other ADRs).
- CLAUDE.md (ADR Translation Discipline): clarify that only the
  Status lifecycle keyword (Accepted / Proposed / Stub / Draft /
  Superseded by ADR-NNNN / Merged into ADR-NNNN) must match across
  EN and KO; parenthetical commentary and trailing list items may be
  translated.
- tools/verify_adr_lang_pairs.py: replace byte-equal Status check
  with normalize_status_keyword() which strips parenthetical
  commentary and takes only the first non-empty line.
- tests/test_verify_adr_lang_pairs.py: update existing test names,
  add coverage for translated parenthetical, translated trailing
  list, and Superseded-by-NNNN keyword equality.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-20 08:17:56 -07:00

283 lines
12 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# ADR-0017: 큐브 NoC와 HBM 연결성
## Status
Accepted
## Context
CUBE 레벨의 NoC는 모든 큐브 내부 요청을 운반하는 2D 라우터 메시이다:
PE-HBM 데이터, PE-PE 트래픽, 명령 경로(M_CPU↔PE_CPU), 공유 SRAM 접근,
큐브 간 UCIe 트래픽.
CUBE의 HBM은 PE 라우터에 부착된 PE별 컨트롤러 엔드포인트를 통해 노출된다.
이러한 PE별 분할 덕분에 로컬-vs-원격 HBM이 메시 거리로 구분 가능하다:
PE 자신의 HBM 파티션은 자신의 라우터에 위치하고(스위칭 오버헤드만 발생),
다른 PE의 HBM 파티션은 해당 PE의 라우터로 메시 hop을 거쳐 도달 가능하다.
설계 공간에서는 두 가지 채널 매핑 모드를 지원한다:
- **n:1 (default, 구현됨)** — 각 PE의 HBM 파티션이 `channels_per_pe`
pseudo-channel을 하나의 엔드포인트로 집계한다. 유효 PE당 BW =
N × per-channel BW.
- **1:1 (future)** — 각 PE 라우터가 채널별 미니 라우터로 분해된다;
채널별 BW 경합을 직접 모델링한다.
두 모드 모두 PE당 유효 BW는 동일하다; 연결 입도만 다르다.
## Decision
### D1. 2D 라우터 메시
각 큐브는 `mesh_gen.py`가 생성하는 2D 라우터 메시를 포함한다.
- 노드 명명: `sip{S}.cube{C}.r{row}c{col}` (예: `sip0.cube0.r0c0`).
- 구현: `forwarding_v1`. NoC `overhead_ns = 0`.
- 기본 6×6 그리드 (PE 코너 배치 + UCIe 부착 개수로 산정); 더 큰 PE
개수는 그리드를 확장한다.
- HBM 제외 영역: HBM 다이가 물리적으로 점유하는 중앙 행/열을 제외한다
(예: 6×6의 경우 r2c2, r2c3, r3c2, r3c3).
- 레이턴시 = Manhattan 거리 × `ns_per_mm`.
### D2. XY 라우팅 알고리즘
결정론적 XY 라우팅:
1. 수평 구간: 소스 X에서 목적지 X까지 소스 Y에서 라우팅.
2. 수직 구간: 소스 Y의 목적지 X에서 목적지 Y까지 라우팅.
각 유향 구간은 고유 키를 운반한다:
- 수평: `("H", y_band, x_min, x_max, direction)`
- 수직: `("V", x_band, y_min, y_max, direction)`
그리드 위치는 HBM 영역을 제외하고 라우터 그리드에 스냅된다.
### D3. 구간별 경합 모델
각 유향 XY 구간은 `simpy.Resource(capacity=1)`이다. 동일 구간을 공유하는
트랜잭션(동일한 행 또는 열 밴드, 동일한 방향)은 자원을 두고 경합한다 —
wormhole 라우팅 메시에서의 링크 수준 직렬화를 모델링한다.
경합이 없을 때 NoC 순회 레이턴시는 Manhattan 거리 × `ns_per_mm`이다.
경합이 있을 때는 SimPy의 자원 스케줄링이 큐잉 지연을 추가한다.
### D4. NoC 부착 지점 (PE별 HBM 파티션)
모든 PE 라우터는 세 개의 부착을 갖는다: `pe{idx}.dma`, `pe{idx}.cpu`,
그리고 `pe{idx}.hbm`. 마지막은 PE별 HBM 컨트롤러 엔드포인트로
`sip{S}.cube{C}.hbm_ctrl.pe{idx}`이며, 큐브 HBM의 한 슬라이스를
소유한다 (하나의 pseudo-channel 그룹; D8 참조).
기타 부착:
- M_CPU와 공유 SRAM은 각각 전용 edge 라우터를 점유한다.
- UCIe 엔드포인트(N/S/E/W)는 각각 해당 변에 분산된 4개의 연결 라우터를
노출한다 (D6 참조).
```text
UCIe-N (conn x4)
|
+---------+---+---+---------+
| | | |
PE0.dma ---+ r0c0 | ... | r0c5 +--- PE2.dma
PE0.cpu <--+ +hbm.pe0| | +hbm.pe2+--< PE2.cpu
| | | |
UCIe-W ----+ ... | [HBM] | ... +---- UCIe-E
(conn x4) | | zone | | (conn x4)
| r2c0 | | |
M_CPU <--->+ | | |
| r3c0 | | |
SRAM <---->+ | | |
| | | |
PE4.dma ---+ r4c0 | ... | r4c5 +--- PE6.dma
PE4.cpu <--+ +hbm.pe4| | +hbm.pe6+--< PE6.cpu
| | | |
+---------+---+---+---------+
|
UCIe-S (conn x4)
```
PE별 HBM 분할은 로컬 vs 크로스-PE HBM을 메시 거리로 구분 가능하게 만드는
핵심 불변식이다 (D7 참조).
### D5. NoC 엣지 대역폭과 거리
| Connection | BW (GB/s) | Distance | Notes |
| ----------------------------- | ---------- | ------------- | ------------------------------------------- |
| PE_DMA → NOC | 256.0 | Physical (PE) | 로컬-HBM 집계 BW와 일치 |
| NOC → PE_CPU | — | 0.0 mm | 명령 경로 전용 |
| Router ↔ hbm_ctrl.pe{idx} | 256.0 | 0.0 mm | PE 라우터당; N × per-channel BW (D8 참조) |
| NOC ↔ M_CPU | — | 0.0 mm | 명령 경로 |
| NOC ↔ SRAM | 128.0 × 4 | 0.0 mm | 512 GB/s 집계 |
| NOC ↔ UCIe conn | 128.0 | 0.0 mm | 연결당; 포트당 4개 conn |
`0.0 mm` 거리는 NoC의 분산 특성을 반영한다; 실제 순회 거리는 라우터
그리드 내에서 Manhattan 거리로 계산된다.
### D6. UCIe 분해와 큐브 간 트래픽
4개의 UCIe 포트(N, S, E, W) 각각은 다음으로 분해된다:
- `ucie-{PORT}` 노드 1개: UCIe 프로토콜 엔드포인트 (`overhead = 8.0 ns`).
- `ucie-{PORT}.conn{0-3}` 노드 4개: NoC와 UCIe 간 연결 브리지.
이 분해로 포트당 4개의 독립 NoC↔UCIe 연결이 생성되며, 각각 128 GB/s
대역폭을 갖는다 (포트당 집계 512 GB/s).
큐브 간 트래픽 경로:
```text
Source: PE_DMA → NOC → conn{i} → ucie-{PORT}
[UCIe link: 512 GB/s, 1.0mm seam distance]
Target: ucie-{PORT} → conn{i} → r{x}c{y} → (mesh hops) → hbm_ctrl.pe{idx}
```
UCIe 오버헤드(8.0 ns)는 각 `ucie-{PORT}` 노드에서 적용되므로 전체 횡단은
16 ns(TX 포트 + RX 포트)가 소요된다.
### D7. NoC를 통한 데이터 경로
모든 큐브 내부 트래픽은 동일한 라우터 메시를 사용한다 — 별도의 fast path는
없다.
**로컬 HBM** (동일 PE의 자신 파티션; 0 메시 hop):
```text
PE_DMA → r{x}c{y} → hbm_ctrl.pe{idx} (switching overhead only)
```
**큐브 내 크로스-PE HBM** (대상 PE의 파티션, 메시로 도달):
```text
PE_DMA → r{x}c{y} → (mesh hops) → r{x'}c{y'} → hbm_ctrl.pe{idx'}
```
예시: PE0(`r0c0` 위)이 PE2의 HBM(PE2는 `r1c4` 위)에 접근:
```text
PE0.pe_dma → r0c0 → r0c1 → r0c2 → r0c3 → r0c4 → r1c4 → hbm_ctrl.pe2
```
Dijkstra가 메시 내 최단 경로를 계산한다.
**큐브 간 HBM** (UCIe 횡단):
```text
PE_DMA → r{x}c{y} → conn → ucie-{PORT} → [seam] → ucie-{PORT'} → conn
→ r{x'}c{y'} → hbm_ctrl.pe{idx'}
```
**PE로의 커널 launch 명령**:
```text
[from io_noc] → ucie → conn → r{x}c{y} → (mesh) → M_CPU → (mesh) → PE_CPU
```
**공유 SRAM 접근**:
```text
PE_DMA → r{x}c{y} → (mesh) → SRAM
```
### D8. HBM 채널 매핑 모드
채널 매핑은 큐브 범위에서 구성된다:
```yaml
cube:
memory_map:
hbm_mapping_mode: n_to_one # one_to_one | n_to_one
hbm_pseudo_channels: 64 # total pseudo-channel count
hbm_channels_per_pe: 8 # per-PE local channel count
hbm_channel_bw_gbs: 32.0 # per-channel bandwidth (GB/s)
hbm_slices_per_cube: 8 # number of per-PE partitions
hbm_total_gb_per_cube: 48
```
**n:1 모드 (default, 구현됨).** 각 PE의 HBM 파티션은 `channels_per_pe`
pseudo-channel을 집계하는 단일 엔드포인트 `hbm_ctrl.pe{idx}`이다.
`Router ↔ hbm_ctrl.pe{idx}` 링크 대역폭은 `channels_per_pe ×
hbm_channel_bw_gbs`와 같다. Pseudo-channel은 인터리브된다고 가정하며,
PE당 집계 BW만 모델링한다. 별도의 집계 라우터 노드는 존재하지 않는다 —
PE별 라우터 자체가 그 역할을 한다.
**1:1 모드 (future).** 각 PE 라우터가 N개의 채널 미니 라우터로
분해된다; 채널별 라우팅이 완전히 해석된 PA + channel ID를 운반한다.
`ChannelSplitter`가 논리적 접근을 N개의 채널별 물리 요청으로 해결한다.
채널별 링크가 BW 경합을 모델링한다. 크로스-PE 채널 접근 시맨틱은
구현 ADR로 연기된다.
**BW 계산 (default 값).**
| Parameter | Value |
| ---------------------------------- | -------------------------- |
| 큐브당 pseudo channel | 64 (parameter) |
| 큐브당 PE | 8 (parameter) |
| PE당 channel (N) | 64 / 8 = 8 |
| 채널당 BW | 32 GB/s (parameter) |
| PE당 로컬 BW | N × 32 = 256 GB/s |
| 큐브 전체 HBM BW | 64 × 32 = 2048 GB/s |
두 모드 모두 PE당 유효 BW는 동일하다; 요청 형태와 경합 모델만 다르다.
### D9. AddressResolver — PE별 HBM 엔드포인트
주소 리졸버는 PA의 HBM 오프셋을 소유 PE의 파티션으로 디코딩한다:
```python
# policy/routing/router.py
hbm_slice_bytes = hbm_total_gb_per_cube * (1 << 30) // hbm_slices_per_cube
if addr.kind == "hbm":
pe_id = int(addr.hbm_offset) // hbm_slice_bytes
return f"sip{s}.cube{d}.hbm_ctrl.pe{pe_id}"
```
pe_id 계산은 라우팅 레이어의 본질적 일부이다 (토폴로지 시점 관심사가
아니다). 모든 HBM PA는 정확히 하나의 파티션에 속하므로 결정론적 라우팅이
보장된다.
외부 호출자(예: M_CPU DMA, PCIE_EP로부터의 Memory R/W)도 동일한 리졸버
경로를 따른다 — 별도의 fast path는 존재하지 않는다.
### D10. 메시 생성 파라미터
`mesh_gen.py`는 다음으로부터 `cube_mesh.yaml`을 생성한다:
- `cube.pe_layout`: 코너 배치(NW, NE, SW, SE)와 코너당 PE 개수.
- `cube.geometry`: 큐브 물리 치수와 HBM 영역.
- `cube.ucie.n_connections`: UCIe 부착용 라우터 개수를 결정.
출력 `mesh_data` 딕셔너리는 다음을 포함한다:
- 위치 및 HBM 제외 영역을 갖는 라우터 그리드.
- PE-라우터 부착 (PE별 `pe{idx}.dma`, `pe{idx}.cpu`, `pe{idx}.hbm`).
- UCIe-라우터 부착 (N/S/E/W가 edge 라우터에 분산).
- M_CPU와 SRAM 라우터 부착.
## Consequences
- 로컬 HBM(0 메시 hop, 스위칭 오버헤드만)과 크로스-PE HBM(메시 hop)이
자연스럽게 구분되어 SPEC R5(다중 도메인 통신)와 ADR-0002(end-to-end
제로 레이턴시 경로 금지)를 만족한다.
- 모든 큐브 내부 트래픽이 하나의 메시를 통해 라우팅된다 — 단일 경합
모델, 단일 레이아웃, 단일 엣지 BW 집합.
- PE별 HBM 분할이 LA 모델(ADR-0011)에 깔끔하게 매핑된다: 각 PE의
파티션은 할당된 pseudo-channel의 n:1 집계이다.
- 1:1 모드 확장이 구조적으로 자연스럽다 — 각 PE 라우터를 N개의 채널
라우터로 분해한다.
- 메시 생성이 `topology.yaml`로 완전히 파라미터화된다; PE/큐브 기하
변경이 코드 수정 없이 전파된다.
## Links
- ADR-0002 (라우팅 거리, 순서, 제로 레이턴시 경로 금지)
- ADR-0003 D3 (큐브 레벨 NoC 정의 — 본 ADR에서 확장)
- ADR-0004 (메모리 시맨틱, 로컬 HBM)
- ADR-0011 (메모리 주소 지정 — LA 모델이 PE별 파티션을 소비)
- ADR-0014 D1 (라우터 메시를 통한 PE_DMA egress)
- ADR-0015 D4 (Memory R/W와 Kernel Launch의 패브릭 경로)
- ADR-0016 (IOChiplet io_noc — IO 칩렛 레벨에서의 유사 패턴)
- ADR-0033 (레이턴시 모델: PC당 병렬성, 스위치 패널티)