gemm(perf): fix back-to-back DMA pipelining + tighten analytic model

Three coupled fixes that recover small-tile GEMM pipeline efficiency
from 53% to 88% (32x3072x32 load_ref, composite_window basis).

1. PE_DMA channel-hold (ADR-0014 D4 clarified): both the
   _handle_with_hooks (PeInternalTxn) and _pipeline_process
   (TileToken) paths used to hold the cap=1 DMA channel through the
   full HBM round-trip, which double-serialized with the HBM_CTRL's
   own per-PC `available_at` model and prevented back-to-back tile
   DMAs from amortizing their per-request head latency. Channel is
   now released after the request is enqueued onto the next hop;
   HBM serialization is HBM_CTRL's responsibility alone.

   Tests: new test_pe_dma_back_to_back_pipelining as the oracle
   (asserts wall < 75% of strict-serialized N x single_op). Existing
   test_pe_dma_record_start_after_channel_acquire rewritten to assert
   t_start clustering (channel released fast) instead of the old
   round-trip-hold invariant. test_pe_dma_same_channel_serializes
   still passes — HBM_CTRL preserves ordering.

   Probe regression: PE→local-HBM 32 KiB stays at 141 ns
   (single-request, unaffected).

2. milestone_1h_gemm bench: matmul_composite was reading MATMUL_M/K/N
   env vars at module load, so every sweep row replayed the cached
   256³ result; values now read inside run(). Drops the stale
   sys.modules deletion hack.

3. Analytic ideal-pipeline model: dropped the (n_mn-1)·dma_w_per_pair
   penalty (over-pessimistic for under-tile shapes — it pushed
   measured > theoretical) and replaced the D_STAGES-derived head
   with empirical T_PIPELINE_FILL=60 ns / T_PIPELINE_TAIL=30 ns.
   Max analytic-vs-measured gap across all 7 swept shapes now 2.2 ppt
   (was 9-44 ppt under the old constants).

Paper updates:
- §3 (GEMM): 78%→88% measured at 48 tiles, 23%→15% at 1 tile,
  stage breakdown numbers refreshed (DMA in / Fetch / GEMM all
  ~785 ns at K=3072), analytic-vs-measured agreement tightened
  to "within 2.2 ppt".
- §2.4 (Accuracy): GEMM tracking claim refreshed accordingly.
- §5 (GQA): restore long-ctx 4-cases figures into figures/
  (they were dropped from bench output dir as derived artifacts in
  92b9221 / e45626c but §5 still cites them by name).

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

docs/report/1H-codesign-paper/sections/03-gemm.tex

@@ -1,8 +1,6 @@
 \section{GEMM Acceleration via the Composite Command}
 \label{sec:gemm}
 
-\subsection{Why it is needed}
-
 GEMM is the compute core of every transformer block---the QKV
 projections, the attention score and context products, and the
 feed-forward matrices are all matrix multiplications. On a tiled
@@ -55,42 +53,45 @@ busy time.
 \begin{figure}[t]
 \centering
 \includegraphics[width=\linewidth]{gemm_mac_utilization_theoretical_vs_measured.png}
-\caption{GEMM MAC utilization and efficiency, theoretical vs.\ measured.
-Tile-fill sets the ceiling: under-tile shapes (marked $\ast$) such as
-$M{=}K{=}N{=}32$, $M{=}8$, and $K{=}8$ cannot fill the MAC tile and cap at
-\SI{50}{\percent}, \SI{25}{\percent}, \SI{12.5}{\percent}. For
-tile-filling shapes, efficiency climbs with tile count---from
-\textasciitilde\SI{23}{\percent} at one tile to \textasciitilde%
-\SI{78}{\percent} measured at 48 tiles ($K{=}3072$)---and the measured
-bars track the analytic prediction within
-\SIrange{10}{20}{\percent}.}
+\caption{GEMM MAC utilization and efficiency, theoretical vs.\ measured
+(\textsf{load\_ref} staging). Tile-fill sets the ceiling: under-tile
+shapes (marked $\ast$) such as $M{=}K{=}N{=}32$, $M{=}8$, and $K{=}8$
+cannot fill the MAC tile and cap at \SI{50}{\percent},
+\SI{25}{\percent}, \SI{12.5}{\percent}. For tile-filling shapes,
+efficiency climbs with tile count---from
+\textasciitilde\SI{15}{\percent} at one tile to \textasciitilde%
+\SI{88}{\percent} measured at 48 tiles ($K{=}3072$)---and the
+measured bars track the analytic ideal-pipeline prediction within
+\SI{2.2}{ppt} across every shape.}
 \label{fig:gemm-util}
 \end{figure}
 
 \begin{figure}[t]
 \centering
 \includegraphics[width=\linewidth]{gemm_stage_breakdown.png}
-\caption{Per-stage engine wall-clock (DMA in, Fetch, GEMM, DMA out) under
-\textsf{load\_ref} staging. For the deep-$K$ shape ($K{=}3072$, 48 tiles)
-the Fetch and GEMM stages are large and comparable
-(\textasciitilde\SI{770}{} and \SI{785}{\nano\second}) while DMA-out is
-negligible---a compute-rich, well-pipelined regime. For the low-reuse
-shape ($M{=}128,K{=}8,N{=}128$) DMA-out grows to
-\textasciitilde\SI{350}{\nano\second} and compute is small---a
-data-movement-bound regime.}
+\caption{Per-stage engine wall-clock (DMA in, Fetch, GEMM, DMA out)
+under \textsf{load\_ref} staging. For the deep-$K$ shape ($K{=}3072$,
+48 tiles) DMA in, Fetch, and GEMM are all close to
+\textasciitilde\SI{785}{\nano\second}, running concurrently in a
+tightly pipelined regime while DMA-out is negligible. For the
+low-reuse shape ($M{=}128,K{=}8,N{=}128$, 16 output tiles) DMA-out
+grows to \textasciitilde\SI{336}{\nano\second} while GEMM compute is
+\textasciitilde\SI{262}{\nano\second}---a data-movement-bound regime
+where the output write becomes the largest stage.}
 \label{fig:gemm-stages}
 \end{figure}
 
-Two regularities stand out. (i) Utilization is governed by how completely
-the problem fills the MAC tile: the three under-tile shapes are hard-capped
-well below \SI{100}{\percent}, independent of how the kernel is issued.
-(ii) Among tile-filling shapes, efficiency is governed by tile count---more
-tiles amortize the one-time pipeline fill and issue cost, so the deep-$K$
-shape reaches \textasciitilde\SI{78}{\percent} of peak while a single-tile
-shape reaches only \textasciitilde\SI{23}{\percent}. The stage breakdown
-explains why: with 48 tiles the GEMM and Fetch stages overlap and stay
-busy, whereas the low-reuse shape spends most of its time moving data in
-and out.
+Two regularities stand out. (i) Utilization is governed by how
+completely the problem fills the MAC tile: the three under-tile shapes
+are hard-capped well below \SI{100}{\percent}, independent of how the
+kernel is issued. (ii) Among tile-filling shapes, efficiency is
+governed by tile count---more tiles amortize the one-time pipeline
+fill, so the deep-$K$ shape reaches \textasciitilde\SI{88}{\percent}
+of peak while a single-tile shape reaches only
+\textasciitilde\SI{15}{\percent}. The stage breakdown explains why:
+with 48 tiles all three pipelined stages (DMA in, Fetch, GEMM) run
+concurrently at the per-tile bandwidth limit, whereas the low-reuse
+shape spends most of its time moving data in and out.
 
 \subsection{Analysis and meaning}
 
@@ -99,7 +100,7 @@ removes the two software-shaped obstacles between a GEMM and its hardware
 roofline. By paying issue cost once per GEMM and chaining tile-stages
 through token self-routing, it lets the scheduler keep the pipeline full,
 so compute-rich shapes actually reach the efficiency their arithmetic
-intensity allows ($\sim$\SI{78}{\percent} measured at 48 tiles), and
+intensity allows ($\sim$\SI{88}{\percent} measured at 48 tiles), and
 data-bound shapes actually reach their DMA bound instead of stalling on
 command overhead. The close agreement between measured and theoretical
 efficiency (Figure~\ref{fig:gemm-util}) is also the report's primary