feat(v2): scaffold hardware/v1 frozen baseline + M1 Neural Processor

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

hardware/v1/docs/validation/05-layer-sequencer.md

@@ -0,0 +1,75 @@
+# C.5 — Sequencer dense (`layer_sequencer.v`)
+
+Data: 2026-09-04.
+
+---
+
+## 5.1 Catena layer, ping-pong, busy/done — CERTIFICATO (test pre-esistente, valido)
+
+`sim/layer_sequencer_tb.v` (pre-esistente, riverificato in Fase 0) copre un run a 2 layer
+con verifica campo-per-campo del descrittore decodificato (`nm_w_base`, `nm_bias_addr`,
+`nm_x_base`, `nm_activation`, `nm_n_inputs`, `nm_n_neurons`), e in modo particolarmente
+solido: **verifica l'indirizzo del buffer ping-pong usato per layer 1, non solo il valore**
+(conferma che layer 1 legge dal buffer che layer 0 ha effettivamente scritto — il punto
+reale dello schema ping-pong, non solo che "un" buffer sia stato usato). Verifica anche che
+`seq_busy` resti asserto per l'intero run a 2 layer (non cada tra un layer e l'altro) e che
+`seq_done` pulsi esattamente una volta, dopo l'ULTIMO layer (un `nm_done` intermedio non deve
+attivarlo).
+
+**Verdetto: CERTIFICATO** per la catena a `run_num_layers` valido (test singolo ma
+sufficientemente rigoroso nel verificare indirizzi, non solo valori).
+
+---
+
+## 5.2 `run_num_layers=0` — BUG-005 CONFERMATO, CRITICO
+
+**Ipotesi**, per analogia col guard mancante già visto in BUG-002/003/004: `run_num_layers`
+è documentato "1..N_LAYERS" ma **non ha alcun guard**, né a compile-time né a runtime.
+`layer_idx` (`rtl/layer_sequencer.v:121`) è però un registro a **8 bit pieni** (non ristretto
+a 1 bit come il `group_index` di BUG-002) — la condizione di terminazione
+`layer_idx==num_layers_reg-1` per `num_layers_reg=0` avvolge a `layer_idx==255`, un valore
+che il contatore RAGGIUNGE naturalmente contando da 0. Ipotesi: non un hang, ma
+un'esecuzione di 256 layer fasulli.
+
+**Verificato empiricamente** (`sim/layer_sequencer_bug005_zero_layers_tb.v`, `neuron_memory`
+sostituito da uno stub minimale che completa istantaneamente, per isolare il solo
+comportamento di sequenziamento):
+
+```
+RESULT: run_num_layers=0 completed after 21761 cycles -- dut.layer_idx ended at 255
+```
+
+**Confermata l'ipotesi**: non un hang. Il sequencer esegue **tutti e 256 gli indici di
+layer possibili**, ciascuno leggendo 11 byte di "descrittore" da
+`table_base + layer_idx×11` — ben oltre la vera tabella (dimensionata sul build reale,
+tipicamente poche decine di byte) — 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
+ad indirizzi derivati da quei dati arbitrari** — non solo un risultato sbagliato, una
+possibile corruzione reale di aree PSRAM non correlate.
+
+**Perché è 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 passare per un valore "runtime" degenere su un percorso secondario — e il rischio non si
+ferma a un risultato sbagliato o a un hang, ma include scritture reali in PSRAM a indirizzi
+non controllati.
+
+**Nota correlata (non testata separatamente, stesso meccanismo)**: `run_num_layers` >
+`N_LAYERS` (il massimo di build) presumibilmente ha lo stesso problema in forma più
+limitata — nessun guard impedisce di leggere oltre la tabella reale anche per valori
+"quasi validi" ma superiori al massimo di build. Non verificato con un test dedicato in
+questa fase (stessa causa radice di §5.2, non una scoperta separata).
+
+**Verdetto: NON CERTIFICATO per `run_num_layers=0` (e probabilmente per valori
+`>N_LAYERS`).** Vedi `docs/validation/bugs.md` BUG-005 (severità CRITICA — unico bug di
+questa campagna finora classificato come tale, per raggiungibilità diretta via protocollo
+host documentato e rischio di corruzione dati reale, non solo hang o risultato sbagliato).
+
+---
+
+## 5.3 Verdetto complessivo C.5
+
+| Sotto-aspetto | Verdetto |
+|---|---|
+| Catena layer, ping-pong, busy/done (valori validi) | **CERTIFICATO** |
+| `run_num_layers=0` | **NON CERTIFICATO** — BUG-005 (CRITICO, causa isolata con certezza) |