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>
This commit is contained in:
@@ -1,4 +1,4 @@
|
||||
# ADR-0016: IOChiplet NOC and Memory Data Path
|
||||
# ADR-0016: IOChiplet NoC와 메모리 데이터 경로
|
||||
|
||||
## Status
|
||||
|
||||
@@ -6,72 +6,73 @@ Accepted
|
||||
|
||||
## Context
|
||||
|
||||
ADR-0003 D2 defines IO chiplets as SIP-level components providing PCIe-EP and
|
||||
IO_CPU interfaces, but does not specify internal routing within the IO chiplet.
|
||||
ADR-0015 D4 was updated to document the M_CPU bypass for Memory R/W, but the
|
||||
IO chiplet's internal NOC architecture that enables this routing was not
|
||||
formally documented.
|
||||
ADR-0003 D2는 IO chiplet을 PCIe-EP 및 IO_CPU 인터페이스를 제공하는 SIP
|
||||
레벨 컴포넌트로 정의하지만, IO chiplet 내부의 라우팅은 명세하지 않는다.
|
||||
ADR-0015 D4는 Memory R/W에 대한 M_CPU 우회를 문서화하도록 갱신되었지만,
|
||||
이 라우팅을 가능하게 하는 IO chiplet의 내부 NoC 아키텍처는 형식적으로
|
||||
문서화되지 않았다.
|
||||
|
||||
The IO chiplet needs an internal routing fabric (io_noc) to:
|
||||
IO chiplet은 다음을 위해 내부 라우팅 패브릭(io_noc)을 필요로 한다:
|
||||
|
||||
- connect pcie_ep, io_cpu, and per-cube UCIe PHY ports
|
||||
- route memory operations (MemoryWrite/Read) directly to cube fabric without
|
||||
passing through io_cpu
|
||||
- route kernel launch commands through io_cpu for command interpretation
|
||||
- pcie_ep, io_cpu, 그리고 큐브당 UCIe PHY 포트들을 연결한다
|
||||
- 메모리 연산(MemoryWrite/Read)을 io_cpu를 거치지 않고 큐브 패브릭으로
|
||||
직접 라우팅한다
|
||||
- 커널 런치 명령을 명령 해석을 위해 io_cpu를 통해 라우팅한다
|
||||
|
||||
## Decision
|
||||
|
||||
### D1. IOChiplet internal NOC (io_noc)
|
||||
### D1. IOChiplet 내부 NoC (io_noc)
|
||||
|
||||
Each IO chiplet instance contains an internal NOC node (`io_noc`) that connects:
|
||||
각 IO chiplet 인스턴스는 다음을 연결하는 내부 NoC 노드(`io_noc`)를
|
||||
포함한다:
|
||||
|
||||
- `pcie_ep` — host-facing PCIe endpoint
|
||||
- `io_cpu` — command processor for kernel launch interpretation
|
||||
- `io_ucie-{PHY}.conn{N}` — per-PHY connection nodes to cube UCIe ports
|
||||
- `pcie_ep` — 호스트 대면 PCIe 엔드포인트
|
||||
- `io_cpu` — 커널 런치 해석용 명령 프로세서
|
||||
- `io_ucie-{PHY}.conn{N}` — 큐브 UCIe 포트들로 가는 PHY별 연결 노드
|
||||
|
||||
The io_noc is a forwarding-only fabric (`forwarding_v1` implementation) with
|
||||
zero overhead. All routing decisions are made by the simulation engine based
|
||||
on message type, not by io_noc itself.
|
||||
io_noc은 오버헤드가 0인 포워딩 전용 패브릭(`forwarding_v1` 구현)이다.
|
||||
모든 라우팅 결정은 io_noc 자체가 아니라 메시지 타입에 기반하여 시뮬레이션
|
||||
엔진이 내린다.
|
||||
|
||||
### D2. IOChiplet UCIe decomposition
|
||||
### D2. IOChiplet UCIe 분해
|
||||
|
||||
Each IO chiplet PHY port is decomposed into:
|
||||
각 IO chiplet PHY 포트는 다음으로 분해된다:
|
||||
|
||||
- `io_ucie-{PHY}` — the UCIe protocol endpoint (overhead = 8ns)
|
||||
- `io_ucie-{PHY}.conn{N}` — N connection nodes between io_noc and io_ucie
|
||||
- `io_ucie-{PHY}` — UCIe 프로토콜 엔드포인트(overhead = 8ns)
|
||||
- `io_ucie-{PHY}.conn{N}` — io_noc과 io_ucie 사이의 N개 연결 노드
|
||||
|
||||
This mirrors the cube-side UCIe decomposition (ADR-0015 D1) and allows
|
||||
multiple independent NOC-to-UCIe connections per PHY.
|
||||
이는 큐브 측 UCIe 분해(ADR-0015 D1)를 미러링하며, PHY당 여러 독립적인
|
||||
NoC-UCIe 연결을 허용한다.
|
||||
|
||||
### D3. Memory R/W path (M_CPU bypass)
|
||||
### D3. Memory R/W 경로 (M_CPU 우회)
|
||||
|
||||
Memory operations (MemoryWrite, MemoryRead) are routed directly from pcie_ep
|
||||
through io_noc to the target cube, bypassing io_cpu entirely:
|
||||
메모리 연산(MemoryWrite, MemoryRead)은 pcie_ep에서 io_noc을 거쳐 대상
|
||||
큐브로 직접 라우팅되며, io_cpu를 완전히 우회한다:
|
||||
|
||||
```text
|
||||
pcie_ep → io_noc → conn → io_ucie → [cube UCIe] → router mesh → hbm_ctrl
|
||||
```
|
||||
|
||||
This avoids the 10ns io_cpu overhead for pure data transfers. The simulation
|
||||
engine's `_process_memory_direct()` method uses `find_memory_path()` which
|
||||
resolves the shortest path from pcie_ep to the target HBM node.
|
||||
이는 순수 데이터 전송에 대해 10ns의 io_cpu 오버헤드를 회피한다.
|
||||
시뮬레이션 엔진의 `_process_memory_direct()` 메서드는 pcie_ep에서 대상
|
||||
HBM 노드까지의 최단 경로를 해석하는 `find_memory_path()`를 사용한다.
|
||||
|
||||
### D4. Kernel Launch path (via io_cpu)
|
||||
### D4. 커널 런치 경로 (io_cpu 경유)
|
||||
|
||||
Kernel launch commands require io_cpu for command interpretation and PE
|
||||
fan-out setup:
|
||||
커널 런치 명령은 명령 해석 및 PE 팬아웃 설정을 위해 io_cpu를 필요로
|
||||
한다:
|
||||
|
||||
```text
|
||||
pcie_ep → io_noc → io_cpu → io_noc → conn → io_ucie → [cube UCIe]
|
||||
→ noc → m_cpu → PE
|
||||
```
|
||||
|
||||
The engine's `_entry_points()` method routes KernelLaunchMsg through both
|
||||
pcie_ep (entry) and io_cpu (command processing).
|
||||
엔진의 `_entry_points()` 메서드는 KernelLaunchMsg를 pcie_ep(진입)와
|
||||
io_cpu(명령 처리) 양쪽 모두를 통해 라우팅한다.
|
||||
|
||||
### D5. IOChiplet-to-cube port mapping
|
||||
### D5. IOChiplet-to-큐브 포트 매핑
|
||||
|
||||
Each IO chiplet instance declares which cube ports it connects to:
|
||||
각 IO chiplet 인스턴스는 자신이 연결되는 큐브 포트를 선언한다:
|
||||
|
||||
```yaml
|
||||
cube_ports:
|
||||
@@ -79,20 +80,20 @@ cube_ports:
|
||||
- { cube: {xy: [1,0]}, cube_side: N, phy: P1, distance_mm: 2.0 }
|
||||
```
|
||||
|
||||
The topology builder creates edges from io_ucie PHY nodes to the
|
||||
corresponding cube UCIe port nodes, with the specified distance and
|
||||
the IO chiplet's `per_connection_bw_gbs` as link bandwidth.
|
||||
토폴로지 빌더는 io_ucie PHY 노드에서 해당 큐브 UCIe 포트 노드로의 엣지를
|
||||
지정된 거리 및 IO chiplet의 `per_connection_bw_gbs`를 링크 대역폭으로
|
||||
하여 생성한다.
|
||||
|
||||
## Consequences
|
||||
|
||||
- IO chiplet has a well-defined internal routing fabric
|
||||
- Memory operations avoid unnecessary io_cpu overhead
|
||||
- Kernel launch commands still get proper command interpretation
|
||||
- The io_noc pattern is consistent with cube-level NOC design
|
||||
- ADR-0003 D2 is extended (not contradicted) by this ADR
|
||||
- IO chiplet은 잘 정의된 내부 라우팅 패브릭을 가진다
|
||||
- 메모리 연산은 불필요한 io_cpu 오버헤드를 회피한다
|
||||
- 커널 런치 명령은 여전히 적절한 명령 해석을 받는다
|
||||
- io_noc 패턴은 큐브 레벨 NoC 설계와 일관된다
|
||||
- ADR-0003 D2는 본 ADR에 의해 확장된다(모순되지 않는다)
|
||||
|
||||
## Links
|
||||
|
||||
- ADR-0003 D2 (IO chiplet definition)
|
||||
- ADR-0015 D4 (fabric paths for Memory R/W and Kernel Launch)
|
||||
- ADR-0012 D1 (host-to-IO_CPU message schema)
|
||||
- ADR-0003 D2 (IO chiplet 정의)
|
||||
- ADR-0015 D4 (Memory R/W 및 커널 런치의 패브릭 경로)
|
||||
- ADR-0012 D1 (호스트-IO_CPU 메시지 스키마)
|
||||
|
||||
Reference in New Issue
Block a user