Implements optimization #1 from the final benchmark campaign's own recommendation: exploit psram_controller.v's already-implemented page-mode support (confirmed present by direct inspection) by fetching multiple bytes per real backend transaction instead of one at a time. Root cause addressed: int8_memory_access.v (the byte-level backend prefetch_engine.v originally sat on) already converts every 8-bit logical request into a full 16-bit PSRAM word access internally (mem_addr <= addr >> 1), discarding half of every word it already paid for. prefetch_engine.v/memory_manager.v now speak memory_interface.v's own 16-bit word protocol directly, bypassing int8_memory_access.v entirely - which remains untouched, still frozen V1 (§1/§34); V2 simply reuses the lower layer of the same frozen chain instead of the byte-splitting layer on top of it, the same "reuse what fits" precedent slot_mem_arbiter.v already set. slot_mem_arbiter.v and neural_multiprocessor.v widened to match (lb_n/ub_n added, master port wired directly to memory_interface.v). Real, measured results: M4's own single-job testbench shows 49-56% fewer cycles (166->84, 446->204, 728->322, all still bit-exact). The full final-benchmark campaign (24/24 workload/config combinations) re-verified bit-exact with D-Stress's real wall-clock time (cycles / real POST-P&R Fmax) improving 2.24-2.37x across every N_SLOTS tested, against a small real Fmax cost (unchanged at N=1, -6.2% at N=2, -1.2% at N=4). tb_neural_multiprocessor.v (M8) and tb_benchmark_suite.v (final campaign) needed zero changes - both treat neural_multiprocessor.v as a black box. Only tb_memory_manager.v (M4, rewired to skip int8_memory_access.v) and tb_dataflow_core.v (M7, behavioral model widened to word-level) needed updates. The "real parallel scaling is flat beyond N_SLOTS=2" finding (DEC-0014) still holds - this optimization made the shared PSRAM port more efficient per transaction, not multi-ported - so N_SLOTS=2 remains the recommended default. Logged: simulation/synthesis/timing/benchmark/decisions (DEC-0015)/ experiments (EXP-0015)/development.log. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013xXuuRUWZScuo1DeYJxs3v
Formato dei log V2
Regola non negoziabile (docs/v2-description.md §25-29): ogni attività
significativa (modifica, simulazione, sintesi, benchmark, decisione, errore)
deve essere registrata. Nessun log viene mai sovrascritto o troncato — solo
append. Nessun ID esperimento (EXP-XXXX) o decisione (DEC-XXXX) viene mai
riutilizzato, anche se il risultato è un FAIL.
File
development.log— log principale di sviluppo, un'entry per ogni sessione di lavoro/milestone (creazione file, refactor, avanzamento roadmap).architecture.log— decisioni e note di architettura a grana fine (non scelte finali — quelle vanno indecisions.log— ma esplorazioni, alternative considerate, vincoli scoperti).simulation.log— ogni run di simulazione (Icarus/Verilator): test, vettori, cicli, PASS/FAIL, confronto bit-exact con V1, stall/memory-wait.synthesis.log— ogni run Yosys: LUT/FF/DSP/BRAM, warning, problemi CHECK.timing.log— ogni run nextpnr-ecp5: Fmax, percorso critico, WNS/TNS se disponibili. Fmax "ufficiale" di una configurazione = solo da qui, mai da simulazione o stima.benchmark.log— tabelle di confronto per configurazione (Fmax, MAC/cycle, cycles/neuron, utilization, ecc.), sempre con etichetta THEORETICAL/SIMULATED/SYNTHESIZED/POST-P&R.decisions.log— decisioni architetturali importanti, formatoDEC-XXXX(vedidocs/v2-description.md§27).experiments.log— registro principale, unEXP-XXXXper ogni esperimento end-to-end (config → sim/synth/timing → risultato), rimanda areports/experiments/EXP-XXXX/.errors.log— errori/bug/regressioni incontrati durante lo sviluppo V2 stesso (non i bug V1, già chiusi inhardware/v1/docs/validation/bugs.md).
Campi minimi per entry (§26)
timestamp, experiment_id (se applicabile), git_commit, session/agent,
module, configuration, action, reason, command, result, errors, decision,
next_action
Per synthesis/timing aggiungere: LUT, FF, DSP, BRAM, Fmax, critical path, WNS/TNS. Per simulazione: test, vectors, cycles, PASS/FAIL, bit-exact result, stall cycles, memory wait, utilization.