FPGA-Neural/hardware/v2/logs/development.log

# V2 development log — solo append, mai troncato/sovrascritto (vedi README.md)

[2026-09-05T11:14:08Z] commit=07a48e4 session=v2-kickoff
module: scaffold
action: creato hardware/v1/ (baseline V1 congelata, sola lettura) e
  hardware/v2/ (struttura obbligatoria: rtl/ sim/ constraints/ synthesis/
  reports/{simulation,synthesis,timing,experiments}/ scripts/sweep/ logs/
  docs/), per iniziare lo sviluppo V2 richiesto da docs/v2-description.md.
reason: richiesta utente esplicita -- "Crea un v1 con tutto il codice
  attuale che non deve essere modificato per nessun motivo e lavora su
  una v2 copiando quello che ti serve. Aggiornami frequentemente e crea
  un log nuovo."
command: cp rtl/*.v sim/*.v tools/ synth/ecp5/{p2,p4,p8,post_fix_verify}
  synth/ecp5/*.lpf docs/validation/*.md WORKLOG.md
  docs/FPGA-NeuralNetwork-Engine.md docs/FPGA-Neural-Datapatch-Benchmark.md
  docs/FPGA-Neural-Hardware-Design.md -> hardware/v1/{rtl,sim,tools,
  constraints,synthesis,docs}; chmod -R a-w su tutto hardware/v1/.
result: verificato bit-esatto (`diff -rq rtl/ hardware/v1/rtl/` e cmp
  file-per-file su sim/*.v, 0 differenze). hardware/v1/ reso sola lettura
  a livello filesystem come ulteriore salvaguardia oltre alla policy.
  hardware/v2/ vuoto tranne logs/ (questo file + README.md).
errors: nessuno.
decision: copia (non spostamento) dell'albero top-level rtl/sim/synth/
  tools -- l'albero principale del repository resta la "produzione" V1
  invariata; hardware/v1/ e' una seconda copia frozen dedicata al
  confronto V2, per minimizzare il rischio di rompere riferimenti/path
  esistenti in WORKLOG.md, docs/, altri script. Vedi decisions.log
  DEC-0001 per la motivazione completa.
next_action: M1 (docs/v2-description.md §33) -- implementare
  hardware/v2/rtl/neural_processor.v (P_IN=8), pipeline 8 stage,
  bit-exact contro hardware/v1/rtl/neuron_parallel.v + mac8.v,
  testbench hardware/v2/sim/tb_neural_processor.v.

[2026-09-05T12:03:12Z] commit=07a48e4 session=v2-M1-neural-processor
module: hardware/v2/rtl/neural_processor.v + hardware/v2/sim/
  tb_neural_processor.v
action: implementato M1 (docs/v2-description.md §33) -- Neural
  Processor P_IN=8, pipeline a 8 stadi (input align -> 8 moltiplicatori
  -> 3 livelli di albero di somma -> accumulatore -> bias/activation ->
  saturazione INT8), FSM a 7 stati (§6, con 4 stati assorbiti in
  NP_WAIT_OPERANDS per il vero throughput pipeline -- vedi
  decisions.log DEC-0002), interfacce valid/ready/data/last (§7).
  Aritmetica bit-esatta con hardware/v1/rtl/neuron_parallel.v +
  mac8.v + mac_unit.v.
reason: roadmap M1, richiesta esplicita utente di iniziare lo sviluppo
  V2 copiando da V1 quanto necessario.
result: 3 bug reali incontrati e risolti durante lo sviluppo (vedi
  errors.log ERR-0001/0002/0003) -- due erano bug del toolchain Icarus
  Verilog v13.0 (non del RTL), confermati installando e usando
  Verilator 5.050 come secondo simulatore indipendente (decisions.log
  DEC-0004); uno era un bug RTL reale (gating mancante su `last0`,
  fix verificato). Testbench finale: 7/7 test PASS, bit-exact contro
  V1, sia a ACC_WIDTH=32 che ACC_WIDTH=24 (esperimento richiesto
  dall'utente, experiments.log EXP-0002). Sintesi reale Yosys + P&R
  reale nextpnr-ecp5: 0 problemi CHECK, Fmax 183.12 MHz (ACC_WIDTH=32)
  / 176.21 MHz (ACC_WIDTH=24) -- entrambi PASS a 80MHz con ampio
  margine, ~3x il Fmax isolato di V1 a PARALLEL=8 (61.71 MHz).
errors: vedi errors.log ERR-0001, ERR-0002, ERR-0003, ERR-0004.
decision: vedi decisions.log DEC-0002, DEC-0003, DEC-0004.
next_action: M2 -- neural_processor_array.v, sweep N_PROCESSORS
  (1,2,4,8), misura timing/risorse/throughput/utilization reali.

[2026-09-05T14:30:00Z] commit=dc0b331 session=v2-M2-processor-array
module: hardware/v2/rtl/neural_processor_array.v + hardware/v2/sim/
  tb_neural_processor_array.v + hardware/v2/synthesis/
  harness_neural_processor_array.v
action: implementato M2 -- Neural Processor Array, N_PROCESSORS
  parametrico, ogni processore con interfaccia job/operand/result
  dedicata (nessun bus condiviso/mux a questo livello, §7). Testato
  N_PROCESSORS=4 con esecuzione concorrente reale (lancio simultaneo
  di 4 job diversi, più un test a partenza sfalsata) e con lo sweep
  reale N_PROCESSORS={1,2,4,8} per sintesi/place&route.
reason: roadmap M2.
result: 7/7 test PASS (Verilator), confermata esecuzione concorrente e
  indipendente (un job più corto lanciato dopo completa prima di uno
  più lungo lanciato prima -- non c'e' serializzazione nascosta).
  Sintesi/P&R reali per N=1/2/4/8: 0 problemi CHECK, scaling lineare
  delle risorse, Fmax sempre PASS a 80MHz (159.11/149.59/151.01/134.70
  MHz). Scoperta reale non assunta: il DSP (MULT18X18D) e' la prima
  risorsa a saturare (88% a N=8), non LUT/FF (sotto il 6% anche a
  N=8) -- vedi decisions.log DEC-0005.
errors: ERR-0005 (artefatto di sintesi da pin-count, non un bug RTL --
  workaround con un harness dedicato, vedi errors.log). Un primo
  tentativo di harness alimentava dati identici a ogni processore/lane
  MAC, e Yosys deduplicava silenziosamente tutto a 1x indipendentemente
  da N -- scoperto verificando che lo scaling fosse davvero lineare
  prima di fidarsi dei numeri.
decision: vedi decisions.log DEC-0005.
next_action: M3 -- activation_buffer.v / weight_buffer.v /
  result_buffer.v (profondita' parametrica, valutare BRAM mapping).

[2026-09-05T15:15:00Z] commit=3026dcd session=v2-M3-buffers
module: hardware/v2/rtl/activation_buffer.v, weight_buffer.v,
  result_buffer.v
action: implementato M3 -- tre buffer paramentrici (profondita'
  parametrica) che inferiscono DP16KD reale, riusando l'idioma gia'
  validato in hardware/v1/rtl/act_buffer.v (porta A scrittura sync,
  porta B lettura sync REGISTRATA, nessun reset sulla porta di lettura
  per restare fuori dal percorso LUT-RAM).
reason: roadmap M3.
result: 10/10 test PASS (Verilator). Sintesi reale a 2 profondita'
  ciascuno: 0 problemi CHECK, DP16KD reale confermato in tutte le 6
  configurazioni (mai LUT-RAM). Scoperta reale non assunta: il costo
  BRAM di weight_buffer e' determinato dalla LARGHEZZA (P_IN*DATA_
  WIDTH=64 bit), non dalla profondita' -- 512->64 di profondita' non
  ha ridotto il conteggio DP16KD (resta 2). Place&route reale sui
  default: tutti PASS a 80MHz con ampio margine (287-367 MHz).
errors: nessuno.
decision: vedi benchmark.log -- il dimensionamento di weight_buffer
  andra' guidato da P_IN, non solo da DEPTH, quando si arrivera' a
  M4/M9.
next_action: M4 -- memory_manager.v + prefetch_engine.v.

[2026-09-05T16:00:00Z] commit=5f0d7f1 session=v2-M4-memory-manager
module: hardware/v2/rtl/memory_manager.v, prefetch_engine.v
action: implementato M4 -- Memory Manager (arbitraggio/buffering/
  forwarding/gestione latenza/double buffering, §12) + Prefetch Engine
  (fetch a doppio buffer con retargeting di una singola istanza per
  banco, §13). Backend PSRAM V1 riusato SENZA MODIFICHE
  (int8_memory_access.v -> memory_interface.v -> psram_controller.v,
  §15), integrato end-to-end con un vero hardware/v2/rtl/
  neural_processor.v (M1).
reason: roadmap M4.
result: 3/3 job PASS end-to-end (1/3/5 tile), risultato verificato con
  RILETTURA INDIPENDENTE da PSRAM (non solo ispezione di segnali
  interni), con byte "poison" attorno alle regioni operando per
  catturare eventuali errori di indirizzamento off-by-one (nessuno
  trovato). 3 bug RTL reali trovati e risolti durante l'integrazione
  (vedi errors.log ERR-0006): mancava una disciplina "una sola
  richiesta di prefetch in volo", un buco di un ciclo nel check
  !pf_busy, un mux di stato disallineato di un ciclo che faceva
  silenziosamente perdere la scrittura del risultato su PSRAM.
  Sintesi reale: 0 problemi, 851 LUT4/789 FF/108 CCU2C/0 DSP (atteso).
  Fmax reale (via harness, stesso motivo pin-count di ERR-0005):
  165.86 MHz, PASS a 80MHz.
errors: vedi errors.log ERR-0005 (ricorrenza), ERR-0006 (3 bug nuovi).
decision: vedi decisions.log DEC-0006 (motore di prefetch singolo +
  registro pendente, nessun arbitro backend ancora necessario).
next_action: M5 -- neural_director.v, scheduling first-free.

[2026-09-05T17:00:00Z] commit=175f697 session=v2-M5-neural-director
module: hardware/v2/rtl/neural_director.v
action: implementato M5 -- Neural Director, scheduling first-free
  (§9) su N_SLOTS coppie (memory_manager, neural_processor). FSM
  ridotta a 4 stati (DIR_IDLE/SCAN_READY/ALLOCATE/ERROR) -- dependency
  tracking/wake-up rimandati al Dependency Manager (M6, non ancora
  costruito), rilevamento completamenti gestito da un tracker
  sempre-attivo per-slot (non uno stato dedicato da rivisitare).
reason: roadmap M5.
result: 4/4 test PASS (N_SLOTS=2) -- dispatch first-free confermato,
  coda pronta con backpressure reale confermata (riempimento e
  recupero), 3 job su 2 slot con il terzo correttamente in coda fino
  a liberazione di uno slot. 2 bug di testbench trovati e risolti
  (non RTL): DEPTH di sim_byte_mem troppo piccolo per il range di
  indirizzi usato, e una condizione di attesa che si fermava al primo
  job completato invece che a tutti e tre. Sintesi reale: 0 problemi,
  382 LUT4/366 FF/4 CCU2C/0 DSP. Fmax reale (via harness): 250.50 MHz.
errors: nessun bug RTL, solo 2 bug di testbench (vedi experiments.log
  EXP-0006).
decision: vedi decisions.log DEC-0007.
next_action: M6 -- dependency_manager.v.

[2026-09-05T18:00:00Z] commit=2e4cedc session=v2-M6-dependency-manager
module: hardware/v2/rtl/dependency_manager.v
action: implementato M6 -- tabella di dipendenze (node_id/state/
  required/resolved/producer_ids, campi esatti §10), wake-up su
  completamento produttore, dispatch first-found-ready verso il
  Director (M5).
reason: roadmap M6.
result: 4/4 test PASS su un piccolo DAG a mano (node2 dipende da
  ENTRAMBI node0+node1 -- dipendenze multiple; node3 dipende solo da
  node0 -- risultato condiviso/piu' consumer). Confermato: node3 pronto
  subito dopo node0, node2 resta WAITING finche' anche node1 non
  completa. Sintesi reale: 0 problemi, 763 LUT4/474 FF/0 DSP/0 CCU2C.
  Fmax reale (nessun harness necessario stavolta): 155.30 MHz.
errors: un errore di sintassi nel testbench (nested replication senza
  livello di parentesi extra), non un bug RTL.
decision: vedi decisions.log DEC-0008 (nessun forwarding di valori
  ancora, nessun riuso degli slot ancora -- entrambi rimandati
  esplicitamente).
next_action: M7 -- dataflow_core.v, prima integrazione di
  Director+Dependency Manager+Memory Manager+Processor Array+Buffer
  in un unico top-level.

[2026-09-05] M7 -- hardware/v2/rtl/dataflow_core.v
reason: roadmap M7 -- first full integration of dependency_manager
  (M6) + neural_director (M5) + N_SLOTS x (memory_manager (M4) +
  neural_processor (M1)) into one top-level module, closing the
  producer-completion -> dependency-wake-up loop end-to-end for the
  first time. Additive extension to neural_director.v: added a
  slot_node_id output port (which node_id occupies each slot) so a
  caller can map a completed slot back to the node_id that just
  finished -- re-verified M5's own testbench still passes 4/4
  unaffected.
result: 4/4 test PASS on a 3-node DAG (node2 depends on BOTH node0 and
  node1; confirmed it does NOT dispatch until both genuinely complete,
  polled every cycle). Real synthesis: 0 problems at both N_SLOTS=2
  (LUT4=2127/CCU2C=248/FF=2505/DSP=16) and N_SLOTS=4
  (LUT4=3953/CCU2C=500/FF=4688/DSP=32). Real Fmax (via
  harness_dataflow_core.v): 165.15 MHz (N_SLOTS=2), 133.19 MHz
  (N_SLOTS=4), both PASS at 80MHz.
errors: one Yosys build-script usage quirk (errors.log ERR-0007,
  chparam target ordering), not an RTL bug.
decision: see decisions.log DEC-0009 (M3 buffers not wired in yet, no
  shared-PSRAM arbitration across slots yet -- both deferred to M8).
next_action: M8 -- PSRAM integration. Wire the real (unmodified) V1
  PSRAM backend chain through dataflow_core end-to-end and measure/
  design whatever N_SLOTS>1 arbitration real contention requires.

[2026-09-05] M8 -- hardware/v2/rtl/neural_multiprocessor.v +
hardware/v2/rtl/slot_mem_arbiter.v
reason: roadmap M8 -- "Integrare il controller V1 senza modificarlo
  inizialmente. Misurare il comportamento reale." dataflow_core.v (M7,
  untouched) now shares the real, unmodified V1 PSRAM backend chain
  (int8_memory_access -> memory_interface -> psram_controller) across
  N_SLOTS genuinely concurrent memory_manager instances, via a new
  generic N-port arbiter inspired by (not copied from) V1's own
  mem_arbiter.v.
result: real concurrent-slot simulation immediately surfaced a real
  bug (errors.log ERR-0008: the byte-level backend's fire-and-forget
  request pulse gets silently dropped by a naive arbiter under
  contention) -- fixed with a pending-request latch. After the fix:
  4/4 test PASS (2 concurrent slots genuinely contending for one real
  PSRAM port, 444 cycles). Real synthesis: 0 problems, LUT4=3145/
  CCU2C=388/FF=3659/DSP=16, real Fmax 142.45 MHz (PASS at 80MHz, no
  harness needed -- real PSRAM pins keep the top-level pin count at
  157). No regression on M4's own testbench.
errors: see errors.log ERR-0008 (real RTL bug, found and fixed).
decision: see decisions.log DEC-0010 (fixed-priority arbitration, no
  fairness yet -- deferred pending real measured need).
next_action: M9 -- Full benchmark (§32): V1-vs-V2 comparison table,
  every number labeled THEORETICAL/SIMULATED/SYNTHESIZED/POST-P&R.

[2026-09-05] M9 -- Confronto finale V1 vs V2 (§32)
reason: roadmap M9 -- produrre la tabella di confronto mandata dal
  mandato, ogni numero classificato THEORETICAL/SIMULATED/SYNTHESIZED/
  POST-P&R, nessun risultato inventato (§30).
result: tabella completa in benchmark.log (M9 entry) -- V2 full-system
  (neural_multiprocessor, N_SLOTS=2, M8) supera V1 full-system
  (spi_neuron_top, PARALLEL=8, post_fix_verify) su ogni asse reale
  misurato: Fmax POST-P&R 142.45 vs 68.65 MHz (V1 FALLISCE il target
  80MHz, V2 lo supera), 166 vs 209 cicli SIMULATED per un neurone/8
  input attraverso la stessa vera catena PSRAM V1 (2.6x speedup
  wall-clock reale), MAC/cycle di picco 16 vs 8 (concorrenza reale a
  livello di sistema, N_SLOTS=2, gia' dimostrata con vera contesa
  PSRAM in EXP-0009). LUT/FF di V2 sono anche piu' bassi (4191/3659 vs
  8907/4900) nonostante il sistema completo comprenda gia' scheduling
  a grafo di dipendenze che V1 non ha affatto.
errors: nessuno (consolidamento dati, nessun nuovo RTL).
decision: vedi decisions.log DEC-0011 (stall %/utilization non
  misurati questo milestone -- richiedono strumentazione dedicata,
  rimandata a M10 dove diventa direttamente utile).
next_action: M10 -- Optimization, sulla base dei dati reali raccolti
  in M1-M9.

[2026-09-05] M10 -- Optimization (finale della roadmap V2, §33)
reason: roadmap M10 -- ottimizzare SOLO sulla base dei dati reali
  raccolti in M1-M9, sugli assi: pipeline, P_IN, numero processor,
  buffer, FIFO, scheduling, prefetch, routing, memoria.
result: tre azioni concrete, tutte basate su dati reali gia' raccolti
  o su nuove misure reali mirate a colmare lacune gia' documentate:
  (1) N_SLOTS=8 sintetizzato e P&R reale (92.63 MHz, PASS @80MHz,
  DSP 64/72=88.9%) -- conferma e completa il limite gia' previsto da
  DEC-0005, formalizzato come DEC-0012 (N_SLOTS=8 tetto pratico per
  P_IN=8 su questo chip). (2) Sweep reale a 6 seed di piazzamento per
  ACC_WIDTH 24 vs 32 (riusando i netlist gia' sintetizzati) -- risolve
  l'inconcludenza a singolo seed di EXP-0002: ACC_WIDTH=24 vince sia
  in Fmax medio (+6.2%) che in varianza (~3.4x piu' stretta),
  formalizzato come DEC-0013 (ACC_WIDTH=24 nuovo default
  raccomandato). (3) Strumentazione di conteggio cicli aggiunta al
  testbench M8 (nessun RTL toccato) -- chiude la lacuna di
  DEC-0011 con dati reali SIMULATED: porta PSRAM condivisa
  utilizzata all'81.7%, slot0 al 95.2%, slot1 al 65.2% (nessuna prova
  conclusiva di starvation dannosa su un test cosi' piccolo).
errors: nessuno.
decision: vedi decisions.log DEC-0012 e DEC-0013.
next_action: nessuna prevista dal mandato (§33 termina a M10) -- la
  roadmap V2 a 10 milestone e' ora completa end-to-end, da M1 (singolo
  neural_processor) a M9 (benchmark completo V1 vs V2) a M10 (risultati
  di ottimizzazione basati sui dati). Elementi ancora aperti restano
  tutti esplicitamente rimandati dalle proprie DEC entry (non
  dimenticanze): riuso slot in dependency_manager (DEC-0008),
  fairness dell'arbitro sotto contesa piu' estesa (DEC-0010), sweep
  P_IN<8 per N_SLOTS ancora piu' alto (DEC-0012 alternativa #2), riuso
  dei buffer M3 come cache condivisa (DEC-0009), strumentazione
  stall%/utilization anche lato V1 (DEC-0011).

[2026-09-05] Final Benchmark Campaign (post-M10, richiesta diretta
utente, non parte del roadmap §33)
reason: caratterizzare le prestazioni reali end-to-end di V2 prima di
  decidere il numero finale di unita' parallele (N_SLOTS) e prima di
  scrivere il datasheet V2. Nessun test funzionale isolato, nessuna
  ottimizzazione prima della misura, come esplicitamente richiesto.
result: 6 workload realistici (16-256 neuroni indipendenti + un layer
  multilivello con dati random seed loggato + un DAG a diamante a 2
  hop) verificati bit-exact su 4 configurazioni (N_SLOTS=1/2/4/8) --
  24/24 PASS dopo aver risolto 3 problemi reali (errors.log ERR-0009).
  Scoperta principale: lo scaling parallelo reale e' sostanzialmente
  PIATTO per i workload memory-bound (1.05-1.06x da N=1 a N=8) -- il
  vero collo di bottiglia e' la porta PSRAM condivisa (~91% utilizzo
  indipendentemente da N_SLOTS>=2), non il numero di processori.
  Considerando anche il vero Fmax POST-P&R (152.46/142.45/113.38 MHz
  per N=1/2/4), N_SLOTS=4 e' realmente PIU' LENTO del 21% in
  wall-clock rispetto a N_SLOTS=1 per il workload Stress. Trovato
  squilibrio reale di scheduling (slot a indice basso fanno quasi
  tutto il lavoro).
errors: vedi errors.log ERR-0009 (1 bug RTL reale in neural_director.v,
  mai testato prima a N_SLOTS=1; 2 bug nel testbench stesso).
decision: vedi decisions.log DEC-0014 -- N_SLOTS=2 raccomandato come
  configurazione di default, non N_SLOTS=8 (DEC-0012 resta valido come
  tetto DSP mafisico, non come raccomandazione d'uso generale).
next_action: datasheet V2 in stile professionale (richiesta utente),
  ora sbloccato dalla decisione su N_SLOTS.

[2026-09-05] Ottimizzazione #1 -- burst read a livello di parola
(word-level), su richiesta esplicita dell'utente
reason: dopo la campagna di benchmark finale, l'utente ha chiesto
  concretamente di implementare la raccomandazione #1 (sfruttare il
  page-mode gia' presente nel controller PSRAM leggendo piu' byte in
  una sola transazione, non uno alla volta).
result: prefetch_engine.v/memory_manager.v riscritti per parlare
  direttamente il protocollo a 16 bit di memory_interface.v (bypassando
  int8_memory_access.v, che resta comunque congelato e non modificato
  -- semplicemente non piu' istanziato in questo percorso dati).
  Risultato reale misurato: -49/-54/-56% cicli su job singoli (M4),
  2.24-2.37x speedup reale in wall-clock sull'intera campagna finale
  (24/24 ancora bit-exact), a fronte di un costo Fmax reale piccolo
  (-6.2% a N_SLOTS=2, -1.2% a N_SLOTS=4, invariato a N_SLOTS=1).
errors: nessuno (implementazione pulita, nessuna regressione).
decision: vedi decisions.log DEC-0015.
next_action: ottimizzazione #2 -- cache condivisa on-chip per il
  vettore di attivazione (X), per eliminare le letture ridondanti tra
  neuroni che condividono lo stesso input di layer.

[2026-09-05] Ottimizzazione #2 -- cache condivisa on-chip per il
vettore di attivazione, su richiesta esplicita dell'utente
reason: dopo l'ottimizzazione #1 (burst a livello di parola), l'utente
  ha chiesto di implementare anche la #2: cache condivisa per evitare
  che ogni neurone rilegga da PSRAM lo stesso vettore X gia' letto da
  un altro neurone dello stesso layer.
result: nuovo modulo activation_cache.v (single-tag, granularita' a
  tile, condiviso tra tutti gli slot). Trovati e risolti 2 bug reali
  durante l'implementazione (errors.log ERR-0010): una race
  target-bank/pending-bank (stessa classe di ERR-0006) e una ripetizione
  del bug a larghezza zero di ERR-0009 (N_SLOTS=1). Dopo il fix: 24/24
  PASS bit-exact. Beneficio reale misurato: ulteriore riduzione cicli
  1.66-2.00x oltre l'ottimizzazione #1 (circa 4x combinato rispetto
  alla baseline originale byte-level). MA costo reale in Fmax molto piu'
  ripido del previsto: N_SLOTS=2 scende da 133.58 a 87.72 MHz (-34%,
  ancora sopra 80MHz ma con margine molto piu' sottile), N_SLOTS=4
  scende a 65.01 MHz e ORA FALLISCE il target 80MHz (prima passava).
  Speedup reale in wall-clock rispetto alla baseline originale:
  N=1 3.86x, N=2 2.45x, N=4 2.29x (ma con una regressione reale
  rispetto alla sola ottimizzazione #1, dato che N=4 ora fallisce il
  timing).
errors: vedi errors.log ERR-0010 (2 bug RTL reali, trovati e risolti).
decision: vedi decisions.log DEC-0016 -- vittoria reale netta
  confermata per N_SLOTS=1/2 (l'intervallo raccomandato, DEC-0014
  resta valida), regressione reale a N_SLOTS=4 (mai la configurazione
  raccomandata, ma un costo reale onestamente riportato, non nascosto).
  Pipeline della logica di hit-check della cache segnalato come lavoro
  futuro concreto se servisse N_SLOTS>2 con la cache attiva.
next_action: nessuna ulteriore richiesta esplicitamente dall'utente per
  questo giro. Datasheet V2 professionale, ora con dati definitivi
  post-ottimizzazione da includere.

=== Sessione: NMS (Neural Memory System) -- avvio, STEP1 ===
timestamp: 2026-09-05
session: v2-NMS-STEP1
Avviato il nuovo progetto NMS (Neural Memory System), richiesto
dall'utente per superare il collo di bottiglia PSRAM condiviso emerso
dalla campagna finale V2 (91% utilizzo, N_SLOTS>=2 senza scaling
reale). Obiettivo: separare COMPUTE DOMAIN (Neural Processor x N) da
MEMORY DOMAIN (nuovo NMS: scheduler/prefetch/DMA/bank manager) da
BACKING STORAGE (PSRAM V1, invariata). Sviluppato interamente sotto
hardware/v2/nms/ (rtl/, sim/, docs/, reports/), senza toccare
hardware/v2/rtl/ esistente (baseline V2 congelata e sempre
confrontabile).

Seguito l'ordine di lavoro esplicitamente richiesto dall'utente (NON
scrivere RTL complesso prima di avere dati): completato STEP1
(bandwidth requirement study) -- vedi experiments.log EXP-0017,
errors.log ERR-0011 (3 bug reali trovati e risolti nel NUOVO harness
di simulazione stesso, non nel V2 congelato), decisions.log DEC-0017.
Nuovi file: hardware/v2/nms/rtl/ideal_memory_model.v (modello di
memoria idealizzato, SOLO simulazione, mai sintetizzato),
hardware/v2/nms/sim/tb_bandwidth_study.v (harness di sweep, riusa
hardware/v2/rtl/neural_processor.v reale e invariato per il lato
compute).
next_action: STEP2 (analisi matematica del traffico, in gran parte
  derivabile a costo zero dai dati EXP-0017) poi STEP3 (sweep
  architetturale bank/bandwidth in simulazione, usando i floor di
  EXP-0017/DEC-0017 come target di progetto, non come ipotesi).

=== Sessione: NMS STEP3 (bank contention sweep) ===
timestamp: 2026-09-05
session: v2-NMS-STEP3
Completato STEP3 (sweep architetturale bank/bandwidth in simulazione).
Nuovi file: hardware/v2/nms/rtl/ideal_banked_activation.v (modello di
riferimento a N_BANKS fisso), hardware/v2/nms/sim/tb_bank_contention.v
(harness di sweep runtime su N_BANKS/stagger). Risultato chiave: con
N_BANKS=N_SLOTS (banking + broadcast su stesso indirizzo + arbitraggio
round-robin sui conflitti), lo scaling parallelo aggregato torna quasi
lineare (N=8 -> 7.87x vs N=1) anche con stagger di dispatch realistico
-- vedi EXP-0018/DEC-0018. 2 bug reali trovati e risolti nel nuovo
harness (ERR-0012): priorita' fissa -> starvation permanente; latch
job_started su job_ready invece che sull'handshake reale job_valid&&
job_ready.
next_action: STEP4 -- selezionare 2-3 architetture candidate per la
  sintesi reale (Yosys+nextpnr-ecp5), usando N_BANKS=N_SLOTS come
  candidato guida ma confrontando anche N_BANKS<N_SLOTS per il costo
  reale BRAM/Fmax.

=== Sessione: NMS STEP4/5/6 (candidati Activation + Weight SRAM, sintesi reale) ===
timestamp: 2026-09-06
session: v2-NMS-STEP4-STEP5-STEP6
Completati STEP4 (selezione candidati), STEP5 (sintesi reale) e STEP6
(place&route reale) per entrambe le meta' del sottosistema memoria NMS:

Activation SRAM: 2 candidati reali (nms_activation_replicated.v,
nms_activation_banked.v), entrambi verificati bit-exact in simulazione
(broadcast, no-contesa, contesa forzata sullo stesso banco), poi
sintetizzati per N_SLOTS=2/4/8 x MAX_TILES=16/256 -- vedi EXP-0019.
Vinto: replicated (Fmax 2-4x piu' alto, ~24x meno LUT a N_SLOTS=8,
nessun arbitraggio -> nessuna possibile starvation), costo reale BRAM
accettabile (8 DP16KD, 7% del chip, a MAX_TILES=256/N_SLOTS=8) --
DEC-0019.

Weight SRAM: 2 candidati reali (nms_weight_direct.v, nms_weight_packed.v),
entrambi verificati bit-exact, sintetizzati stesso sweep -- vedi
EXP-0020. Vinto: packed (stessa BRAM di direct, ~2x meno LUT/FF a
N_SLOTS=8/MAX_TILES=256, Fmax comparabile) -- DEC-0020.

Costo reale combinato: 16 DP16KD (14.8% del chip) a N_SLOTS=8 con
vettori profondi realistici -- onestamente accettabile.
next_action: STEP7 e' concluso per la parte memoria. STEP8 --
  integrazione NMS completa (prefetch engine, DMA, scheduler,
  forwarding, interfaccia verso Neural Processor) -- ancora da fare.

=== Sessione: NMS STEP8 (integrazione completa, bit-exact) ===
timestamp: 2026-09-06
session: v2-NMS-STEP8
Completata l'integrazione STEP8: nms_dataflow_core.v (Dependency
Manager + Neural Director riusati invariati + N_SLOTS x
nms_memory_manager/neural_processor + nms_activation_fill_ctrl
condiviso, su nms_activation_replicated.v + nms_weight_packed.v).
2 bug reali trovati e risolti (ERR-0013): mancava un secondo stadio
di pipeline sulla lettura SRAM (risultato calcolato = 0 invece del
valore reale, causa lettura di un ciclo troppo presto); race nel
riavvio del prefetch peso privato che duplicava/saltava tile alterni
per job con n_tiles>1 (mai testato prima, dato che i primi test
usavano tutti n_tiles=1). 7/7 test PASS bit-exact (stesso DAG di
dataflow_core.v M7, test di broadcast su x_base condiviso, nuovo test
n_tiles=4) -- EXP-0021/DEC-0021.
next_action: STEP9 (benchmark end-to-end con Fmax reale da sintesi) e
  STEP10 (tabella di confronto Current V2 vs NMS).

=== Sessione: NMS STEP9/STEP10 (benchmark reale + confronto finale) -- ROADMAP CHIUSA ===
timestamp: 2026-09-06
session: v2-NMS-STEP9-STEP10
Completati STEP9 (benchmark end-to-end reale, Fmax da sintesi reale) e
STEP10 (confronto Current V2 vs NMS), chiudendo l'intera roadmap NMS
(STEP1-STEP10).

Nuovo file: nms_neural_multiprocessor.v (top-level reale, rispecchia
neural_multiprocessor.v: nms_dataflow_core.v + slot_mem_arbiter.v reale
+ catena PSRAM V1 reale). Sintesi reale N_SLOTS=1/2/4/8. Benchmark
D-Stress reale (256 neuroni, 16 tile, stesso workload della campagna
V2) via psram_model.v reale, adattando tb_benchmark_suite.v.

4 bug reali trovati e risolti (ERR-0014), tutti la stessa causa radice:
un contatore che deve rappresentare il VALORE MAX_TILES stesso (non
solo indicizzarlo 0..MAX_TILES-1) dichiarato con la larghezza sbagliata
in 4 punti diversi (nms_memory_manager.v x2, nms_activation_fill_ctrl.v,
e il wire di collegamento in nms_dataflow_core.v) -- mai esposto prima
perche' nessun test STEP8 usava n_tiles=MAX_TILES esattamente.

Risultato finale (EXP-0022/DEC-0022): a N_SLOTS=2 (la config
raccomandata), NMS batte V2 attuale del 6.0% in wall-clock reale
(93.10MHz vs 87.72MHz Fmax reale) usando il 55% in meno di LUT4 e il
10% in meno di FF, a parita' di DSP/BRAM, bit-exact sullo stesso
workload D-Stress. A N_SLOTS=4, invece, V2 attuale vince ancora
(NMS -12.9%) per un problema di Fmax reale nel fill controller
condiviso dell'activation (stesso tipo di problema gia' documentato
per activation_cache.v in DEC-0016) -- pipeline del suo scan di
priorita' e' il fix concreto, non ancora tentato.
next_action: pipeline nms_activation_fill_ctrl.v per recuperare
  N_SLOTS=4/8; completare N_SLOTS=1/8 su D-Stress per parita' con la
  tabella V2. Nessun'altra richiesta esplicita dall'utente al momento.