FPGA-Neural/hardware/v1/docs/FPGA-Neural-Datapatch-Benchmark.md

# FPGA-Neural — Analisi datapath e benchmark ECP5

## 1. Obiettivo

Questa fase del progetto FPGA-Neural ha avuto lo scopo di verificare il comportamento sintetizzabile e le prestazioni del core neurale parametrico sul dispositivo:

**Lattice LFE5U-45F-8BG381C**

Configurazione FPGA:

- ECP5-45F
- Speed grade: `-8`
- Package: `CABGA381`
- 72 blocchi `MULT18X18D`
- circa 43.8k LUT/FF equivalenti

La configurazione funzionale utilizzata nei benchmark è:

```text
DATA_WIDTH  = 8 bit
ACC_WIDTH   = 32 bit
N_INPUTS    = 256
N_NEURONS   = 4
PARALLEL    = variabile

Il datapath implementa:

INT8 × INT8
      ↓
   INT16
      ↓
sign extension
      ↓
   INT32
      ↓
accumulation
      ↓
   + bias
      ↓
    ReLU
      ↓
INT8 saturation

Lo scopo principale del benchmark è stato determinare il compromesso tra:

numero di MAC paralleli;
utilizzo dei DSP;
complessità del datapath;
routing;
frequenza massima;
latenza di elaborazione.
2. Architettura RTL

L'attuale datapath è organizzato gerarchicamente:

                    layer
                      │
             ┌────────┴────────┐
             │                 │
          neuron 0           neuron N
             │                 │
             ▼                 ▼
       neuron_parallel   neuron_parallel
             │                 │
             ▼                 ▼
           mac8              mac8
             │                 │
       MAC × PARALLEL    MAC × PARALLEL

Ogni neurone elabora N_INPUTS ingressi a gruppi di PARALLEL.

Con:

N_INPUTS = 256

il numero di gruppi è:

GROUPS = 256 / PARALLEL

Pertanto:

PARALLEL	Gruppi per neurone
16	16
8	32
4	64
2	128

I quattro neuroni vengono elaborati contemporaneamente.

3. MAC unit

Il modulo mac_unit implementa un singolo prodotto-accumulatore.

Per la configurazione INT8:

x : signed INT8
w : signed INT8

Il prodotto è:

INT8 × INT8 = INT16

Il risultato viene quindi esteso con segno a 32 bit:

INT16 → INT32

e sommato all'accumulatore.

L'operazione fondamentale è quindi:

acc_out = acc_in + (x × w)

L'implementazione è completamente parametrica rispetto a:

DATA_WIDTH
ACC_WIDTH
4. Balanced adder tree

Una modifica importante rispetto alla prima implementazione è stata la sostituzione dell'accumulatore combinazionale lineare con un balanced binary adder tree.

Una riduzione lineare avrebbe prodotto:

((((p0 + p1) + p2) + p3) + ...)

con profondità:

O(PARALLEL)

La nuova implementazione utilizza invece:

             sum
           /     \
        sum       sum
       /   \     /   \
      p0   p1   p2   p3

La profondità diventa:

O(log2(PARALLEL))

Per esempio:

PARALLEL = 8
→ 3 livelli

PARALLEL = 16
→ 4 livelli

PARALLEL = 32
→ 5 livelli

Questa modifica riduce significativamente la profondità combinazionale del datapath.

5. neuron_parallel

neuron_parallel esegue il calcolo di un singolo neurone.

Il funzionamento è:

start
  ↓
group 0
  ↓
group 1
  ↓
...
  ↓
group N
  ↓
+ bias
  ↓
ReLU
  ↓
saturation
  ↓
done

Durante ogni ciclo viene elaborato un gruppo di:

PARALLEL

prodotti.

L'accumulatore mantiene il risultato tra un gruppo e il successivo.

6. Test funzionale

Il testbench sim/parametric_tb.v utilizza:

DATA_WIDTH = 8
N_INPUTS   = 256
N_NEURONS  = 4
PARALLEL   = variabile
ACC_WIDTH  = 32

Sono stati definiti quattro casi di test.

N0 — accumulazione su più gruppi

Input:

x = 1

Pesi:

primi 32 = +1
restanti = 0

Risultato:

32 × 1 × 1 = 32

Output atteso:

32

Questo test verifica soprattutto la corretta gestione dell'accumulatore attraverso più gruppi.

N1 — bias

Pesi:

tutti = 0

Bias:

+10

Output atteso:

10
N2 — ReLU

Pesi:

tutti = -1

Input:

tutti = +1

Il risultato è negativo.

La ReLU produce:

0
N3 — saturazione

Pesi:

primi 32 = +4
restanti = 0

Input:

tutti = +1

Risultato:

32 × 4 = 128

L'uscita INT8 positiva viene saturata:

128 → 127
7. Risultato simulazione

Il test è passato con PARALLEL=16:

PARALLEL  = 16

PASS N0: 32
PASS N1: 10
PASS N2: 0 (ReLU)
PASS N3: 127 (saturation)

INT8 PARAMETRIC TEST PASSED

È passato anche con PARALLEL=32:

PARALLEL  = 32

PASS N0: 32
PASS N1: 10
PASS N2: 0 (ReLU)
PASS N3: 127 (saturation)

INT8 PARAMETRIC TEST PASSED

La correttezza funzionale del datapath parametrico è quindi confermata.

8. Sintesi e Place & Route

Dopo la simulazione il datapath è stato sintetizzato per ECP5 utilizzando:

Yosys

e successivamente piazzato e instradato con:

nextpnr-ecp5

Target:

LFE5U-45F
CABGA381
Speed grade -8

Il wrapper di benchmark genera internamente:

input;
pesi;
bias;
segnali di test.

In questo modo non vengono portati all'esterno i giganteschi bus del modello neurale.

Il top-level espone solamente:

clk
rst
start
y_bus
busy
done

Questa modifica è stata fondamentale.

Il primo tentativo esponeva infatti direttamente:

x_bus      ≈ 2048 bit
weights    ≈ 8192 bit
bias       ≈ 32 bit

portando a oltre 10.000 I/O fisiche richieste.

Il risultato era:

TRELLIS_IO: 10309/245

e quindi un errore di placement.

Il problema non era la dimensione logica del circuito, ma esclusivamente il numero di I/O.

9. PARALLEL = 16

Risorse sintetizzate:

LUT4 ≈ 2531
DFF  = 186

Risorse FPGA:

MULT18X18D = 64 / 72

quindi:

88% dei DSP

Timing:

Fmax ≈ 52.13 MHz
Tcrit ≈ 19.18 ns

Il percorso critico risultava fortemente influenzato dal routing.

Configurazione:

PARALLEL = 16
N_NEURONS = 4

produce:

16 × 4 = 64 MAC simultanei
10. PARALLEL = 8

Risorse:

MULT18X18D = 32 / 72

quindi:

32 DSP

Con quattro neuroni:

8 × 4 = 32 MAC simultanei

Timing:

Fmax ≈ 61.71 MHz
Tcrit ≈ 16.20 ns

Composizione del percorso critico:

logic   ≈ 6.43 ns
routing ≈ 9.77 ns
total   ≈ 16.20 ns

Questa configurazione è particolarmente importante perché corrisponde esattamente al target originale di:

32 MAC hardware simultanei
11. PARALLEL = 4

Risorse:

LUT4 = 804
DFF  = 194

MULT18X18D = 16 / 72

Quindi:

16 MAC simultanei

Timing:

Fmax ≈ 75.01 MHz
Tcrit ≈ 13.33 ns

Composizione:

logic   ≈ 6.67 ns
routing ≈ 6.66 ns
total   ≈ 13.33 ns

In questa configurazione logica e routing sono quasi perfettamente bilanciati.

12. PARALLEL = 2

Risorse:

LUT4 = 481
DFF  = 198

MULT18X18D = 8 / 72

Quindi:

8 MAC simultanei

Timing finale dopo routing:

Fmax ≈ 87.88 MHz
Tcrit ≈ 11.38 ns

Composizione:

logic   ≈ 6.43 ns
routing ≈ 4.95 ns
total   ≈ 11.38 ns

Il design è stato quindi verificato con target:

80 MHz

ottenendo:

87.88 MHz

e:

PASS

Il margine teorico rispetto a 80 MHz è:

T80MHz = 12.50 ns

12.50 - 11.38 ≈ 1.12 ns
13. Tabella comparativa
PARALLEL	MAC/neurone	Neuroni	MAC totali	DSP	Fmax	Tcrit	80 MHz
16	16	4	64	64	52.13 MHz	19.18 ns	FAIL
8	8	4	32	32	61.71 MHz	16.20 ns	FAIL
4	4	4	16	16	75.01 MHz	13.33 ns	FAIL
2	2	4	8	8	87.88 MHz	11.38 ns	PASS
14. Interpretazione

I risultati mostrano chiaramente il trade-off fondamentale.

Riducendo PARALLEL:

PARALLEL ↓
    ↓
MAC simultanei ↓
    ↓
DSP ↓
    ↓
adder tree ↓
    ↓
routing/congestione ↓
    ↓
Fmax ↑

ma contemporaneamente:

PARALLEL ↓
    ↓
numero gruppi ↑
    ↓
cicli necessari ↑
    ↓
latenza ↑

Quindi la frequenza massima non è sufficiente per scegliere la configurazione.

Occorre considerare il throughput complessivo:

throughput ≈ MAC_per_cycle × clock_frequency

A parità di quattro neuroni:

P2
8 MAC × 87.88 MHz
≈ 703 M MAC/s
P4
16 MAC × 75.01 MHz
≈ 1.20 G MAC/s
P8
32 MAC × 61.71 MHz
≈ 1.97 G MAC/s
P16
64 MAC × 52.13 MHz
≈ 3.34 G MAC/s

Questi valori sono una misura teorica del throughput del datapath MAC, non ancora del throughput end-to-end della rete, perché non includono i limiti della memoria esterna, del trasferimento dei pesi e del controller.

15. Scelta architetturale

Il risultato più importante del benchmark è che PARALLEL=8 rimane il candidato naturale per l'architettura V1 se l'obiettivo iniziale di progetto è mantenere circa:

32 MAC simultanei

Infatti:

PARALLEL = 8
N_NEURONS = 4

→ 32 MAC
→ 32 DSP / 72
→ 61.71 MHz

L'utilizzo DSP è ancora relativamente basso:

44% circa

lasciando risorse per:

controller memoria;
buffer;
interfaccia SPI;
DMA;
gestione layer;
eventuali pipeline;
future funzioni di controllo.

PARALLEL=2 è invece la configurazione più semplice da temporizzare tra quelle testate:

87.88 MHz

e passa il target di 80 MHz.

Tuttavia richiede:

128 gruppi

per elaborare un neurone da 256 ingressi.

Per questo motivo non è opportuno adottarlo automaticamente come configurazione definitiva solo perché raggiunge la frequenza più elevata.

16. Timing a 100 MHz

Il target di:

100 MHz

non viene attualmente raggiunto.

Il miglior risultato è:

87.88 MHz

con PARALLEL=2.

Il percorso critico è ancora:

weight FF
    ↓
MULT18X18D
    ↓
products
    ↓
adder/carry chain
    ↓
acc_next
    ↓
ReLU / saturation
    ↓
output FF

Il problema non è quindi un'elevata occupazione delle risorse FPGA.

Al contrario, con P2 l'FPGA è utilizzato molto poco:

DSP ≈ 11%
LUT ≈ 1%
FF  ≈ 0%

Il limite è principalmente temporale e dipende dal datapath combinazionale.

Per superare 100 MHz sarà probabilmente necessario introdurre una o più pipeline interne.

Questa ottimizzazione non è però ancora necessaria per procedere con la prossima fase architetturale.

17. Vincoli LPF

Durante questi benchmark il file:

synth/ecp5/top.lpf

è stato lasciato senza vincoli di pin.

nextpnr viene eseguito con:

--lpf-allow-unconstrained

Pertanto i numerosi warning relativi a I/O non vincolate sono intenzionali.

Il benchmark verifica quindi:

sintesi
placement
routing
timing

e non:

pin assignment
I/O standard della scheda
signal integrity

I vincoli LPF reali verranno aggiunti quando sarà definito il pinout della scheda FPGA-Neural.

18. Decisione per la prossima fase

Non è utile proseguire con benchmark PARALLEL=1.

Il punto di interesse architetturale è già stato individuato.

La prossima fase deve spostare il progetto dal benchmark sintetico verso l'architettura reale:

                    HOST
                      │
                      │ SPI
                      ▼
              FPGA interface
                      │
                      ▼
               Memory interface
                      │
          ┌───────────┴───────────┐
          ▼                       ▼
      PSRAM 8 MB               FPGA BRAM
          │                       │
          └──────────┬────────────┘
                     ▼
                tile/buffer
                     │
                     ▼
                 MAC engine
                     │
                     ▼
                accumulator
                     │
                     ▼
                 activation
                     │
                     ▼
                  output

Il core layer e neuron_parallel dovrà quindi essere separato dalla memoria fisica attraverso una Memory Interface.

19. Memoria V1

La memoria di lavoro prevista è:

ISSI IS66WVE4M16EBLL-70BLI

Caratteristiche:

64 Mbit
8 MB
4M × 16
parallel PSRAM
asynchronous/page mode
70 ns
2.7–3.6 V
48-TFBGA
6 × 8 mm

La memoria volatile sarà utilizzata come working memory durante l'inferenza.

La memoria persistente prevista è:

Winbond W25Q128JVS

con:

128 Mbit
16 MB
SPI NOR Flash

La divisione dei ruoli è:

W25Q128JVS
    ↓
persistent storage
    ↓
weights
biases
network metadata
FPGA/network configuration

e:

IS66WVE4M16EBLL
    ↓
runtime working memory
    ↓
input/output tensors
intermediate data
weight tiles

Infine:

FPGA BRAM
    ↓
local working buffers
tiles
accumulators
20. Conclusioni

La fase di caratterizzazione del datapath ha prodotto i seguenti risultati:

Il datapath INT8/INT32 è funzionalmente corretto.
Il test parametrico è passato.
Il balanced adder tree ha sostituito con successo la precedente riduzione lineare.
Il design è sintetizzabile per LFE5U-45F.
Il placement e routing sono stati completati correttamente.
Il problema iniziale delle migliaia di I/O è stato eliminato spostando i test vector all'interno del wrapper.
PARALLEL=8 implementa esattamente 32 MAC simultanei con quattro neuroni.
PARALLEL=2 raggiunge 87.88 MHz e supera il target di 80 MHz.
Il limite attuale a 100 MHz è dovuto al percorso combinazionale, non alla saturazione delle risorse FPGA.
Non è necessario continuare il benchmark verso PARALLEL=1.

La baseline architetturale rimane quindi:

LFE5U-45F-8BG381C
INT8 / INT32
256 inputs
4 neurons
PARALLEL parametrico

con:

PARALLEL = 8

come candidato principale per la configurazione orientata al throughput e:

PARALLEL = 2

come riferimento per la configurazione orientata alla frequenza.

La prossima attività significativa è l'integrazione della Memory Interface con la PSRAM esterna, mantenendo PARALLEL come parametro del motore computazionale.

Appendice A — Toolchain
Yosys

Yosys è il tool di sintesi RTL.

Flusso:

Verilog RTL
    ↓
elaborazione
    ↓
ottimizzazione
    ↓
mapping ECP5
    ↓
JSON netlist

Versione utilizzata:

Yosys 0.68+post

Binary:

/opt/homebrew/bin/yosys
Project Trellis

Project Trellis fornisce il database open-source dell'architettura ECP5 e gli strumenti necessari all'implementazione.

Tra gli strumenti disponibili:

ecppack
ecppll
ecpbram
ecpunpack

Installazione utilizzata:

/tmp/prjtrellis/install
nextpnr-ecp5

nextpnr-ecp5 esegue:

placement
routing
timing analysis

Versione:

nextpnr-0.11.1-19-g8dbcee5

Binary:

/tmp/nextpnr/build/nextpnr-ecp5

Parametri principali:

--45k

seleziona LFE5U-45F.

--package CABGA381

seleziona il package.

--speed 8

seleziona speed grade -8.

--json

carica la netlist generata da Yosys.

--lpf

carica i vincoli di pin.

--lpf-allow-unconstrained

permette I/O non vincolate.

--freq 80

richiede un timing target di 80 MHz.

Icarus Verilog

Icarus Verilog viene utilizzato per la simulazione RTL.

Esempio:

iverilog -g2012 \
  -Ptb.PARALLEL=16 \
  -o sim/parametric_256x4_p16 \
  sim/parametric_tb.v \
  rtl/mac_unit.v \
  rtl/mac8.v \
  rtl/neuron_parallel.v \
  rtl/layer.v

Esecuzione:

vvp sim/parametric_256x4_p16

Icarus verifica principalmente la correttezza funzionale del RTL.

Appendice B — Differenza tra simulazione e implementazione
Simulazione
Icarus Verilog

verifica:

algebra signed;
prodotti;
accumulazione;
gruppi;
bias;
ReLU;
saturazione;
segnali busy e done.
Implementazione
Yosys
+
nextpnr-ecp5

verifica:

sintetizzabilità;
mapping FPGA;
LUT;
FF;
DSP;
placement;
routing;
timing;
Fmax.

Le due verifiche sono complementari.
 r
Appendice C — Stato attuale
RTL funzionale              PASS
Simulazione parametrica     PASS
Sintesi ECP5                PASS
Placement                   PASS
Routing                     PASS

PARALLEL=16                 52.13 MHz
PARALLEL=8                  61.71 MHz
PARALLEL=4                  75.01 MHz
PARALLEL=2                  87.88 MHz

Target 80 MHz, P2           PASS
Target 100 MHz              FAIL

Memory Interface            PASS (implementata, vedi Appendice D)
PSRAM controller            PASS (implementata, page mode incluso dal 2026-09-03, vedi Appendice D)
Host SPI interface          DA IMPLEMENTARE
Layer engine reale          PROSSIMA FASE

Appendice D — PSRAM page mode (2026-09-03)

Contesto: il chip di memoria previsto (ISSI IS66WVE4M16EBLL-70BLI,
§19) è "asynchronous/page mode", ma `rtl/psram_controller.v` fino a
questa data usava solo l'accesso asincrono a parola singola — ogni
transazione pagava sempre i 70ns pieni (`tAA`), il page mode non era
usato. Verificato leggendo il datasheet reale della famiglia
(IS66WVE1M16BLL, stesso layout di registro di configurazione/CR
della famiglia BLL — 4M×16 vs 1M×16 cambia solo la densità
dell'array, non la logica di page mode/CR): pagina di 16 word
(`A[3:0]`), `tAPA`/`tPC` = 20ns per accessi successivi nella stessa
pagina invece di `tAA` = 70ns, page mode disabilitato di default
all'accensione (serve un caricamento esplicito del registro di
configurazione).

Implementato in `rtl/psram_controller.v` (dettagli in WORKLOG.md,
sezione "PSRAM page mode"), interamente interno al controller —
nessuna modifica a `memory_interface.v`/`int8_memory_access.v`/
`mem_arbiter.v` o a chi li usa.

Banda del gather `graph_engine` (`sim/graph_engine_bandwidth_tb.v`,
stesso benchmark già citato in "Bitstream reale + banda del gather"),
misurata prima/dopo isolando i soli due file toccati con `git
stash`:

```text
                  PRIMA (no page mode)   DOPO (page mode)   Δ
cicli/edge        53.25                  37.53              -29.5%
edge/s  @80MHz     1 502 347              2 131 557          +41.9%
banda   @80MHz     6.01 MB/s              8.53 MB/s          +41.9%
edge/s  @16MHz*      300 469                426 311          +41.9%
banda   @16MHz*    1.20 MB/s              1.71 MB/s          +41.9%
```
\* oscillatore reale raccomandato, `docs/FPGA-Neural-Hardware-Design.md` §4.

Nota: il primo tentativo di implementazione (chiusura pagina anche
sul cambio di `LB#`/`UB#`) misurava **61.25 cicli/edge, peggio del
"prima"** — regressione reale, trovata proprio grazie a questo
benchmark prima di considerare il lavoro finito, poi corretta (vedi
WORKLOG.md per il dettaglio).

Impatto risorse ECP5 (Yosys `synth_ecp5`):

```text
                     PRIMA         DOPO          Δ
psram_controller.v (isolato)
  LUT4               63            290           +227
  TRELLIS_FF         83            141           +58
  CCU2C               7             12           +5

spi_neuron_top (sistema completo, Tipo #2, PARALLEL=2)
  LUT4              2367          2619           +252
  TRELLIS_FF        2406          2467           +61
  DP16KD               2             2            0
  MULT18X18D           4             4            0
```

Su un dispositivo da ~43.8k LUT4 equivalenti l'incremento resta sotto
il 6% di utilizzo totale — nessun impatto pratico sul budget
risorse. Nessuna DP16KD/MULT18X18D aggiuntiva (il page mode è pura
logica di controllo, non tocca la datapath).

Fmax reale (`nextpnr-ecp5`, stesso comando/vincoli già validati in
"Bitstream reale + banda del gather" e nell'entry "Pin fisici
IRQ_N/DATA_READY_N", `spi_neuron_top`, Tipo #2), misurata sia a
PARALLEL=2 sia a PARALLEL=8 per completezza (prima c'era solo P2):

```text
            PRIMA (sessione precedente)   DOPO (con page mode)
P2          55.59 MHz                     75.73 MHz
P8          non misurato in questa serie  65.13 MHz
```

Entrambe ancora FAIL all'obiettivo 80MHz, ma P2 è **migliore**, non
peggiore, rispetto a prima di questa sessione. Il percorso critico è
stato verificato esplicitamente leggendo il report `nextpnr-ecp5` per
entrambe le configurazioni, non assunto: la sorgente in entrambi i
casi è `u_graph_engine.u_neuron.group_index` → catena
`mac8`/`neuron_parallel` (lo stesso accumulatore CCU2C già
identificato in Fase 7) — **`psram_controller` non compare mai nel
percorso critico**, nonostante la crescita di risorse del page mode.
Coerente con quanto stabilito nello sweep di seed di Fase 7
(`FPGA-NeuralNetwork-Engine.md` §15): il collo di bottiglia resta la
catena di accumulo di `neuron_parallel.v`, non lo stack PSRAM.

**Verifica `tCEM` rafforzata** (richiesta esplicita dell'utente, dopo
il lavoro sopra): `sim/psram_model.v` non aveva un controllo
indipendente sul limite di 8µs di CE# basso — solo il controller lo
rispettava, senza una rete di sicurezza nel modello di test.
Aggiunto un check dedicato (`TCEM_NS = 8000.0`, verificato sia a fine
sessione sia a metà burst) e un test dedicato che tiene una pagina
aperta per centinaia di letture consecutive, mai idle, fino a
superare il budget interno del controller: split confermato (8
chiusure di CE# durante il singolo burst), nessuna violazione
rispetto al limite reale del modello — margine reale, non per
coincidenza. Aggiungere questo controllo ha smascherato una race
Verilog genuina nel modello stesso (due processi indipendenti
triggerati nello stesso istante di simulazione, ordine di esecuzione
non definito dallo standard — non un bug del controller), corretta
con la tecnica standard (`#0` di sincronizzazione). Dettagli completi
in `WORKLOG.md`, sezione "PSRAM page mode — giro di rigore
aggiuntivo".

Tentata anche la ri-esecuzione del benchmark di parallelizzazione
P2/P4/P8 isolato (`tools/fpga_benchmark.py`) per completezza — quel
benchmark sintetizza solo
`mac_unit.v`/`mac8.v`/`neuron_parallel.v`/`layer.v`, non tocca
`psram_controller.v`. Il sotto-processo Yosys per P8 è incappato in
una patologia nota di `abc -g simple` sul netlist completamente
srotolato (256×4×32 MAC), superando le 2 ore di CPU senza terminare;
interrotto, non riprodotto in questa sessione. **Verificato non
essere un effetto del lavoro di oggi** (stesso script, stesso RTL di
input di prima, nessuna modifica su quel percorso). I numeri storici
restano validi perché deterministici su input invariati:

```text
PARALLEL=16   52.13 MHz
PARALLEL=8    61.71 MHz
PARALLEL=4    75.01 MHz
PARALLEL=2    87.88 MHz
```