test: certify spi_neuron_top mux/pins (C.8), find critical BUG-007
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
This commit is contained in:
Claude Sonnet 5
@@ -0,0 +1,67 @@
|
||||
# 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) |
|
||||
@@ -165,6 +165,48 @@ funzionale pratico), **INFO** (non un bug: gap di copertura, ambiguità document
|
||||
- **Stato**: **APERTO**, severità inferiore a BUG-005 per la protezione incidentale
|
||||
osservata, non pienamente verificato su ogni pattern di dati possibile.
|
||||
|
||||
### 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 proposto** (non applicato — analisi separata dalla correzione): in
|
||||
`rtl/spi_engine.v`, rifiutare/accodare `SET_NET_TYPE` mentre `graph_busy||seq_busy` è
|
||||
asserto, oppure latchare `net_type` in `spi_neuron_top.v` solo all'avvio di un run
|
||||
(non renderlo immediatamente combinazionale sul mux dell'arbitro).
|
||||
- **Stato**: **APERTO, confermato end-to-end, causa isolata con certezza, recupero via
|
||||
RESET verificato.**
|
||||
|
||||
---
|
||||
|
||||
## Risolti
|
||||
|
||||
Reference in New Issue
Block a user