docs: decisive test -- pipelining both cores does NOT fix the lottery; fault is outside the datapath (Refs #1764)

docs/NOW.md

@@ -1,7 +1,14 @@
-# NOW — pipeline prototype: bit-exact but a dropped-in register won't reduce depth (2026-08-08)
+# NOW — pipelining the shared cores does NOT fix the lottery; fault is outside the datapath (2026-08-08)
 
 Last updated: 2026-08-08
 
+## docs: the decisive test — pipelining both cores (mid-cloud, bit-exact) does NOT fix the lottery; fault is outside the arithmetic datapath (Refs #1764)
+
+- Ran the decisive silicon experiment for the whole pipeline branch. Pipelined BOTH shared cores latency-1 with a register INSIDE the combinational cloud (GftSmul_p2b cut mid-RNE, GftSadd_p2 cut mid-cascade), each VERIFIED BIT-EXACT to its combinational core over 40-60k random operands (incl. zero + exact-cancellation corners); integrated trainer bit-exact in sim, fmax 32 MHz (vs 21 baseline)
+- On the AX7203, 4 seeds: 0/4 trained stably. Seeds 2,3 were near-model at ep0 (0/0.718/0.886/-0.011 and 0/0.551/1.021/0.506) then collapsed to all-zero by ep20 (the characteristic glitch); seeds 1,4 glitched from ep0 -- same as baseline (~1/8 stable)
+- CONCLUSION: registering the core datapath -- endpoints (cycle 97) OR mid-cloud (now) -- does NOT fix the fault. So the hazard is NOT in the GftSmul/GftSadd combinational datapath at all. This closes the entire "pipeline the cores" branch (cycles 94-99)
+- REDIRECT: the next suspects are the rf-write / control path (register the destination index di + write-enable; harden pc/settle/cen counters) and a global placement effect (clock skew/routing). Added ruled-out #10. Board restored to generated capstone (XOR 4/4). (Sample is 4 seeds; base rate ~1/8, so 0/4 is indicative not a zero-improvement proof.) Docs only. Refs #1764
+
 ## docs: pipeline prototype — bit-exact, but naive RTL register insertion does not reduce depth; go spec-level on_clock (Refs #1764)
 
 - Started Variant 1 (pipeline the shared core) with an RTL prototype, after first ruling out the cheap route: yosys automatic retiming (`synth_xilinx -retime`) moves only a few levels (ltp 57->51 on GftSadd with 2 output regs) -- not enough to split the cloud

docs/SILICON_TRAINING_METHODOLOGY.md

@@ -168,13 +168,28 @@ does not re-run them:
    register. **Implication for the pipeline: it must be a *spec-level* `on_clock` where the
    compiler co-optimizes the stages (and the multiply becomes a real pipelined primitive),
    not a register hand-inserted into the codegen output.**
-
-Live path: **a spec-level `on_clock` pipelined `GftSadd`/`GftSmul`** (compiler-scheduled
-stages, not a hand-dropped register), whose *mid-cloud resynchronization* is the untested
-lever against the hazard. Since the microsequencer already waits `settle` ≫ 1 cycle, a
-latency-1 pipelined core needs no sequencer change — the decisive experiment is to build
-the trainer on pipelined cores and see if the glitch dies. Open experiment: an **MMCM**
-real divided clock. Prototypes bit-exact-verified in `scratchpad/retime/`.
+10. **Pipelining the shared cores (mid-cloud registers) — the decisive silicon test —
+    does NOT fix the lottery.** Both cores were pipelined latency-1 with a register *inside*
+    the combinational cloud (`GftSmul_p2b` cut mid-RNE, `GftSadd_p2` cut mid-cascade), each
+    verified **bit-exact** to its combinational core over 40–60 k random operands (including
+    zero and exact-cancellation corners), and the integrated trainer is bit-exact in
+    simulation and reaches **fmax 32 MHz** (vs 21 baseline). Flashed on the AX7203 across
+    four seeds: **0 / 4 trained stably** — seeds 2 and 3 were near-model at ep0
+    (y = 0/0.718/0.886/−0.011 and 0/0.551/1.021/0.506) then collapsed to all-zero by ep20,
+    the characteristic training-divergence glitch; seeds 1, 4 glitched from ep0. This is the
+    same behaviour as the baseline (~1/8 seeds stable), so **registering the core datapath —
+    at the endpoints (item 7) *or* mid-cloud — does not fix the fault.** Together these say
+    the hazard is **not in the `GftSmul`/`GftSadd` combinational datapath at all** — it lives
+    in the register-file write / control path (`di` destination decode, `pc`/`settle`/`cen`
+    counters, or the write-capture), or is a global placement effect. (Sample is four seeds;
+    the base rate is ~1/8, so 0/4 is indicative, not a proof of zero improvement.)
+
+Live path (redirected): **the fault is outside the arithmetic cores.** Registering the
+datapath (endpoints and mid-cloud) does not help, so the next suspects are the **rf-write /
+control path** — register the destination index `di` and the write-enable, and/or harden the
+`pc`/`settle`/`cen` counters — and a **global placement** effect (clock skew / routing).
+Open experiment: an **MMCM** real divided clock. Bit-exact core prototypes in
+`scratchpad/retime/`; pipelined trainer in `scratchpad/board/bppipe/`.
 
 ## Reproducibility