Riepilogo Tecnico: SparsePixels: Convoluzione Efficiente per Dati Sparsi su FPGA

1. Definizione del Problema

Le reti neurali convoluzionali (CNN) standard implementate su Field-Programmable Gate Arrays (FPGA) per esperimenti di fisica delle particelle soffrono spesso di alta latenza di inferenza e lunghi intervalli di iniziazione. Questa inefficienza deriva dal fatto che la convoluzione standard richiede l'elaborazione densa di ogni pixel di input, indipendentemente dal fatto che il pixel contenga informazioni semantiche. In molte moderne applicazioni di rilevamento, come il tracciamento dei muoni in camere a gas o l'identificazione dei neutrini in camere a proiezione temporale di Argon liquido (LArTPC), i dati di input sono spazialmente sparsi. Ad esempio, una traccia di un muone può occupare meno dello 0,3% di un'immagine 2D, e le tracce di neutrini nei LArTPC possono avere solo lo 0,01% di pixel non nulli.

Le attuali implementazioni FPGA, come quelle che utilizzano la libreria hls4ml, si affidano tipicamente allo streaming di Input/Output (I/O) per gestire i vincoli di risorse. Sebbene lo streaming riduca l'uso delle risorse, esso elabora i pixel sequenzialmente, portando a latenze che scalano linearmente con la dimensione dell'immagine (ad esempio, scansionando migliaia di pixel vuoti). Ciò rende le CNN standard impraticabili per i sistemi di trigger in tempo reale negli esperimenti di fisica delle alte energie, che richiedono latenze decisionali nell'ordine dei microsecondi o sub-microsecondi per gestire tassi di collisione di 40 MHz.

I metodi di convoluzione sparsa esistenti per le GPU (ad esempio, MinkowskiEngine, SpConv) spesso permettono al set di pixel attivi di "dilatarsi" attraverso i livelli, aumentando il costo computazionale, o si affidano a flussi di dati irregolari che risultano in tempi di esecuzione dipendenti dall'input. In sistemi con vincoli di latenza rigorosi, il tempo di esecuzione variabile è inaccettabile.

2. Metodologia: Il Framework SparsePixels

Gli autori introducono SparsePixels, un framework progettato per implementare la convoluzione sparsa su FPGA che mantiene un tempo di esecuzione costante e indipendente dall'input. La filosofia centrale è quella di trattenere e computare selettivamente solo un piccolo sottoinsieme predefinito di pixel attivi, ignorando il resto, garantendo che il numero totale di operazioni rimanga fisso per ogni input.

2.1 Architettura Core

Il framework consiste in cinque livelli sparsi specializzati progettati per l'HLS (High-Level Synthesis):

1. Riduzione dell'Input Sparso: Il primo livello identifica i pixel attivi (quelli che superano una soglia) ed estrae loro in array compatti. Per evitare indirizzi di scrittura dipendenti dai dati (che causano problemi di scheduling in HLS), gli autori utilizzano un albero di riduzione binaria ricorsivo. Questo schema, efficiente per l'hardware, scansiona l'input secondo un pattern fisso per popolare due array: un array di feature (afeat) e un array di hash delle coordinate (ahash). Il numero di pixel trattenuti è limitato da un iperparametro, $N_{max}^{active}$.
2. Convoluzione Sparsa: Questo livello esegue una convoluzione che preserva la sparsità. Fondamentalmente, un pixel di output viene calcolato solo se il corrispondente pixel di input nella stessa posizione è attivo. Ciò impedisce la "dilatazione" del set attivo osservata in altri metodi di sparsità. L'algoritmo itera sugli array di dimensione fissa anziché sull'intera griglia dell'immagine. Il conteggio delle iterazioni dipende da $N_{max}^{active}$, non dalla dimensione del kernel $K$, poiché le posizioni del kernel sono determinate tramite controlli di offset piuttosto che tramite espliciti cicli su tutte le $K^2$ posizioni.
3. Attivazione Sparsa: Applica la non linearità elemento per elemento all'array di feature sparse.
4. Pooling Sparso: Sottocampiona la rappresentazione sparsa mappando le coordinate e accumulando le feature per i pixel che ricadono nello stesso pool.
5. Flattening Sparso: Converte la rappresentazione sparsa finale in un array denso per la connessione a livelli densi standard (MLP).

2.2 Dettagli di Implementazione

• Tempo di Esecuzione Costante: Poiché il sistema opera su array di dimensione fissa ($N_{max}^{active}$), integrati con flag di invalidità se l'input ha meno pixel attivi, la latenza di inferenza è indipendente dalla reale sparsità dell'input.
• Addestramento: È stata sviluppata una libreria Python per addestrare queste CNN sparse utilizzando il Quantization-Aware Training (QAT) con QKeras come backend. L'addestramento imita il comportamento HLS, incluso il vincolo di $N_{max}^{active}$ fisso.
• Target Hardware: Il design punta agli FPGA AMD/Xilinx Alveo (xcu250) utilizzando Vitis HLS, operando a 200 MHz.

3. Contributi Chiave

1. Metodo di Convoluzione Sparsa: Un approccio innovativo per gli FPGA che seleziona adattivamente i pixel attivi ma impone un budget di computazione fisso ($N_{max}^{active}$), garantendo una latenza costante indipendentemente dalla sparsità dell'input.
2. Implementazione Proof-of-Concept: Una dimostrazione di significativi miglioramenti della velocità di inferenza su FPGA con dati d'immagine spazialmente sparsi, con prestazioni del modello comparabili alle CNN standard con I/O di streaming.
3. Strumentazione Open-Source: Una libreria Python pubblicamente rilasciata per l'addestramento di CNN sparse e moduli C++ HLS per il deployment, facilitando l'adozione nella comunità della fisica delle particelle.

4. Risultati Sperimentali

Gli autori hanno valutato SparsePixels su tre dataset: una variante sparsificata di MNIST, la rilevazione di neutrini MicroBooNE e il jet flavor tagging di LHC. I modelli erano compatti (~4k parametri) e confrontati con baseline di CNN standard implementate con I/O di streaming.

• Performance vs. Latenza: Sul dataset MicroBooNE (immagini 63×63, ~4k pixel), una CNN standard a 8 bit ha richiesto 48,665 µs (9.733 cicli di clock) per l'inferenza. La variante "sparse-large" di SparsePixels (che computa su soli 20 pixel attivi, <1% dell'input) ha ottenuto un tempo di inferenza di 0,665 µs (133 cicli di clock). Ciò rappresenta un incremento di velocità di 73× con una perdita di prestazioni trascurabile (<2% di calo nel ROC AUC).
• Scalabilità: Simili incrementi di velocità sono stati osservati per MNIST (fino a 41×) e per il jet tagging di LHC (fino a 112×).
• Utilizzo delle Risorse: Sebbene le CNN sparse utilizzino più risorse (a causa dell'unrolling dei cicli per il parallelismo) rispetto alle CNN standard in streaming, l'utilizzo delle risorse rimane ampiamente entro i budget on-chip (ad esempio, ~20% delle LUT per i modelli più grandi).
• Intervallo di Iniziazione (II): L'II per le CNN sparse è determinato esclusivamente dal livello di riduzione dell'input sparso (il primo livello), poiché i successivi operano in parallelo sugli array sparsi a dimensione fissa.

5. Significato e Limitazioni

Significato:
Il paper sostiene che SparsePixels permetta il deployment di CNN in regimi di latenza ultra-bassa (sub-microsecondo) richiesti dai moderni trigger della fisica delle particelle, dove le CNN standard sono attualmente impraticabili a causa della latenza. Scambiando una piccola quantità controllabile di accuratezza con enormi incrementi di velocità, il framework permette algoritmi online più sofisticati in esperimenti come l'High-Luminosity LHC.

Limitazioni e Lavori Futuri:

• Vincoli di Parallelizzazione: L'implementazione attuale esegue il full unrolling dei cicli per minimizzare la latenza, il che limita la dimensione massima dell'input e la complessità del modello a causa dell'esaurimento delle risorse FPGA. Il lavoro futuro mira a introdurre un controllo flessibile sulla parallelizzazione per scambiare latenza con efficienza delle risorse.
• Tuning degli Iperparametri: La scelta di $N_{max}^{active}$ è attualmente empirica. Gli autori propongono di rendere questo parametro (e potenzialmente la soglia) addestrabile nelle versioni future.
• Quantizzazione: Il backend attuale utilizza una quantizzazione uniforme per livello. Gli aggiornamenti futuri prevedono l'adozione di una High-Granularity Quantization (HGQ) per un controllo più fine.

Gli autori concludono che SparsePixels offre una via percorribile per un'efficiente lettura dei dati in esperimenti con requisiti di latenza nell'ordine dei microsecondi, colmando il divario tra la necessità di modelli ML complessi e i severi vincoli temporali dei trigger hardware in tempo reale.