docs: complete architecture analysis - DDR3 bandwidth is the real ceiling, not DSP count (EXP-0080)

Before building N=4/8/16 core scaling, did the requested full
analysis. Real finding: using measured DDR3 throughput (1.24 GB/s,
from the actual EXP-0079 JEDEC trace) against calculated compute-side
need (4.96 GB/s for one core at peak DSP throughput, given the
current activation memory layout's 2x byte overhead), the system is
memory-bandwidth-bound already at N=1/N=2, not DSP-bound (only 6.67%
DSP used). Scaling core count today would show no real throughput
gain.

docs/ARCHITECTURE_ANALYSIS.md: full module review + ranked
interventions -- result-writeback engine (blocker), denser activation
packing (highest-leverage bandwidth fix), then the user's own proposed
DDRManager/orchestrator-prefetch idea (design-sketched, grounded in
neural_director_packed.v's existing job queue, explicitly scoped as
complementary to denser packing, not a substitute for it), THEN
N-scaling with real per-N P&R signoff.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MUG92aM9m68TRc4rG55BcC

hardware/v2/logs/experiments.log

@@ -5031,3 +5031,69 @@ was already thin, +0.013ns, before this addition) -- must re-confirm
 timing still closes before calling this "ready to use in physical
 hardware". Also: finalize and commit docs/PHYSICAL_REALIZATION.md
 (drafted this session, real pin/part/protocol/layout data).
+
+EXP-0080 -- complete architecture analysis: real DDR3 bandwidth ceiling
+found and quantified, before any N-scaling work (2026-09-20, same
+autonomous continuation, user's own explicit request: "fai prima una
+analisi completa", plus their own proposed DDRManager/prefetch idea)
+
+CONTEXT: user asked for N=4/8/16 core scaling "sul prodotto finito"
+(on the real hardware). Before spending real engineering/P&R time
+building that blind, did the requested full analysis first -- and it
+changed the recommended plan substantially.
+
+REAL FINDING: using real measured numbers (DDR3 back-to-back burst
+throughput from the actual JEDEC trace in EXP-0079's own real
+simulation run: 128 bits / 12.9ns = 1.24 GB/s) against calculated
+compute-side bandwidth need (one packed core's real 155.039MHz Fmax x
+16 MACs/cycle = 2.48 GMAC/s, x 2 real DDR3 bytes/MAC under the current
+"1 tile = 1 full burst" activation layout, EXP-0079 = 4.96 GB/s
+needed) -- DDR3 can sustain at best ~25% of ONE core's peak DSP
+throughput. The system is memory-bandwidth-bound, not DSP-bound,
+already at N=1/N=2. Confirmed DSP headroom is real and large (16/240
+used, 6.67%) but irrelevant until the memory ceiling is addressed --
+scaling core count today would show near-identical real throughput to
+N=2, wasting real P&R cycles building N=4/8/16 for no real gain.
+
+Wrote docs/ARCHITECTURE_ANALYSIS.md: full module-by-module review,
+the real signoff history table (WNS non-monotonic across EXP-0074/76/
+78/79, confirmed NOT a trend to extrapolate from), and ranked
+recommended interventions:
+  1. Result-writeback engine (real blocker for N>2 regardless of
+     bandwidth -- same pin-explosion risk already caught once for
+     activations, EXP-0074).
+  2. Denser activation packing (1 byte/MAC instead of 2 -- doubles the
+     real achievable throughput ceiling) -- proposed a safer approach
+     than the runtime part-select EXP-0079 deliberately avoided
+     (register the tile-index bit one cycle ahead of the burst
+     response, keeping selection off the critical path) -- NOT yet
+     built or verified, flagged as needing a real prototype + P&R
+     check.
+  3. Re-measure real N=2 throughput with (2) in place BEFORE deciding
+     if N=4 is worth building.
+  4. User's own DDRManager/orchestrator-prefetch idea -- real design
+     sketch grounded in what already exists (neural_director_packed.v
+     already queues up to 8 pending jobs with known x_base/w_base --
+     exactly the "reservation" data a prefetch manager needs, no
+     Director changes required). Explicitly scoped: this hides
+     LATENCY (stalls waiting for a fetch), it does NOT raise the
+     bandwidth CEILING (2) does -- presented as complementary to (2),
+     not a substitute, since conflating the two would overstate what
+     prefetching alone can fix. Recommended minimal validation: one
+     slot's own double-buffered look-ahead prefetch (mirrors layer_
+     weight_buffer.v's already-proven double-buffer pattern) before
+     attempting the full multi-job-queue version.
+  5. Only then: N=4/8/16, each with its own real P&R (the margin is
+     thin and non-monotonic, EXP-0074..0079 -- no N's timing closure
+     predicts the next).
+
+DECISION: do not build N=4/8/16 yet. Real next engineering task is the
+result-writeback engine (genuine blocker) followed by denser
+activation packing (real bandwidth-ceiling fix, highest leverage found
+in this analysis) -- both real, scoped, bounded pieces of work, not
+speculative.
+
+next_action: await user direction on which recommended intervention
+to build first (result-writeback engine is the more clearly-scoped,
+lower-risk starting point; denser packing needs more design care given
+the thin timing margin).