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-0003: Target System Hierarchy & Modeling Scope
|
||||
# ADR-0003: 타겟 시스템 계층 및 모델링 범위
|
||||
|
||||
## Status
|
||||
|
||||
@@ -6,63 +6,63 @@ Accepted
|
||||
|
||||
## Context
|
||||
|
||||
We need a system-level simulator to evaluate LLM kernel performance on our AI Accelerator platform.
|
||||
The platform is organized as a compute tray containing multiple identical SIPs connected via PCIe or UAL
|
||||
through switching fabrics, with a host CPU issuing commands/kernels.
|
||||
자사 AI Accelerator 플랫폼에서 LLM 커널 성능을 평가하기 위해 시스템 수준의 시뮬레이터가 필요하다.
|
||||
해당 플랫폼은 PCIe 또는 UAL을 통해 스위칭 패브릭으로 연결된 다수의 동일한 SIP를 포함하는 컴퓨트 트레이로 구성되며,
|
||||
호스트 CPU가 명령/커널을 발급한다.
|
||||
|
||||
## Decision
|
||||
|
||||
We model the system hierarchy explicitly:
|
||||
시스템 계층을 다음과 같이 명시적으로 모델링한다.
|
||||
|
||||
### D1. Tray-level
|
||||
|
||||
- A compute tray contains:
|
||||
- Host CPU (issues requests / coordinates runtime & data placement)
|
||||
- Multiple identical SIPs (accelerators)
|
||||
- Interconnect fabric between SIPs (PCIe and/or UAL via switches)
|
||||
- 하나의 컴퓨트 트레이는 다음을 포함한다:
|
||||
- 호스트 CPU (요청 발급 / 런타임 및 데이터 배치 조정)
|
||||
- 다수의 동일한 SIP (가속기)
|
||||
- SIP 간 인터커넥트 패브릭 (스위치를 통한 PCIe 및/또는 UAL)
|
||||
|
||||
### D2. SIP-level
|
||||
|
||||
- A SIP is a multi-die package composed of:
|
||||
- Multiple CUBEs (HBM die + compute PEs + UCIe)
|
||||
- One or more IO chiplets (host/SIP interfaces)
|
||||
- IO chiplets:
|
||||
- provide interfaces: PCIe-EP, IO_CPU, optionally UAL-EP
|
||||
- can be multiple per SIP
|
||||
- placement constrained to SIP shoreline (top/bottom/left/right); each shoreline may host 1–2 IO chiplets
|
||||
- SIP는 다음으로 구성된 멀티 다이 패키지이다:
|
||||
- 다수의 CUBE (HBM 다이 + 컴퓨트 PE + UCIe)
|
||||
- 하나 이상의 IO 칩렛 (호스트/SIP 인터페이스)
|
||||
- IO 칩렛:
|
||||
- 다음 인터페이스를 제공한다: PCIe-EP, IO_CPU, 선택적으로 UAL-EP
|
||||
- SIP 당 다수가 존재할 수 있다
|
||||
- 배치는 SIP shoreline(상/하/좌/우)으로 제약되며, 각 shoreline에는 1~2개의 IO 칩렛이 위치할 수 있다
|
||||
|
||||
### D3. CUBE-level
|
||||
|
||||
- A CUBE contains:
|
||||
- HBM + memory controller (HBM_CTRL)
|
||||
- NOC (on-die fabric): carries all intra-cube traffic including HBM data,
|
||||
inter-cube (UCIe), command (M_CPU↔PE_CPU), and shared SRAM access.
|
||||
Must provide: full-BW PE↔local HBM path, PE↔SRAM connectivity,
|
||||
PE↔UCIe connectivity, M_CPU↔PE command path.
|
||||
NOC topology is an implementation choice (e.g., 2D mesh, ring, crossbar);
|
||||
current implementation uses a 2D mesh with XY routing (see ADR-0017).
|
||||
HBM_CTRL is attached to each PE's local NOC port (local HBM = minimal hop).
|
||||
- Shared SRAM: cube-level shared memory accessible by all PEs via NOC
|
||||
- management/control CPU (M_CPU) coordinating PE command distribution and completion aggregation
|
||||
- multiple PEs
|
||||
- up to 4 UCIe endpoints (N/E/W/S) for CUBE↔CUBE and CUBE↔IO connectivity
|
||||
- 하나의 CUBE는 다음을 포함한다:
|
||||
- HBM + 메모리 컨트롤러 (HBM_CTRL)
|
||||
- NoC (on-die 패브릭): HBM 데이터, 큐브 간(UCIe) 트래픽, 명령(M_CPU↔PE_CPU),
|
||||
공유 SRAM 액세스를 포함한 모든 큐브 내부 트래픽을 운반한다.
|
||||
반드시 제공해야 하는 것: 풀-대역폭 PE↔로컬 HBM 경로, PE↔SRAM 연결성,
|
||||
PE↔UCIe 연결성, M_CPU↔PE 명령 경로.
|
||||
NoC 토폴로지는 구현 선택사항(예: 2D 메시, 링, 크로스바)이며,
|
||||
현재 구현은 XY 라우팅 방식의 2D 메시를 사용한다(ADR-0017 참조).
|
||||
HBM_CTRL은 각 PE의 로컬 NoC 포트에 부착된다(로컬 HBM = 최소 홉).
|
||||
- 공유 SRAM: 모든 PE가 NoC를 통해 액세스 가능한 큐브 수준 공유 메모리
|
||||
- PE 명령 분배 및 완료 집계를 조정하는 관리/제어 CPU (M_CPU)
|
||||
- 다수의 PE
|
||||
- CUBE↔CUBE 및 CUBE↔IO 연결성을 위한 최대 4개의 UCIe 엔드포인트 (N/E/W/S)
|
||||
|
||||
### D4. PE-level
|
||||
|
||||
- A PE can execute one kernel instance
|
||||
- PE contains internal control + accelerators (modeled at PE view granularity):
|
||||
- PE_CPU, command handler, PE_TCM, DMA/GEMM/MATH engines, internal queues
|
||||
- 하나의 PE는 하나의 커널 인스턴스를 실행할 수 있다
|
||||
- PE는 내부 제어 + 가속기를 포함한다 (PE 뷰 단위로 모델링):
|
||||
- PE_CPU, 명령 핸들러, PE_TCM, DMA/GEMM/MATH 엔진, 내부 큐
|
||||
|
||||
## Consequences
|
||||
|
||||
- The simulator supports abstraction by “views”:
|
||||
- SIP view hides PE internals
|
||||
- CUBE view treats each PE as a single block
|
||||
- PE view expands PE internals
|
||||
- Topology remains parameterized; sizes/counts/links come from configuration.
|
||||
- 시뮬레이터는 "뷰" 단위의 추상화를 지원한다:
|
||||
- SIP 뷰는 PE 내부를 숨긴다
|
||||
- CUBE 뷰는 각 PE를 단일 블록으로 다룬다
|
||||
- PE 뷰는 PE 내부를 전개한다
|
||||
- 토폴로지는 매개변수화된 상태로 유지되며, 크기/개수/링크는 설정으로부터 주어진다.
|
||||
|
||||
## Links
|
||||
|
||||
- SPEC R3/R5
|
||||
- ADR-0005 (diagram views)
|
||||
- ADR-0017 (cube NOC 2D mesh architecture)
|
||||
- ADR-0005 (다이어그램 뷰)
|
||||
- ADR-0017 (큐브 NoC 2D 메시 아키텍처)
|
||||
|
||||
Reference in New Issue
Block a user