V2.0.0 hardware freeze - single SDRAM

FASE #1 hardware freeze for FPGA-Neural V2, N4/P8, single external
SDRAM (Alliance Memory AS4C4M16SA-6TIN) serving weights, activations,
and results through one physical sdram_controller.v instance. Removes
the PSRAM dependency (hardware/v1/rtl/psram_controller.v +
memory_interface.v) from the V2 physical path entirely -- V1 itself
remains fully unmodified, the golden reference.

New RTL: sdram_unified_backend.v (2-way W/AR arbitration over one
SDRAM controller, real per-byte DQM write masking added to
sdram_controller.v for correct single-byte result writes with no
read-modify-write), nms_neural_multiprocessor_sdram_unified.v (the
frozen top-level). Two real bugs found and fixed via full-system
testing before being accepted (ERR-0023): a deadlock and an off-by-one
data-shift bug in the new arbitration logic.

Real results: N=4 and N=2 D-Stress bit-exact (256/256 neurons), 40
real AUTO REFRESH events interleaved with zero corruption, real
Yosys+nextpnr-ecp5 synthesis/P&R for LFE5U-45F-8CABGA381 (149/245
TRELLIS_IO, a real 45-pin reduction from the prior dual-memory
design). Timing is MARGINAL (1/8 P&R seeds >=80MHz), reported honestly
rather than masked by the best seed.

Real, sourced ball-level pinout for the SDRAM bus + clk/rst (39/149
signals, P&R-verified) using the official Lattice ECP5U-45 pinout CSV
found on disk during this step's own pre-commit review -- corrects an
earlier draft that wrongly assumed no real pinout data was available.

Chip readiness: NO. Real, disclosed blockers remain (no physical host
interface exists yet -- the RTL's own reg_* ports are a 110-pin raw
test-harness bus; clock source/PLL decision; power/configuration
component selection) -- see hardware/v2/docs/{HARDWARE_FREEZE,
CHIP_READINESS,OPEN_ITEMS}.md for the complete, itemized status.

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

hardware/v2/logs/architecture.log

@@ -12,3 +12,46 @@ NP_ERROR as an isolated fault (report + exclude from scheduling) rather
 than a system-wide halt, once the Director (M5) exists to observe it.
 No shared/global reset or shared bus signal is driven by any single
 processor's error state at M1.
+
+[2026-09-05] NMS STEP2 -- closed-form traffic model (activation/weight/
+result bytes/cycle), cross-validated against EXP-0017's real simulated
+floor.
+Per slot, at steady-state 1 tile/cycle compute consumption (P_IN=8,
+DATA_WIDTH=8):
+  WEIGHT traffic: never shared across neurons (each neuron owns its
+    weight vector) -- exactly P_IN=8 bytes/cycle/slot, always, with no
+    possible amortization.
+  ACTIVATION traffic: WORST CASE (no sharing, e.g. a cache miss every
+    tile, or genuinely different x_base per concurrent request) is
+    also P_IN=8 bytes/cycle/slot -- identical to weight traffic, since
+    both halves of a tile are the same size. BEST CASE (many neurons
+    of one layer sharing one x_base, fetched once and served from an
+    on-chip buffer thereafter -- exactly what
+    hardware/v2/rtl/activation_cache.v already exploits, DEC-0016) is
+    close to 0 bytes/cycle/slot amortized across the whole layer after
+    the first fetch.
+  RESULT traffic: exactly 1 byte per completed neuron, spread over
+    that neuron's own n_tiles cycles -- 1/n_tiles bytes/cycle/slot,
+    negligible next to activation/weight for any realistic n_tiles
+    (e.g. 1/16 for a 16-tile neuron) -- a low-bandwidth, low-priority
+    background stream, matching the LOW-priority scheduler tier the
+    user's own NMS spec calls for.
+TOTAL per-slot demand: 8 B/cycle/slot (weight only, activation fully
+  amortized -- the aggressive/ideal NMS target) to 16 B/cycle/slot
+  (weight + activation, no sharing exploited -- the SAFE worst-case
+  floor). The 16 B/cycle/slot worst case is EXACTLY EXP-0017's own
+  measured simulated floor (TILE_BYTES=2*P_IN modeled combined,
+  unshared activation+weight per tile) -- a clean cross-validation of
+  the simulated result against the closed-form model, not a
+  coincidence: EXP-0017's harness never modeled activation sharing at
+  all (every tile issues its own fresh 16-byte fetch), i.e. it directly
+  measured the worst-case floor this note derives analytically.
+IMPLICATION for STEP3 (bank/bandwidth architectural sweep): the NMS's
+  own Activation SRAM (built correctly -- banked/pipelined, not the
+  current single-tag, Fmax-fragile activation_cache.v) is what
+  determines whether the system sits near the 8 B/cycle/slot ideal or
+  the 16 B/cycle/slot worst case for a given workload's real
+  producer/consumer locality -- the Weight SRAM's own bandwidth
+  requirement is fixed and non-negotiable at P_IN bytes/cycle/slot
+  regardless of any caching scheme (weights are never shared, per
+  §6/§11 of the user's own NMS spec).