Files
FPGA-Neural/hardware/v2/logs
micheleandClaude Sonnet 5 3cdaeaee35 test(v2): final benchmark campaign - real end-to-end characterization (EXP-0014)
Post-M10, user-requested final benchmark campaign: 6 realistic
workloads (16-256 independent neurons in a shared-input dense-layer
shape, a random-seeded 2-layer network with real cross-node PSRAM
forwarding, and a 6-node 2-hop dependency diamond) x 4 concurrency
levels (N_SLOTS=1/2/4/8) through the real, full neural_multiprocessor
system (real V1 PSRAM chain, real slot_mem_arbiter). 24/24 runs PASS
bit-exact against a software golden model (11,520 individual neuron/
node checks, zero mismatches).

Three real bugs found and fixed during the campaign itself (ERR-0009):
1. neural_director.v (M5) had a real RTL bug at N_SLOTS=1
   ($clog2(1)=0 makes a replication expression illegal) - never
   caught because M5-M10 only ever tested N_SLOTS=2/4/8. Fixed with
   a width-agnostic '0 literal; M5's own testbench re-verified
   unaffected.
2/3. Two testbench sizing bugs in tb_benchmark_suite.v itself
   (psram_model DEPTH too small for the Large workload's address
   range; N_NODES too small for the Stress workload's node-id range,
   causing a real deadlock via node-id wraparound colliding with an
   already-DISPATCHED node - a real, honest consequence of DEC-0008's
   own "no node-slot reclamation" design choice).

Headline finding: real parallel scaling is essentially flat beyond
N_SLOTS=2 - the single shared PSRAM port saturates at ~91%
utilization regardless of slot count, so memory-bound workloads gain
only 1.05-1.06x real speedup from N=1 to N=8. Once real POST-P&R Fmax
degradation is also factored in, N_SLOTS=4 is measurably 21% SLOWER
in real wall-clock time than N_SLOTS=1 for the largest workload
tested. N_SLOTS=2 is recommended as the default (DEC-0014,
superseding DEC-0012's resource-only "N_SLOTS=8 ceiling" framing for
general use).

Full 21-section report (every number classified THEORETICAL/
SIMULATED/POST-P&R MEASURED/DERIVED, per the user's own
methodology requirements): hardware/v2/docs/benchmarks/
final-benchmark.md

Logged: simulation/synthesis/timing/benchmark/decisions (DEC-0014)/
experiments (EXP-0014)/errors (ERR-0009)/development.log,
ROADMAP.md updated.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013xXuuRUWZScuo1DeYJxs3v
2026-09-05 19:58:30 +02: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.