micheleandClaude Sonnet 5
f0a66363de
Legitimate dispatch mux and data_ready_n/irq_n pins certified via existing pre-session tests. BUG-007 (CRITICAL), confirmed end-to-end over real simulated SPI: SET_NET_TYPE has no check against graph_busy/seq_busy in rtl/spi_engine.v, and rtl/spi_neuron_top.v's arbiter Port C mux selects between graph_engine/layer_sequencer purely combinationally on the current net_type value -- not latched to whichever engine actually started the in-flight run. Started a valid graph RUN_NETWORK, sent SET_NET_TYPE(dense) immediately after (before completion): STATUS.busy gets stuck (30+ consecutive polls with no done/err, vs. ~12-25us normal completion) -- the graph engine is left waiting for a ram_ready that never arrives via the now-disconnected mux path. Also verified recovery: RESET during the hang brings the system back to a fully working state (a subsequent legitimate dense op completes normally) -- not a permanent lockup, but plain STATUS polling alone would never unstick without a host-side RESET fallback. Full regression: 40/40 real tests pass, 1 new observational test deterministically reproduces BUG-007 and verifies RESET recovery. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013xXuuRUWZScuo1DeYJxs3v
3.4 KiB
C.8 — Top-level (spi_neuron_top.v)
Data: 2026-09-04.
8.1 Mux seq_busy/dispatch legittimo, pin data_ready_n/irq_n — CERTIFICATO
Il meccanismo di mux mux_nm_* (che decide se neuron_memory è pilotato da
layer_sequencer durante un RUN_NETWORK o direttamente da spi_engine per un START
manuale) è già coperto da sim/spi_neuron_top_runnetwork_tb.v (un START a singolo layer
funziona ancora correttamente dopo un RUN_NETWORK precedente — "mux sanity"). I pin
data_ready_n/irq_n sono coperti da 4 test dedicati in sim/spi_neuron_top_irq_tb.v
(idle, run valido, run non valido, RESET pulisce irq_n). Entrambi pre-esistenti,
riverificati PASS in Fase 0.
Verdetto: CERTIFICATO per questi aspetti.
8.2 SET_NET_TYPE durante un run in corso — BUG-007 CONFERMATO END-TO-END, CRITICO
Analisi strutturale: il mux della Porta C dell'arbitro (righe 394-397) sceglie tra
graph_engine e layer_sequencer in modo puramente combinazionale sul valore corrente
di net_type. rtl/spi_engine.v accetta SET_NET_TYPE incondizionatamente, senza
alcun controllo su graph_busy/seq_busy. Il commento "mutually exclusive by
construction" (riga 390) copre solo l'AVVIO simultaneo dei due motori, non una scrittura
di net_type che arriva a metà di un run già avviato.
Verificato end-to-end su SPI reale (sim/spi_neuron_top_bug007_mid_run_net_type_tb.v,
stesso grafo valido già certificato in spi_neuron_top_graph_tb.v, stesse routine SPI
provate):
--- starting graph RUN_NETWORK, then immediately SET_NET_TYPE(dense) before it completes ---
after 30 polls: last_status=0x01 (bit0=busy) -- expected 0x01 stuck if the hang reproduces
RESULT: HANG CONFIRMED -- STATUS.busy stuck, no done/err after 30 polls (vs. ~12-25us normal completion time for this graph)
--- recovery check: RESET, then a legitimate legacy dense START ---
RECOVERY RESULT: RESET DOES recover the system -- a subsequent legitimate dense op completed normally (status=0x02 after 2 polls)
STATUS.busy resta bloccato dopo un SET_NET_TYPE inviato subito dopo un RUN_NETWORK in
modalità grafo, per un tempo enormemente superiore al normale completamento di quel grafo
(~2.35ms osservati in un run più lungo, vs ~12-25µs normali) — un hang reale, non un
rallentamento. Le transazioni SPI stesse continuano a funzionare (il SET_NET_TYPE
avversariale e i successivi poll di STATUS completano regolarmente); è specificamente il
motore grafo a restare bloccato, in attesa di un ram_ready che non arriva più tramite il
percorso del mux ormai scollegato.
Recupero verificato: un RESET durante l'hang riporta il sistema a uno stato
pienamente funzionante (una successiva operazione dense legittima completa normalmente).
Non è un blocco permanente — ma senza un RESET di ripiego lato host, il polling da solo
non si sbloccherebbe mai.
Verdetto: NON CERTIFICATO. Vedi docs/validation/bugs.md BUG-007 — severità CRITICA
insieme a BUG-005, per raggiungibilità diretta con due soli opcode SPI documentati in
sequenza ravvicinata, uno scenario host plausibile.
8.3 Verdetto complessivo C.8
| Sotto-aspetto | Verdetto |
|---|---|
Mux seq_busy per dispatch legittimo |
CERTIFICATO |
Pin data_ready_n/irq_n |
CERTIFICATO |
SET_NET_TYPE durante un run in corso |
NON CERTIFICATO — BUG-007 (CRITICO, confermato end-to-end, recupero via RESET verificato) |