micheleandClaude Sonnet 5
dc0b331d3e
Begins the V2 Neural Multiprocessor / Dataflow architecture per docs/v2-description.md, per explicit user request to freeze V1 and start V2 development, copying from V1 what's needed. Scaffold: - hardware/v1/: byte-exact, read-only copy of the current V1 codebase (rtl, testbenches, tools, constraints, a representative subset of synthesis results, and reference docs) -- verified identical via diff/cmp against the live top-level tree before being made filesystem-read-only. The live top-level tree is untouched and remains the project's "production" V1 (see hardware/v1/README.md and hardware/v2/logs/decisions.log DEC-0001 for why copy-not-move). - hardware/v2/: mandatory structure (rtl/sim/constraints/synthesis/ reports/scripts/logs/docs) plus the full logging system required by the spec (development/architecture/simulation/synthesis/timing/ benchmark/decisions/experiments/errors.log). M1 -- Neural Processor (hardware/v2/rtl/neural_processor.v): - 8-stage pipelined perceptron unit (P_IN=8): input align, 8 multipliers, 3-level adder tree, accumulator, bias+activation, INT8 saturation. Genuine 1-tile/cycle throughput, not just a wider combinational datapath. - 7-state FSM (NP_IDLE..NP_ERROR per docs/v2-description.md §6, with 4 baseline states merged into NP_WAIT_OPERANDS -- see decisions.log DEC-0002); valid/ready/data/last stream interfaces per §7. - Bit-exact vs the frozen hardware/v1/rtl/neuron_parallel.v + mac8.v + mac_unit.v: 7/7 tests pass (hardware/v2/sim/tb_neural_processor.v), covering regular/mixed-sign/extreme-INT8 vectors, both activations, a zero-idle-gap back-to-back-tiles throughput check, and an 8-tile job -- verified with Verilator (see below for why). - Real synthesis + place&route (Yosys + nextpnr-ecp5): 0 CHECK problems, Fmax 183.12 MHz at ACC_WIDTH=32 (PASS at 80MHz, ~3x V1's isolated PARALLEL=8 Fmax of 61.71 MHz) and 176.21 MHz at ACC_WIDTH=24 (a user-requested comparison experiment, also bit-exact-verified; see experiments.log EXP-0001/EXP-0002 and benchmark.log). Three real bugs found and resolved during M1 development (full diagnostic record in errors.log): - Two independent, reproducible Icarus Verilog v13.0 scheduling defects (ERR-0001, ERR-0002) that silently produced wrong simulation results for standard sequential Verilog -- confirmed via Verilator 5.050 giving correct results on the same minimal repros. Verilator is now the trusted simulator for hardware/v2/ (decisions.log DEC-0004); Icarus's affected protocol-violation check was removed from the RTL and deferred architecturally to the Neural Director (DEC-0003) rather than chased further. - One real RTL bug (ERR-0003): last0 wasn't gated like valid0, letting a "last tile" tag leak into the pipeline ahead of its actual valid tile on back-to-back jobs. Fixed and verified. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013xXuuRUWZScuo1DeYJxs3v
68 lines
3.4 KiB
Markdown
68 lines
3.4 KiB
Markdown
# 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) |
|