ADR housekeeping: category prefixes, lifecycle folders, retroactive 0034-0037
Filename + lifecycle:
- ADR rename to ADR-NNNN-<cat>-title.md with 8 3-letter category prefixes
(dev / mem / lat / prog / algo / par / api / ver). Numbers stay immutable.
- ADR Lifecycle split into 3 folders, documented in CLAUDE.md Part 2:
docs/adr/ (Accepted), docs/adr-proposed/ (Proposed/Stub/Draft),
docs/adr-history/ (Superseded/Merged). Status field gains "Draft" for
retroactive docs pending verification.
Merges (one ADR per topic, no change-history annotations):
- ADR-0017 absorbs ADR-0019 (Cube NOC + per-PE HBM connectivity, 10 D-items)
- ADR-0014 absorbs ADR-0021 (PE pipeline execution model, 8 D-items incl.
TileToken self-routing and multi-op composite epilogue scope)
- ADR-0023 absorbs docs/ipcq-dma-codesign-hw.md as new "HW Realization
Notes (Informative)" section (D16-D23 + Open HW Questions). codesign-hw.md
deleted; ADR-0019/0021 moved to adr-history with one-line stub status
Retroactive documentation (G4 closures, code-verified):
- ADR-0037 forwarding component (TransitComponent: first-flit overhead,
serial worker, path-based routing, single impl/multiple names)
- ADR-0036 IO_CPU component (target_start_ns global barrier stamping,
per-cube fan-out, response aggregation)
- ADR-0035 M_CPU & M_CPU.DMA component (3 fan-out paths, DMA Resources,
target_start_ns passthrough)
- ADR-0034 HBM controller internal design (per-PC state, address-based
selection, flit-aware per-flit commit, async finalize, command-only
fallback path)
Content updates:
- ADR-0010 expanded to full CLI surface (run/probe/web), retitled
"Command Line Interface and Execution Semantics"
- ADR-0007 D2 rewritten to current state; ADR-0015 supersession notes pruned
- ADR-0005 wrapped in Decision header with D1-D5; ADR-0022 metadata
block replaced with standard Status header
- ADR-0024 trimmed to rank=SIP launcher essentials (D1-D4);
ADR-0027 cleaned of supersession history
- ADR-0033 D6 cleanup: address-based PC selection moved out of future-work
(now documented in ADR-0034 D3); related D1/D3 wording realigned
- Cross-references back-filled in 5 ADRs (G3 gaps closed)
Onboarding docs split:
- docs/onboarding/ created
- moved: hw-architecture-overview.md, latency-model.md, di-presentation.md,
ccl-author-guide{,.en}.md
- references updated in README, ADR-0023{,.en}, src/kernbench/ccl/__init__.py
Source / test / yaml: ADR-NNNN cross-references in docstrings and YAML
comments updated after the merges (ADR-0021->0014 D6, ADR-0019->0017 D8).
No behavior change.
Tooling:
- tools/verify_adr_lang_pairs.py + tests/test_verify_adr_lang_pairs.py
(ADR EN/KO pair invariant checker)
- .claude/commands/report.md tracked (/report slash command)
- .gitignore: allow .claude/commands/*.md while keeping settings files ignored
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,98 @@
|
||||
# ADR-0016: IOChiplet NOC and Memory Data Path
|
||||
|
||||
## Status
|
||||
|
||||
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.
|
||||
|
||||
The IO chiplet needs an internal routing fabric (io_noc) to:
|
||||
|
||||
- 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
|
||||
|
||||
## Decision
|
||||
|
||||
### D1. IOChiplet internal NOC (io_noc)
|
||||
|
||||
Each IO chiplet instance contains an internal NOC node (`io_noc`) that connects:
|
||||
|
||||
- `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
|
||||
|
||||
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.
|
||||
|
||||
### D2. IOChiplet UCIe decomposition
|
||||
|
||||
Each IO chiplet PHY port is decomposed into:
|
||||
|
||||
- `io_ucie-{PHY}` — the UCIe protocol endpoint (overhead = 8ns)
|
||||
- `io_ucie-{PHY}.conn{N}` — N connection nodes between io_noc and io_ucie
|
||||
|
||||
This mirrors the cube-side UCIe decomposition (ADR-0015 D1) and allows
|
||||
multiple independent NOC-to-UCIe connections per PHY.
|
||||
|
||||
### D3. Memory R/W path (M_CPU bypass)
|
||||
|
||||
Memory operations (MemoryWrite, MemoryRead) are routed directly from pcie_ep
|
||||
through io_noc to the target cube, bypassing io_cpu entirely:
|
||||
|
||||
```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.
|
||||
|
||||
### D4. Kernel Launch path (via io_cpu)
|
||||
|
||||
Kernel launch commands require io_cpu for command interpretation and PE
|
||||
fan-out setup:
|
||||
|
||||
```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).
|
||||
|
||||
### D5. IOChiplet-to-cube port mapping
|
||||
|
||||
Each IO chiplet instance declares which cube ports it connects to:
|
||||
|
||||
```yaml
|
||||
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 }
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
## 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
|
||||
|
||||
## 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)
|
||||
Reference in New Issue
Block a user