micheleandClaude Sonnet 5
20b0b1f4c0
mac_unit.v: exhaustive unit test (all 65536 (x,w) combinations at DATA_WIDTH=8, plus 486 boundary acc_in vectors) against an independent Python oracle (tools/validation/mac_oracle.py). 66022/66022 match, 0 reserves. mac8.v: first-ever dedicated unit test (previously only indirect coverage at whatever single PARALLEL neuron_parallel_tb.v happens to use). Verified at PARALLEL=2/8/32 with structural adversarial vectors (catches swapped/duplicated tree wiring), 300 random INT8 pairs per PARALLEL with realistic accumulating acc_in, and worst-case magnitude adversarial vectors. 939/939 match. Confirms BUG-002 (N_INPUTS=0 bypasses the N_INPUTS%PARALLEL elaboration guard) is real, on both simulation and real Yosys synthesis -- root cause: [DATA_WIDTH*N_INPUTS-1:0] becomes [-1:0] for N_INPUTS=0, which both tools treat as a genuine 2-bit undriven vector rather than collapsing to zero width. Includes a documented self-correction: the first verification attempt produced a false "hang" using an invalid one-shot late check of a single-cycle done pulse -- caught by reproducing the same false result on a known-good sanity config before trusting it. Full regression re-run clean after adding 3 new testbenches: 36/36 real tests pass. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013xXuuRUWZScuo1DeYJxs3v
4.7 KiB
4.7 KiB
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
BUG-001 (INFO, non ancora classificato) — sim/top.v non compila contro l'RTL corrente
- Sintomo:
iverilogfallisce conparameter 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, vedidocs/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) — è dead code, non un difetto funzionale del design.
- Stato: aperto, non corretto per policy §E (analisi separata dalla correzione). Azione proposta: rimuovere il file o aggiornarlo, decisione da confermare con l'utente.
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): conneuron_parallel #(.N_INPUTS(0), .PARALLEL(P)), il guard elaboration-time (rtl/neuron_parallel.v:71,if (N_INPUTS % PARALLEL != 0)) non scatta (0 % P == 0per ogniP), il modulo elabora con successo (sia in simulazione Icarus sia in sintesi reale Yosys, 0 problemi CHECK). A runtime:startviene accettato mabusynon si alza mai edonenon 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_bussono dichiarati[DATA_WIDTH*N_INPUTS-1:0], che perN_INPUTS=0diventa[-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 conN_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 proposto (non applicato — analisi separata dalla correzione, §E del prompt di
certificazione): estendere il guard a
if (N_INPUTS == 0 || N_INPUTS % PARALLEL != 0). - Stato: APERTO, confermato, non corretto.
Risolti
(nessuno ancora in questa campagna — la Fase 0 è analisi/inventario, non correzione)
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). Vedidocs/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.