feat: denser activation packing, real bandwidth ceiling doubled (EXP-0081)

Implements the highest-leverage fix from EXP-0080's bottleneck
analysis: act_tile_fetch.v now packs 2 consecutive tiles per DDR3
burst (even tile low 64 bits, odd tile high 64 bits) instead of 1
tile per burst, halving real DDR3 bytes-per-useful-byte. Timing-safe
by construction: the tile-index select bit is registered at request
time, long before the real DDR3 round-trip completes, never racing
the arriving read data (unlike the runtime part-select pattern
EXP-0079 deliberately avoided).

Re-verified at all 3 levels (isolated engine 8/8, packed_slot.v 9/9
with bit-identical results to EXP-0079, full N=2 system on real DDR3
8/8) -- the real JEDEC trace now shows no half-burst padding, direct
confirmation the fix works in practice, not just in theory.

Also: real device data gathered on this package's I/O bank layout
(only 5 banks total, 14/15/16/34/35) informing the next bandwidth step
(32-bit-wide single controller recommended over a second independent
channel, given the pin/logic cost comparison).

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

hardware/v2/logs/experiments.log

@@ -5097,3 +5097,74 @@ 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).
+
+EXP-0081 -- denser activation packing: 2 tiles per burst, halving real
+DDR3 bytes-per-MAC (2026-09-20, same autonomous continuation, user's
+own direction: "procediamo #A che e gratis sicuramente" from the
+EXP-0080 analysis's ranked recommendations)
+
+CONTEXT: EXP-0080's analysis found the system is DDR3-bandwidth-bound
+(real 1.24GB/s measured vs 4.96GB/s needed per core at peak DSP rate)
+BECAUSE EXP-0079's activation layout moved 2 bytes of real DDR3
+traffic per useful byte (1 tile = 1 full burst, half padding). This
+experiment implements the analysis's own highest-leverage fix.
+
+DESIGN: act_tile_fetch.v's memory layout changed from "1 tile = 1
+burst" to "2 consecutive tiles share 1 burst" (even tile in the low 64
+bits, odd tile in the high 64 bits). Burst address = base +
+(tcnt>>1)*BURST_LEN. THE KEY SAFETY PROPERTY (why this doesn't
+reintroduce the runtime-part-select Fmax risk EXP-0079 deliberately
+avoided): the tile index's own LSB is captured into a registered
+`sel_lat` at REQUEST time -- many real ui_clk cycles before the DDR3
+round-trip completes and ctrl_rdata becomes valid -- so the eventual
+data-select mux uses an already-long-stable registered bit, never one
+racing the arriving read data.
+
+VERIFICATION (same 3-level discipline as EXP-0079, all re-run after
+the layout change):
+  1. tb_act_tile_fetch.v -- rewrote the preload/expected-value logic
+     for 2-tiles-per-burst, added new cases (even/odd tile in the same
+     burst, tile crossing into a new burst, alternating even/odd
+     back-to-back). 8/8 PASS on first real run.
+  2. tb_packed_slot.v -- preload_sdram_activations rewritten for the
+     new layout (N_TILES/2 bursts per position instead of N_TILES).
+     9/9 PASS, and critically the per-test numeric RESULTS are
+     bit-identical to EXP-0079's own run (a=0/b=127, a=127/b=0, etc.)
+     -- confirms this is purely an internal memory-layout optimization
+     with zero effect on computed results, exactly as intended.
+  3. tb_n2_system_ddr3.v -- same rewrite, re-run via real xsim against
+     the real ddr3_model.sv. 8/8 PASS, 0 errors, 8/8 positions
+     completed. The real JEDEC read trace now shows genuinely varied
+     data across the WHOLE burst (no more half-burst "0000" padding
+     visible in the log) -- direct, real, visual confirmation the
+     padding waste is actually gone from real DDR3 traffic, not just
+     claimed.
+
+DECISION: real DDR3 bytes-per-MAC for activation fetching is now 1
+(down from 2), meaning the real achievable fraction of one core's peak
+DSP throughput under §3.2's own analysis roughly DOUBLES (was ~25%,
+now ~50%, pending a fresh real bandwidth remeasurement -- the
+underlying 1.24GB/s ceiling itself is unchanged by this experiment,
+only the bytes-needed side of the ratio improved).
+
+next_action: real P&R re-verification (this changes real logic on the
+activation-fetch path, and the timing margin was already thin,
+EXP-0079's own +0.030ns) -- must confirm timing still closes before
+trusting this as done. Also: update docs/ARCHITECTURE_ANALYSIS.md S5.1
+from "proposed" to "done, verified" with the real re-measured numbers,
+and docs/PHYSICAL_REALIZATION.md S4's memory layout convention.
+
+Also this session: real device data gathered for the next planned
+step (raising real DDR3 bandwidth further) -- this package
+(xc7a100tcsg324-2) has only 5 total I/O banks (14/15/16/34/35).
+Banks 14/15 real-verified to have DQS-capable pins (8 each, matching
+banks 34/35's own memory-PHY signature) -- a genuine second MIG
+instance there is physically plausible, but would displace the
+already-placed SPI/flash-bridge pins with no real remaining bank to
+move them to (bank 16 has only 11 pins). Recommended instead (pending
+user confirmation): widen the EXISTING single MIG controller to 32-bit
+(natively wizard-supported, same 2x bandwidth gain, no pin
+displacement, no duplicated controller logic) over a second
+independent channel. User confirmed target: N=8 real cores; N=16 to
+be built and tested specifically to document where/how it breaks
+(real data for the analysis document, not a real deployment target).