Files
FPGA-Neural/hardware/v2/logs
micheleandClaude Sonnet 5 6a46dc857f fix: propagate runtime-indexed-crossbar fix to slot_mem_arbiter(_wide) + dataflow_core mux
DEC-0043: slot_mem_arbiter.v/slot_mem_arbiter_wide.v both still had the
exact runtime-variable-indexed part-select anti-pattern
(pending_addr[grant_idx*ADDR_WIDTH +: ADDR_WIDTH], grant_idx a runtime
register) that neural_director.v had already found and fixed once
before -- ADDR_WIDTH=26 not being a power of 2 means this synthesizes
as a real multiplier + wide crossbar, sitting right on the
arbiter<->backend boundary this project's own N=8 congestion diagnosis
names, growing with N_PORTS=N_SLOTS(+1). Also fixed the cheaper but
same-class dir_job_out_slot*16 mux in nms_dataflow_core_sdram.v,
feeding directly into dependency_manager -- this exact signal was
DEC-0042's own diagnosed N=4 critical path.

Fix: N_PORTS/N_SLOTS parallel constant-indexed comparisons (unrolled
for-loop) instead of a runtime-indexed read -- same technique already
proven in neural_director.v. Purely an internal-implementation change.

Verified bit-exact via Verilator: tb_fpga_neural_v2_top_smoke.v 11/11
PASS; tb_nms_dstress_sdram_unified.v (256-neuron stress) at both
N_SLOTS_CFG=4 and =8, 256/256 bit-exact vs golden, total_cycles
IDENTICAL to pre-fix historical values (49927/49909, exact match to
DEC-0042's own recorded numbers).

Bonus finding from the same D-Stress run (not this commit's main
point, logged for Phase 3/4): sdram_busy_cycles ~81.6% and
useful-MAC-cycle fraction HALVING from N=4 to N=8 (2.04%->1.02%) --
real existing evidence the system is memory-bound on a single SDRAM
bank well before N=8, independent of Fmax.

Re-synthesis (8-seed sweep, N=4/N=8) in progress to measure the actual
Fmax delta from this fix -- committed separately once complete.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-15 22:39:00 +00:00
..

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 in decisions.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, formato DEC-XXXX (vedi docs/v2-description.md §27).
  • experiments.log — registro principale, un EXP-XXXX per ogni esperimento end-to-end (config → sim/synth/timing → risultato), rimanda a reports/experiments/EXP-XXXX/.
  • errors.log — errori/bug/regressioni incontrati durante lo sviluppo V2 stesso (non i bug V1, già chiusi in hardware/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.