Files

T

ywkang 22fd0d2b9d ADR: introduce docs/history/, merge 0011+0018, prune migration cruft

- CLAUDE.md: add ADR Lifecycle subsection (superseded → docs/history/,
  immutable numbering, no renumber)
- ADR-0011: merge ADR-0018 content as "Address Model: LA" section
  alongside PA / VA; status notes VA model is currently implemented
- ADR-0018 / 0029 / 0031: moved to docs/history/ with status updates
  (0018 merged into 0011, 0029 superseded by 0032, 0031 absorbed
  into 0001 rev 2)
- ADR-0019: rewrite Context as PE-HBM connectivity decision
  (self-contained, no LA model framing)
- ADR-0019/0020/0021/0023/0025/0027: Status Proposed → Accepted
  (code verified) and prune Implementation Notes / Affected files /
  Test strategy / "현재 상태" sub-sections describing pre-impl state
- ADR-0024/0026: same migration-flavor cleanup; 0026 also drops D6
  Migration and D8 docs-update sub-decisions
- ADR-0030: status simplified (blocker ADR-0031 now superseded)
- SPEC.md: R10 + §0.2 reflect PA / VA / LA model names
- ADR-0008/0012/0013: refresh ADR-0011 subtitle in Links

21 files changed, 553 insertions(+), 1290 deletions(-).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-19 11:42:45 -07:00

2.7 KiB

Raw Blame History

ADR-0008: Tensor Deployment and Allocation (Host Allocator, PA-first)

Status

Accepted

Context

Benchmarks require PyTorch-like tensor semantics:

tensor creation (empty, fill),
deployment to accelerator devices (tensor.to()).

In the realistic system, host software manages allocation/mapping and installs mappings for DMA/MMU. For Phase 0 we simplify (ADR-0011):

device memory operations use PA only,
VA/MMU/IOMMU is not modeled.

To keep the host↔device interface minimal, we avoid a separate AllocateTensorMeta message. Instead, host allocation produces a PA shard map that is used directly by MemoryWrite/Read and KernelLaunch.

Decision

D1. Tensor is a host-owned handle with PA shard mapping

A Tensor object is a host-owned handle that encapsulates:

shape and dtype,
initialization intent,
device placement and allocation metadata as a PA shard map.

After deployment, the Tensor handle MUST contain:

a list of shards, each with (sip,cube,pe,pa,nbytes,offset_bytes).

This PA shard mapping is the single source of truth for kernel argument binding.

D2. Deployment uses a host allocator (Phase 0)

In Phase 0, tensor deployment produces PA shard mappings via a host allocator:

placement (split/replicate/hybrid) is decided by a DP policy,
allocation assigns PA ranges at the PE level and returns shard mappings,
the Tensor handle stores the resulting shard list deterministically.

No separate host-visible device allocation RPC is required in Phase 0.

D3. Data initialization and transfer uses MemoryWrite/Read only

Any data initialization or transfer implied by a tensor (e.g., fill, copy) MUST be represented using Host ↔ IO_CPU messages only:

MemoryWrite
MemoryRead

Rules:

MemoryWrite/Read MUST reference PA + (sip,cube,pe) tags (ADR-0012).
Allocation metadata MUST NOT be embedded as a separate allocation message.
Bulk tensor data MUST NOT be embedded in Phase 0 messages.

The simulation engine schedules MemoryWrite/Read through the graph so that latency is computed by explicit traversal.

D4. Extension path (non-breaking)

Future ADRs MAY introduce optional VA/MMU/IOMMU modeling by adding:

virtual addressing in tensor handles,
mapping install steps,
translation latency/page granularity.

The Phase 0 PA shard map remains a valid fast-path configuration.

Consequences

Host↔IO_CPU contract remains minimal (MemoryRead/Write + KernelLaunch).
KernelLaunch can pass per-PE data placement explicitly via shard tags.
Early implementation stays simple and testable.

2.7 KiB Raw Blame History