FPGA-Neural/hardware/v1/docs/validation/bugs.md

# Registro bug — campagna di ri-certificazione FPGA-Neural

Formato per ogni voce: severità, sintomo, causa radice, evidenza (file:riga / comando/log
citabile), stato, test di regressione che lo blocca (se risolto) o che lo riprodurrebbe (se
aperto). Aggiornato incrementalmente man mano che avanzano gli aspetti C.1–C.14.

Severità: **CRITICA** (corrompe dati/hang in scenari raggiungibili), **MEDIA** (comportamento
scorretto in casi limite plausibili ma rari), **BASSA** (difetto reale ma senza impatto
funzionale pratico), **INFO** (non un bug: gap di copertura, ambiguità documentale/naming).

---

## Aperti

(nessuno — tutti i bug della campagna sono stati corretti e verificati, vedi "Risolti" sotto)

---

## Risolti

### BUG-001 (INFO) — `sim/top.v` non compila contro l'RTL corrente

- **Sintomo**: `iverilog` fallisce con `parameter FRAC_BITS not found in top.dut`.
- **Causa radice**: `sim/top.v` è un residuo della versione Q8.8 a virgola fissa del
  progetto, mai aggiornato dopo la conversione a INT8 puro (Fase 6, vedi
  `docs/validation/00-inventario.md` §0.2).
- **Evidenza**: `iverilog -g2012 -o /tmp/topcheck.out rtl/neuron_parallel.v rtl/mac8.v rtl/mac_unit.v sim/top.v` → 2 errori di elaborazione.
- **Impatto**: nessuno sulla regressione (il file non è referenziato da alcun testbench o
  tool) — era dead code, non un difetto funzionale del design.
- **Fix applicato**: file rimosso (`git rm sim/top.v`) — confermato non referenziato da alcun
  testbench o tool (`tools/run_regression.py` lo esclude esplicitamente dal proprio elenco
  sorgenti anche prima della rimozione).
- **Stato**: **RISOLTO** — file eliminato, nessun test di regressione necessario (non c'era
  comportamento da preservare).

### BUG-002 (MEDIA, CONFERMATO su sim + sintesi reale) — `N_INPUTS=0` bypassa il guard, `start` viene silenziosamente ignorato

- **Sintomo confermato** (non più un'ipotesi — vedi `docs/validation/01-datapath.md` §1.4 per
  la narrativa completa, incl. un falso positivo iniziale nella mia stessa metodologia di
  test, corretto e ridocumentato per trasparenza): con
  `neuron_parallel #(.N_INPUTS(0), .PARALLEL(P))`, il guard elaboration-time
  (`rtl/neuron_parallel.v:71`, `if (N_INPUTS % PARALLEL != 0)`) **non scatta** (`0 % P == 0`
  per ogni `P`), il modulo **elabora con successo** (sia in simulazione Icarus sia in sintesi
  reale Yosys, 0 problemi CHECK). A runtime: `start` viene accettato ma **`busy` non si alza
  mai e `done` non pulsa mai** — non l'hang "busy resta alto per sempre" descritto nel
  commento originale del guard (righe 55-58), un sintomo diverso, osservato per la prima
  volta in questa campagna.
- **Causa radice, confermata (non più ipotesi)**: `x_bus`/`w_bus` sono dichiarati
  `[DATA_WIDTH*N_INPUTS-1:0]`, che per `N_INPUTS=0` diventa `[-1:0]` — un range che **non
  collassa a larghezza zero**: sia Icarus sia Yosys lo trattano come un vettore reale a
  **2 bit** (larghezza = |MSB-LSB|+1 = 2), lasciato non pilotato. Confermato dai warning di
  Yosys: `Wire ...x_bus[1] is used but has no driver` (×2, per x_bus e w_bus).
- **Evidenza**:
  - `iverilog -g2012 -o /tmp/n0proper.out rtl/neuron_parallel.v rtl/mac8.v rtl/mac_unit.v sim/neuron_parallel_bug002_n_inputs_zero_tb.v && vvp /tmp/n0proper.out` → conferma il sintomo, ogni volta.
  - `yosys -p "synth_ecp5 -json /tmp/n0.json -top n0_synth_wrap" rtl/neuron_parallel.v rtl/mac8.v rtl/mac_unit.v <wrapper>` → **0 problemi CHECK**, 4 warning "no driver" su x_bus/w_bus[1:0].
  - Test di regressione permanente: `sim/neuron_parallel_bug002_n_inputs_zero_tb.v`.
- **Impatto pratico**: `N_INPUTS` è un parametro Verilog fissato in fase di sintesi (non un
  registro configurabile via SPI a runtime) — per essere raggiunto, qualcuno deve
  deliberatamente istanziare il modulo con `N_INPUTS=0`, cosa che non ha senso semantico per
  un layer reale. Rischio quindi basso in pratica (nessun percorso runtime/host-controllato
  può innescarlo), ma è un buco reale e confermato nella protezione, non solo teorico.
- **Fix applicato** (`rtl/neuron_parallel.v`, guard di elaborazione): esteso a
  `if (N_INPUTS == 0 || N_INPUTS % PARALLEL != 0)` — `N_INPUTS=0` ora fa fallire
  l'elaborazione con lo stesso errore `Unknown module type:
  neuron_parallel_requires_N_INPUTS_multiple_of_PARALLEL` dei due test negativi già
  esistenti, invece di elaborare con successo e produrre `start` silenziosamente ignorato.
- **Test di regressione**: `sim/neuron_parallel_bug002_n_inputs_zero_tb.v`, riscritto per
  asserire il fallimento di compilazione (stesso pattern di
  `neuron_parallel_guard_negative_*_tb.v`), aggiunto a `EXPECTED_COMPILE_FAIL` in
  `tools/run_regression.py`. Verificato: `iverilog -g2012 -o /tmp/out rtl/neuron_parallel.v sim/neuron_parallel_bug002_n_inputs_zero_tb.v` → errore di elaborazione atteso, exit code 3.
- **Stato**: **RISOLTO, verificato.**

### BUG-003 (MEDIA, CONFERMATO ma NON pienamente caratterizzato) — `n_inputs_real=0` a runtime, comportamento incoerente tra ripetizioni

- **Sintomo**: con `N_INPUTS=32, PARALLEL=8` validi a compile-time (nessun problema di
  larghezza `[-1:0]`, a differenza di BUG-002), impostando `n_inputs_real=0` a runtime (lo
  stesso percorso raggiungibile dall'host via `SET_BASE sel=7`) il comportamento osservato
  **varia tra ripetizioni quasi identiche dello stesso test**: a volte `start` viene
  accettato ma `busy`/`done` non si muovono mai più (hang), a volte l'operazione completa
  normalmente ma processa l'INTERA larghezza di build invece di zero elementi (limite
  ignorato silenziosamente, stessa classe di BUG-004). Vedi `docs/validation/
  02-runtime-width.md` §2.3 per la registrazione completa di ogni singola ripetizione e dei
  suoi risultati, riportati senza scartare quelli "scomodi".
- **Causa radice**: **non isolata con certezza** entro il tempo ragionevole per questa
  campagna. Analisi aritmetica plausibile (non confermata come spiegazione completa): per
  questa build `GROUP_INDEX_WIDTH=2` bit, quindi `groups_real[1:0]-1` per `groups_real=0`
  avvolge al valore 3 (raggiungibile da un contatore a 2 bit, a differenza del contatore a
  1 bit di BUG-002) — spiegherebbe l'esito "limite ignorato" come esito aritmeticamente
  atteso, ma non spiega perché in alcune ripetizioni compaia invece un hang vero. Esclusi
  esplicitamente: propagazione di X in simulazione (verificato inizializzando ogni registro
  prima di qualunque reset, il comportamento non cambia), e una dipendenza semplice
  dall'ordine delle chiamate (una sequenza valida→zero non blocca; una sequenza
  zero→zero→zero blocca dalla seconda chiamata in poi, non dalla prima — non un pattern
  semplice "prima volta sicura, poi no").
- **Impatto pratico**: come BUG-002, `n_inputs_real=0` non ha senso semantico per una rete
  reale, ma a differenza di BUG-002 questo valore **è raggiungibile a runtime da un host via
  SPI** senza bisogno di una nuova sintesi — un host con un bug che calcola erroneamente
  `n_inputs_real=0` per un caso limite (es. un layer con zero neuroni in una topologia
  degenere) potrebbe innescarlo, con un esito imprevedibile tra hang e risultato
  silenziosamente sbagliato.
- **Fix applicato** (`rtl/neuron_parallel.v`, dentro `if (start && !busy)`):
  `finishing <= (n_inputs_real == 16'h0);` (era `finishing <= 0;`) — riusa il percorso di
  completamento "finishing" già corretto ed esistente nel modulo invece di introdurre nuova
  logica per il caso degenere, stessa convenzione già usata altrove nel progetto. Per zero
  input reali il risultato matematico è `y = activation(bias)`: con `bias=0` e ACT_RELU nel
  test di regressione, `expect_y=0`.
- **Nota onestà**: il meccanismo esatto per cui il comportamento pre-fix variava tra
  ripetizioni (hang vs. risultato sbagliato silenzioso) **non è stato isolato bit-per-bit**
  neppure in fase di correzione — il fix è un early-out esplicito che bypassa
  l'intero percorso ambiguo, verificato corretto e deterministico sul nuovo comportamento,
  non una spiegazione a posteriori del vecchio meccanismo.
- **Test di regressione**: `sim/neuron_parallel_bug003_n_inputs_real_zero_tb.v` TEST 4,
  riscritto da osservazione ad asserzione hard (done entro 8 cicli, `y===0`). Verificato:
  `n_inputs_real=0` completa in **1 ciclo**, `y=0` — TUTTI I TEST PASSED (incluse le TEST
  1-3 di non-regressione sulla regione "poison").
- **Stato**: **RISOLTO, verificato** (il meccanismo esatto del comportamento PRE-fix resta
  non isolato per intero, per trasparenza, ma non è più rilevante: il nuovo percorso è
  deterministico e verificato indipendentemente).

### BUG-004 (MEDIA, CONFERMATO scorretto, NON pienamente caratterizzato) — `n_neurons_real=0` non blocca, ma non fa nemmeno quello che ci si aspetterebbe in modo coerente

- **Sintomo**: a `rtl/neuron_memory.v`, con `n_neurons_real=0`, l'operazione **completa
  sempre normalmente** (mai un hang, a differenza di BUG-002/003) — ma il numero di cicli
  impiegato **non è coerente tra build diverse**: per `N_NEURONS=2` (`NEURON_INDEX_WIDTH=1`
  bit) impiega **esattamente** lo stesso numero di cicli di `n_neurons_real=2` (114=114,
  suggerendo che il limite venga ignorato e processi tutto), mentre per `N_NEURONS=3`
  (`NEURON_INDEX_WIDTH=2` bit) impiega **196 cicli — più della build completa a 3 neuroni
  (155)**, un terzo valore che non corrisponde né a "zero neuroni" né a "tutti i neuroni".
  In ogni caso testato: nessun errore, nessun timeout — un host che chiede zero neuroni
  riceve sempre un completamento dall'aspetto normale ma su un conteggio/dato diverso da
  quanto richiesto, e il conteggio esatto varia con `N_NEURONS`.
- **Causa radice**: non isolata bit-per-bit (a differenza di BUG-002). Ipotesi coerente con
  BUG-003: l'aritmetica di avvolgimento (`neuron_index == n_neurons_real[W-1:0]-1`) per
  `n_neurons_real=0` produce un valore di terminazione che, per coincidenza di larghezza,
  corrisponde al conteggio pieno invece che a "termina subito".
  Vedi `docs/validation/02-runtime-width.md` §2.5.
- **Impatto pratico**: come BUG-002/003, richiede che l'host imposti deliberatamente (o per
  bug proprio) `n_neurons_real=0` — non raggiungibile da un input esterno arbitrario, ma
  raggiungibile da un bug nel software host senza bisogno di ricompilare il bitstream.
- **Fix applicato** (`rtl/neuron_memory.v`, tre punti coordinati, non uno solo): il pattern
  vulnerabile esisteva in TRE punti distinti, non uno — scoperto durante la correzione stessa
  (un primo tentativo di guard solo al dispatch `STATE_IDLE`→`STATE_READ_X` è stato
  riconosciuto insufficiente perché copriva un solo dei tre punti d'ingresso nello stato
  vulnerabile `STATE_READ_W`, che viene rientrato indipendentemente una volta per neurone nel
  loop). Fix corretto (single-point-of-truth sulle CONDIZIONI di terminazione, non sui punti
  di dispatch): `STATE_READ_X` e `STATE_READ_W` guadagnano entrambe un prefisso
  `n_inputs_real == 16'h0 ||`/`n_neurons_real == 16'h0 ||` sulla propria condizione di
  terminazione, e il punto di transizione X→W guadagna un ramo esplicito
  `if (n_neurons_real == 16'h0) begin busy<=0; done<=1; state<=STATE_IDLE; end`.
- **Test di regressione**: `sim/neuron_memory_bug004_n_neurons_real_zero_tb.v` TEST 4,
  riscritto per asserire `done` entro il baseline a piena larghezza (`cyc_full`, stabilito
  dinamicamente da TEST 3). Verificato: `n_neurons_real=0` completa in **32 cicli** contro
  **155** per il build completo a 3 neuroni (X viene ancora letto una volta, condiviso tra
  neuroni, ma nessun calcolo per-neurone viene eseguito) — TUTTI I TEST PASSED.
- **Stato**: **RISOLTO, verificato** (stessa nota di onestà di BUG-003: il meccanismo esatto
  del comportamento PRE-fix — 114 vs 196 cicli a seconda di `N_NEURONS` — non è stato isolato
  bit-per-bit, ma il nuovo percorso è deterministico e verificato indipendentemente).

### BUG-005 (CRITICA, CONFERMATO) — `RUN_NETWORK(0)` esegue 256 layer fasulli leggendo dati arbitrari come descrittori

- **Sintomo**: `rtl/layer_sequencer.v` documenta `run_num_layers` come "1..N_LAYERS" ma
  **non esiste alcun guard**, né a tempo di elaborazione né a runtime, che lo imponga.
  `layer_idx` (riga 121) è un registro a 8 bit PIENO (non ristretto come il
  `group_index` a 1 bit di BUG-002) — per `run_num_layers=0`, la condizione di
  terminazione `layer_idx == num_layers_reg-1` (riga 303) avvolge a `layer_idx==255`, un
  valore che il contatore RAGGIUNGE naturalmente contando da 0. Risultato confermato
  empiricamente: **`RUN_NETWORK(0)` non si blocca — esegue tutti e 256 gli indici di
  layer possibili** (21761 cicli in simulazione) prima di terminare, ciascuno leggendo 11
  byte di "descrittore" da `table_base + layer_idx×11` — ben oltre la vera tabella
  descrittori (dimensionata per il build reale, tipicamente poche decine di byte) — e
  interpretando dati PSRAM arbitrari (pesi, altri dati di rete, o memoria non
  inizializzata) come indirizzi/parametri di layer validi, eseguendo run reali di
  `neuron_memory` con quei parametri e **scrivendo i risultati nei buffer ping-pong a
  indirizzi derivati da quei dati arbitrari**.
- **Causa radice**: nessun guard su `run_num_layers`, né a tempo di elaborazione (come
  invece esiste per `N_INPUTS%PARALLEL` in `neuron_parallel.v`) né a runtime (come invece
  esiste, sia pure incompleto, per `n_inputs_real`/`n_neurons_real`, BUG-003/004).
- **Evidenza**: `sim/layer_sequencer_bug005_zero_layers_tb.v` — `iverilog -g2012 -o /tmp/ls0.out rtl/layer_sequencer.v sim/layer_sequencer_bug005_zero_layers_tb.v && vvp /tmp/ls0.out` →
  `dut.layer_idx` termina a 255, non a 0.
- **Impatto pratico**: **più severo di BUG-002/003/004** — raggiungibile con un singolo
  opcode SPI documentato (`RUN_NETWORK`, `num_layers=0`) senza bisogno di ricompilare il
  bitstream né di impostare un valore "runtime" degenere in un percorso secondario; il
  rischio non è solo un risultato sbagliato o un hang, ma **scritture reali in PSRAM a
  indirizzi non controllati**, derivati da dati che non erano mai stati pensati per essere
  interpretati come indirizzi.
- **Fix applicato** (`rtl/layer_sequencer.v`, `ST_IDLE`): `run_num_layers==0` è ora un
  no-op esplicito e immediato — `seq_done` pulsa senza mai entrare in `ST_READ_DESC`,
  stessa convenzione già usata da `spi_engine.v` per `WRITE_RAM`/`READ_RAM` con `len==0`
  (accetta il comando, non fa nulla, nessun errore riportato).
- **Test di regressione**: `sim/layer_sequencer_bug005_zero_layers_tb.v`, riscritto da
  osservazione ad asserzione hard (seq_done entro 5 cicli, `layer_idx===0`). Verificato:
  `run_num_layers=0` completa in **1 ciclo** con `layer_idx` rimasto a 0 (era 21761 cicli,
  `layer_idx` terminato a 255, prima del fix) — PASS.
- **Stato**: **RISOLTO, verificato.**

### BUG-006 (BASSA, stessa causa radice di BUG-005, protezione incidentale) — `num_neurons_graph=0` in `graph_engine.v`

- **Sintomo/causa radice**: identica struttura a BUG-005 — `neuron_idx`
  (`rtl/graph_engine.v:159`) è un registro a 16 bit pieni, `num_neurons_graph=0` fa
  avvolgere la condizione di terminazione a un valore (65535) che il contatore raggiunge
  naturalmente. Nessun guard esplicito su `num_neurons_graph`.
- **Differenza da BUG-005**: `graph_engine` ha già un guard runtime per-edge
  (`src_id>=out_id`/`out_id>=N_TOTAL` → `err`) che, **come effetto collaterale non
  progettato per questo scopo**, cattura la maggior parte dei pattern di dati spazzatura
  molto rapidamente — verificato con un pattern non banale: `err` a 58 cicli, non 65536.
  `layer_sequencer.v` non ha alcuna protezione equivalente.
- **Evidenza**: `sim/graph_engine_bug006_zero_neurons_probe_tb.v` — finestra di 5000 cicli,
  non fatto girare a completamento (limite dichiarato, vedi
  `docs/validation/06-graph-engine.md` §6.2).
- **Impatto pratico**: basso ma non nullo — la protezione PRE-fix era incidentale, non
  garantita per ogni possibile contenuto PSRAM. Il buco strutturale era reale.
- **Fix applicato** (`rtl/graph_engine.v`, `ST_COPY_IN_WAIT`, alla transizione di fine copia
  input): `num_neurons_graph==0` è ora un no-op esplicito e immediato — `done` pulsa subito
  dopo il completamento della copia input, senza mai entrare in `ST_DESC_RD`/il loop
  descrittori, stessa convenzione del fix BUG-005.
- **Test di regressione**: `sim/graph_engine_bug006_zero_neurons_probe_tb.v`, riscritto da
  osservazione a asserzione hard (`done` entro 30 cicli, nessun `err`, `neuron_idx===0`).
  Verificato: `num_neurons_graph=0` completa in **13 cicli** senza `err`, `neuron_idx` rimasto
  a 0 (era 58 cicli tramite l'intercettazione incidentale del guard src_id/out_id, prima del
  fix) — PASS.
- **Stato**: **RISOLTO, verificato.**

### BUG-007 (CRITICA, CONFERMATO end-to-end via SPI reale) — `SET_NET_TYPE` durante un `RUN_NETWORK` in corso blocca permanentemente il motore in esecuzione

- **Sintomo**: `rtl/spi_engine.v`, stato `ST_SET_NET_TYPE`, accetta
  `net_type <= rx_byte` **incondizionatamente** su qualunque `rx_valid`, senza alcun
  controllo su `graph_busy`/`seq_busy`. `rtl/spi_neuron_top.v` (righe 394-397) instrada la
  Porta C dell'arbitro tra `graph_engine` e `layer_sequencer` in modo **puramente
  combinazionale** sul valore CORRENTE di `net_type` — non agganciato a quale motore ha
  effettivamente avviato il run in corso. Il commento alla riga 390 dichiara i due motori
  "mutually exclusive by construction", ma quella costruzione impedisce solo che **entrambi
  vengano avviati insieme** — non dice nulla su una scrittura di `net_type` che arriva a
  metà di un run già avviato.
- **Confermato end-to-end su SPI reale** (non solo per ispezione): avviato un
  `RUN_NETWORK` in modalità grafo (lo stesso grafo valido già certificato in
  `spi_neuron_top_graph_tb.v`), poi immediatamente — prima che completi — inviato
  `SET_NET_TYPE(dense)` via SPI. Risultato: **`STATUS.busy` resta bloccato a 1 per 400+
  letture consecutive, ~2.35ms di tempo simulato** (contro i ~12-25µs normali per quel
  grafo) — un hang permanente, non un rallentamento. Le transazioni SPI stesse (incl. il
  `SET_NET_TYPE` avversariale) completano regolarmente; è specificamente il motore grafo
  a restare bloccato in attesa di un `ram_ready` che non arriverà mai più tramite il
  percorso ormai scollegato dal mux.
- **Evidenza**: `sim/spi_neuron_top_bug007_mid_run_net_type_tb.v` — riproduce l'hang in
  modo deterministico e ripetibile su SPI reale (non solo un accesso interno).
- **Impatto pratico**: **il più severo finora insieme a BUG-005** — raggiungibile con due
  soli opcode SPI documentati emessi in sequenza ravvicinata (`RUN_NETWORK` seguito da
  `SET_NET_TYPE` prima del completamento), uno scenario host plausibile (es. un host che
  prepara la configurazione per il prossimo run senza attendere la fine del precedente,
  o una race a livello applicativo tra due richieste). Blocca l'inferenza in corso finché
  l'host non se ne accorge (nessun timeout hardware, nessun errore riportato — solo
  `STATUS.busy` che non si abbassa mai).
- **Recupero verificato**: un `RESET` inviato durante l'hang **riporta il sistema a uno
  stato pienamente funzionante** — verificato con una successiva operazione dense legittima
  completata normalmente (2 cicli di polling, esito corretto). **Non è un blocco
  permanente**, ma un host che si limita a fare polling di `STATUS` senza un timeout e un
  `RESET` di ripiego resterebbe bloccato indefinitamente comunque, dato che l'hardware non
  segnala mai da solo che qualcosa è andato storto.
- **Fix applicato** (`rtl/spi_engine.v`, `ST_SET_NET_TYPE`): `net_type <= rx_byte` ora
  condizionato a `if (!graph_busy && !seq_busy)` — la scrittura viene silenziosamente
  rifiutata (comando accettato via SPI come prima, ma senza effetto) mentre un run è in
  corso, invece di rimappare il mux dell'arbitro a metà esecuzione.
- **Test di regressione**: `sim/spi_neuron_top_bug007_mid_run_net_type_tb.v`, riscritto per
  asserire end-to-end su SPI reale sia (a) che il run in corso completi normalmente
  nonostante lo `SET_NET_TYPE` avversariale a metà esecuzione, sia (b) che la scrittura sia
  stata VERAMENTE rifiutata e non parzialmente applicata (una successiva `RUN_NETWORK` senza
  re-inviare `SET_NET_TYPE(graph)` completa comunque correttamente). Verificato: il run grafo
  completa con `out_base[0]=126` dopo 1 solo polling nonostante lo `SET_NET_TYPE(dense)`
  avversariale; `net_type` confermato ancora `GRAPH` internamente — PASS su entrambi i
  controlli.
- **Stato**: **RISOLTO, verificato end-to-end su SPI reale.**

---

## Verifica post-fix su entrambi i piani (§A.4)

Dopo l'applicazione di tutti e 7 i fix (RTL: `rtl/neuron_parallel.v`, `rtl/neuron_memory.v`,
`rtl/layer_sequencer.v`, `rtl/graph_engine.v`, `rtl/spi_engine.v`; rimozione:
`sim/top.v`):

- **Regressione Icarus completa** (`python3 tools/run_regression.py`): 44 testbench, **43
  PASS**, 0 FAIL/ERROR, 1 BENCHMARK (nessun verdetto per progetto, invariato). Nessuna
  regressione sui 37 test già certificati pre-fix.
- **Sintesi reale** (`yosys synth_ecp5`, sistema completo `spi_neuron_top` con sottosistema
  flash, PARALLEL=8, stessi file/comando già validati in Fase 15/F7 di WORKLOG.md): **0
  problemi CHECK**, 1 warning atteso/preesistente (tri-state limitato in
  `psram_controller.v`, invariato). TRELLIS_FF: 4900 (era 4855 — +45, coerente con la nuova
  logica di guard/controllo introdotta dai fix, nessuna crescita anomala).
- **Place&route reale** (`nextpnr-ecp5 --45k --package CABGA381 --speed 8 --freq 80
  --lpf synth/ecp5/spi_neuron_top.lpf`): **0 errori di vincolo, 0 pin non vincolati,
  "Program finished normally"**. Fmax: **68.65 MHz** (era 67.91 MHz — leggermente meglio,
  entro il rumore di piazzamento già documentato in Fase 7/WORKLOG.md, non una regressione).
  Percorso critico verificato esplicitamente **strutturalmente identico** a prima del fix:
  `u_neuron_memory.u_neuron.group_index` → `u_mac8` → catena di riporto CCU2C
  dell'accumulatore (`rtl/mac8.v`) — nessun modulo toccato dai fix (che sono tutti
  aggiunte al percorso di controllo, non al datapath MAC/accumulatore) compare nel
  percorso critico. Margine sull'oscillatore reale 16MHz: 4.29× (invariato).
  Log: `synth/ecp5/post_fix_verify/yosys.log`, `synth/ecp5/post_fix_verify/nextpnr.log`.

---

## Non-bug (falsi positivi trovati e chiusi durante l'analisi)

Voci che sono sembrate anomalie a un primo controllo automatico ma si sono rivelate corrette
per progetto una volta letto il codice/intento — riportate per trasparenza sul processo, non
perché siano difetti.

- **`neuron_parallel_guard_negative_{degenerate,nonmultiple}_tb.v` "falliscono a compilare"**:
  comportamento corretto e intenzionale (test negativi, la mancata compilazione è il PASS).
  Vedi `docs/validation/00-inventario.md` §0.5.
- **`graph_engine_bandwidth_tb.v` "nessun verdetto PASS/FAIL"**: è un benchmark per
  progetto, non un test di correttezza. Vedi §0.3/§0.5 dell'inventario.
- **C.1 (falso "hang" iniziale, `neuron_parallel` config nota-buona)**: controllo tardivo e
  singolo di `done` (impulso di un solo ciclo) in uno script bespoke — non un problema
  dell'RTL. Vedi `docs/validation/01-datapath.md` §1.4.
- **C.2 (falso "hang" per `n_inputs_real=17`)**: stesso tipo di errore in un secondo script
  bespoke diverso da quello già provato — corretto riusando lo schema affidabile. Vedi
  `docs/validation/02-runtime-width.md` §2.2.
- **C.3 (falsi mismatch su 2048 controlli + un falso fallimento di round-trip)**: nel nuovo
  `sim/int8_memory_access_bytelane_tb.v`, un controllo dei segnali nello stesso passo di
  simulazione del loro aggiornamento non-bloccante (leggeva il valore dell'iterazione
  precedente), e uno stub di memoria comportamentale che ignorava le byte-lane
  `mem_lb_n`/`mem_ub_n` durante la scrittura. Entrambi difetti della testbench, non
  dell'RTL — vedi `docs/validation/03-memoria.md` §3.1.
- **C.4 (`mem_arbiter` mai concedeva nulla nella mia prima testbench)**: assegnazioni
  bloccanti per ritirare le richieste dei "perdenti" nello stesso fronte di clock che
  doveva concedere la richiesta — race reale con il blocco sincrono del DUT. Diagnosticato
  con `dut.owner` mai uscito da `SEL_NONE`. Corretto passando ad assegnazioni non bloccanti.
  Vedi `docs/validation/04-arbiter.md` §4.1.