Files
kernbench2/docs/adr-ko/ADR-0016-dev-iochiplet-noc-and-memory-path.md
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

3.7 KiB

ADR-0016: IOChiplet NoC와 메모리 데이터 경로

Status

Accepted

Context

ADR-0003 D2는 IO chiplet을 PCIe-EP 및 IO_CPU 인터페이스를 제공하는 SIP 레벨 컴포넌트로 정의하지만, IO chiplet 내부의 라우팅은 명세하지 않는다. ADR-0015 D4는 Memory R/W에 대한 M_CPU 우회를 문서화하도록 갱신되었지만, 이 라우팅을 가능하게 하는 IO chiplet의 내부 NoC 아키텍처는 형식적으로 문서화되지 않았다.

IO chiplet은 다음을 위해 내부 라우팅 패브릭(io_noc)을 필요로 한다:

  • pcie_ep, io_cpu, 그리고 큐브당 UCIe PHY 포트들을 연결한다
  • 메모리 연산(MemoryWrite/Read)을 io_cpu를 거치지 않고 큐브 패브릭으로 직접 라우팅한다
  • 커널 런치 명령을 명령 해석을 위해 io_cpu를 통해 라우팅한다

Decision

D1. IOChiplet 내부 NoC (io_noc)

각 IO chiplet 인스턴스는 다음을 연결하는 내부 NoC 노드(io_noc)를 포함한다:

  • pcie_ep — 호스트 대면 PCIe 엔드포인트
  • io_cpu — 커널 런치 해석용 명령 프로세서
  • io_ucie-{PHY}.conn{N} — 큐브 UCIe 포트들로 가는 PHY별 연결 노드

io_noc은 오버헤드가 0인 포워딩 전용 패브릭(forwarding_v1 구현)이다. 모든 라우팅 결정은 io_noc 자체가 아니라 메시지 타입에 기반하여 시뮬레이션 엔진이 내린다.

D2. IOChiplet UCIe 분해

각 IO chiplet PHY 포트는 다음으로 분해된다:

  • io_ucie-{PHY} — UCIe 프로토콜 엔드포인트(overhead = 8ns)
  • io_ucie-{PHY}.conn{N} — io_noc과 io_ucie 사이의 N개 연결 노드

이는 큐브 측 UCIe 분해(ADR-0015 D1)를 미러링하며, PHY당 여러 독립적인 NoC-UCIe 연결을 허용한다.

D3. Memory R/W 경로 (M_CPU 우회)

메모리 연산(MemoryWrite, MemoryRead)은 pcie_ep에서 io_noc을 거쳐 대상 큐브로 직접 라우팅되며, io_cpu를 완전히 우회한다:

pcie_ep → io_noc → conn → io_ucie → [cube UCIe] → router mesh → hbm_ctrl

이는 순수 데이터 전송에 대해 10ns의 io_cpu 오버헤드를 회피한다. 시뮬레이션 엔진의 _process_memory_direct() 메서드는 pcie_ep에서 대상 HBM 노드까지의 최단 경로를 해석하는 find_memory_path()를 사용한다.

D4. 커널 런치 경로 (io_cpu 경유)

커널 런치 명령은 명령 해석 및 PE 팬아웃 설정을 위해 io_cpu를 필요로 한다:

pcie_ep → io_noc → io_cpu → io_noc → conn → io_ucie → [cube UCIe]
  → noc → m_cpu → PE

엔진의 _entry_points() 메서드는 KernelLaunchMsg를 pcie_ep(진입)와 io_cpu(명령 처리) 양쪽 모두를 통해 라우팅한다.

D5. IOChiplet-to-큐브 포트 매핑

각 IO chiplet 인스턴스는 자신이 연결되는 큐브 포트를 선언한다:

cube_ports:
  - { cube: {xy: [0,0]}, cube_side: N, phy: P0, distance_mm: 2.0 }
  - { cube: {xy: [1,0]}, cube_side: N, phy: P1, distance_mm: 2.0 }

토폴로지 빌더는 io_ucie PHY 노드에서 해당 큐브 UCIe 포트 노드로의 엣지를 지정된 거리 및 IO chiplet의 per_connection_bw_gbs를 링크 대역폭으로 하여 생성한다.

Consequences

  • IO chiplet은 잘 정의된 내부 라우팅 패브릭을 가진다
  • 메모리 연산은 불필요한 io_cpu 오버헤드를 회피한다
  • 커널 런치 명령은 여전히 적절한 명령 해석을 받는다
  • io_noc 패턴은 큐브 레벨 NoC 설계와 일관된다
  • ADR-0003 D2는 본 ADR에 의해 확장된다(모순되지 않는다)
  • ADR-0003 D2 (IO chiplet 정의)
  • ADR-0015 D4 (Memory R/W 및 커널 런치의 패브릭 경로)
  • ADR-0012 D1 (호스트-IO_CPU 메시지 스키마)