SoC study Phase 5: fidelity where the studies need it -- execution plan

In progress · updated 2026-10-30 · branes-ai/graphs#269 · graphs/docs/plan/soc-phase5-execution-plan.md

Tracking: branes-ai/graphs#269, Phase 5. Parent plan: docs/plan/soc-microarchitecture-study-plan.md, section 7 (“driven by what the first studies expose”). The strict rule of Phases 2-4 carries over. Started 2026-09-18.

What the first study exposed

docs/assessments/soc-orin-vs-kpu-heterogeneous.md (PR 4.3) could decide only DRAM feasibility. In order of leverage, what blocks the rest:

1. No per-engine service time exists for any stage. default_v1 has two measured pairs, and neither is a format the stages run in.
2. The KPU has no FP32, so 14 of 19 stages fall to the CPU.
3. Unpriced silicon: Orin’s SM, DLA, PVA and CPU logic, and the H64’s systolic, LNS and fixed-function tiles.
4. Far flight needs about 470 GB/s of peak DRAM.

Items 2 to 4 are data, or design choices; Phase 5 builds no model for them. Item 1 is where modelling or measurement is needed.

The parent plan’s Phase 5 items, against the strict rule

Item	What it produces	Under the strict rule
Measured stage-kernel efficiencies	CALIBRATED default_v1 entries from benchmarks run on the Orin AGX / Nano	Consistent: data, not fill
L1 DNN stages via UnifiedAnalyzer	Roofline service times for det, sdfenc, policy, vlm, vla	Model output, THEORETICAL. The Orin AGX mapper reports THEORETICAL (50%) even on ResNet-50. The stages’ own networks (YOLOe-class, a 2B VLM, the SDF encoder, the DRL policy) are not in the model factory, so stand-ins would carry their efficiency over to the stage’s ops.
L1 KPU stages (domain-flow wavefront cost model)	KPU service times from the SURE/SARE schedule	Model output, THEORETICAL. A research-scale item.
ILP mapper, split mappings	Better assignments of stages to engines	Consistent: infrastructure
RM/EDF response time, DRAM contention	Replaces the “owns the engine” lower bound	Consistent: infrastructure. It only bites once stages are priced.
Multi-block floorplan; die cost and yield	Area layout; cost per good die	Needs wafer cost and D0 per node, which are unsourced today (gaps)
Upstream schemas to embodied-schemas	IP block, SoC design and PipelineWorkload schemas	Consistent: housekeeping

Decision needed first

Which of these goes first is the user’s call (P5-D1). It sets whether Phase 5 prices the pipeline through measurement, through labelled model output, or leaves it priced by nothing while the infrastructure matures.

P5-D1, decided 2026-09-18: the measurement path first. Per-engine efficiencies come from stage-kernel benchmarks run on the target hardware. Neither model output from stand-in networks nor the KPU cost model is used to fill default_v1.

PR sequence (measurement path)

PR	Content
5.1	graphs.benchmarks.soc_kernels and cli/benchmark_soc_kernels.py. See the notes below.
5.2	tools/ingest_soc_kernel_benchmarks.py, plus efficiency-table layering (base:). See the notes below.
5.3	The Orin Nano and AGX runs (the user runs them on the hardware), the regenerated table, and the 4.3 study re-run on measured data.

5.1, the benchmark harness:

• It measures the kernel classes it has a representative kernel for, on the target, and writes a JSON document per run.
• The device clock is sampled throughout every timed loop, and a run is verified only when enough samples agree within 5%. This fixes the 2026-02 calibrations’ idle-clock readings.
• CPU kernels run pinned to one core, single-threaded, matching the analyzer’s one-core server.
• Seven kernel classes have no kernel yet and are listed as not covered: cost volume DP, feature tracking, kNN, raycast, wavefront, graph search, and pixel fixed-function. Update 2026-09-19 (6.5): six of them now have one, each sized like the stage it stands for; only kNN tree search is left, and no stage uses it.

5.2, the ingest and table layering:

• The ingest turns runs into a measured table layered over default_v1.
• Efficiency is attained ops/s over the composed block’s per-server peak at the measured clock.
• An entry is CALIBRATED when the clock was verified and INTERPOLATED otherwise.
• A format the IP template states no peak for stays a gap, with the measurement kept alongside it. (Orin’s SM had no FP16 rate at first; it now carries NVIDIA’s sourced dense FP16 tensor rate, so FP16 is ingested and only FP64 is left out.)

Infrastructure: response time and DRAM contention

RM/EDF response-time analysis (estimation/soc/response.py) turns the schedule’s “owns the engine” lower bound into a proven upper bound per stage. DRAM contention closes the hole that remained. Each task’s execution time used to include its memory time with the stage owning the whole sustained bandwidth, so a memory-bound stage could be “proven schedulable” on a bus it shares.

The bound.

• At most k servers issue DRAM traffic at once: per engine, its server count or its DRAM-using tasks, whichever is fewer.
• Each server is guaranteed supply / k. The analysis therefore multiplies each task’s memory time, and a split’s transfer, by k.
• Compute is unchanged. A compute-bound stage stays compute-bound until k x t_memory overtakes its compute time.
• The schedule keeps the owns-the-bandwidth time as the lower bound, so the true response lies between the two.

The assumption.

• The 1/k share is guaranteed by a fair arbiter, round-robin or TDM:
  • Akesson, Goossens & Ringhofer, “Predator”, CODES+ISSS 2007;
  • Paolieri, Quinones, Cazorla & Valero, IEEE Embedded Systems Letters 1(4), 2009.
• A COTS FR-FCFS controller does not guarantee it: Kim, de Niz, Andersson, Klein, Mutlu & Rajkumar, RTAS 2014. Tighter or controller-specific bounds need DRAM timing parameters that no design states.
• With k > 1 the analysis is therefore at most THEORETICAL, and its confidence source names the assumed arbiter.
• A design that states no DRAM supply leaves contention unbounded, and the analysis gives no upper bounds.

Effect on the shipped profiles (all_known test efficiencies, greedy mapping):

• AV L2 on the Orin reference loses its schedulability proof. At k = 7, 19 GB/s each, mono’s upper bound passes its deadline. The verdict is open, not failed: the lower bounds still hold.
• The KPU H64’s two edge-AI profiles stay proven.
• Every other profile was already open.