A real-time demonstrator of track reconstruction with FPGAs at LHCb

Questo documento presenta un dimostratore in tempo reale basato su FPGA per la ricostruzione di tracce a 30 MHz nel rivelatore VELO di LHCb, dettagliandone l'architettura, la distribuzione dei dati e la sincronizzazione con le costanti di allineamento durante l'elaborazione di dati in tempo reale nelle operazioni della Run 3 di LHCb.

L'essenziale

Immagina il Large Hadron Collider (LHC) come una stazione ferroviaria massiccia e ad alta velocità, dove le particelle sono i passeggeri. Ogni secondo, 30 milioni di "pacchetti" di queste particelle si scontrano tra loro, creando un'esplosione caotica di dati. L'esperimento LHCb è come una gigantesca fotocamera che cerca di scattare una foto a ogni singolo scontro per capire cosa è successo.

Il problema? Ci sono troppi dati. Se provassi a salvare ogni singola foto, il tuo hard disk si riempirebbe istantaneamente e il computer si bloccherebbe. Di solito, un "buttafuori" (un programma informatico) sta alla porta e scarta la maggior parte delle foto, trattenendo solo quelle interessanti. Ma mentre la stazione ferroviaria diventa più affollata (più collisioni), il buttafuori deve lavorare più velocemente e in modo più intelligente.

Questo articolo descrive un nuovo "buttafuori" super-veloce costruito utilizzando speciali chip informatici chiamati FPGA. Ecco come funziona, spiegato in modo semplice:

1. La "Rete Artificiale" (L'Occhio Intelligente)

Il team ha costruito un sistema che chiamano "Rete Artificiale". Pensateci come a una gigantesca griglia di sicurezza high-tech.

• La Griglia: Immaginate una scacchiera dove ogni quadrato è un piccolo lavoratore indipendente.
• Il Lavoro: Ogni lavoratore è assegnato a un specifico "modello" di percorso di una particella (una traccia).
• Il Processo: Quando una particella colpisce un sensore, invia un segnale (un "colpo"). Il sistema non cerca solo un modello; verifica se quel colpo si adatta a molti modelli diversi esattamente nello stesso momento.
• Il Risultato: Se un colpo si adatta bene a un modello, quel lavoratore si "eccita" (come una lampadina che si accende). Se abbastanza lavoratori per un modello specifico si eccitano, il sistema dice: "Aha! Abbiamo trovato una traccia!"

2. Il Sistema di Traffico (La Rete di Distribuzione)

La parte più difficile è portare i dati dai sensori ai lavoratori giusti.

• Il Problema: Un singolo colpo di particella potrebbe adattarsi a diversi modelli, il che significa che deve essere copiato e inviato a più lavoratori. Questo crea un ingorgo.
• La Soluzione: Il team ha costruito un sistema "autostradale" personalizzato fatto di cavi in fibra ottica (dati alla velocità della luce). Hanno progettato una macchina di smistamento intelligente (uno switch) che organizza il traffico.
• L'Ottimizzazione: Invece di inviare i dati in modo casuale, hanno disposto i lavoratori in modo che modelli simili siano raggruppati insieme. È come organizzare una biblioteca in modo che i libri sullo stesso argomento siano sullo stesso scaffale, rendendo molto più veloce trovare ciò di cui si ha bisogno. Questo ha impedito al sistema di intasarsi.

3. La Prova di Guida (Il Dimostratore)

Il team ha costruito un prototipo (un "dimostratore") per testare questa idea.

• La Configurazione: Hanno utilizzato 8 potenti schede informatiche collegate da cavi in fibra ottica, tutte contenute in un singolo rack server.
• L'Obiettivo: Si sono concentrati su una parte specifica del rivelatore chiamata VELO (Vertex Locator), che è come la "porta d'ingresso" dell'esperimento dove avvengono per prime le collisioni. Hanno coperto circa 1/4 di questa area.
• La Simulazione: Prima, hanno immesso nel sistema dati finti che mimavano le reali collisioni dell'LHC. Il sistema è rimasto in funzione per 10 giorni consecutivi senza crash, elaborando dati a una velocità di 19 milioni di eventi al secondo. È incredibilmente veloce! (L'obiettivo è 30 milioni, ma sono molto vicini).

4. Il Test nel Mondo Reale (Dati in Diretta)

Il vero test è stato utilizzare il sistema su dati in diretta mentre l'LHC stava effettivamente conducendo esperimenti di fisica.

• La Sfida: I dati reali sono disordinati e cambiano costantemente. Il sistema doveva anche utilizzare le più recenti "costanti di allineamento" (pensate a queste come alle coordinate della mappa più aggiornate) per sapere esattamente dove si trovavano i sensori.
• Il Risultato: Hanno costruito un ponte speciale per inviare dati in diretta dal sistema di monitoraggio dell'esperimento al loro prototipo. Il sistema ha funzionato senza intoppi durante le reali sessioni di fisica di luglio e settembre.
• L'Esito: Le tracce trovate dal prototipo sembravano esattamente quelle trovate dal software standard, più lento. Ha dimostrato che il sistema funziona nel mondo reale senza rompere nulla.

Il Punto Chiave

Questo articolo mostra che un nuovo tipo di hardware (FPGA) disposto in un pattern a "Rete" può agire come un filtro super-veloce per i dati della fisica delle particelle. Ha elaborato con successo dati in tempo reale dall'LHC, gestendo milioni di collisioni al secondo senza essere sopraffatto.

Il team conclude che questa tecnologia è pronta per il prossimo grande aggiornamento dell'LHC (Run 4). Spostando questo lavoro pesante su questi chip veloci, possono risparmiare la potenza dei computer principali per altre attività, permettendo all'esperimento di gestire ancora più collisioni in futuro.

Sommario tecnico

Sintesi Tecnica: Un Dimostratore in Tempo Reale di Ricostruzione di Tracce con FPGA presso LHCb

Enunciato del Problema
Gli esperimenti di Fisica delle Alte Energie (HEP) affrontano sfide crescenti legate al flusso di dati e alla complessità, mentre la Legge di Moore mostra segni di rallentamento. L'esperimento LHCb, in particolare per la sua Run 3 e per il futuro "Upgrade II" (che aumenterà la luminosità di un fattore da 5 a 10), richiede architetture di calcolo eterogenee avanzate per gestire l'elaborazione dei dati in tempo reale alla piena frequenza di collisione del LHC (30 MHz). I tradizionali Trigger di Livello Alto (HLT) basati su CPU/GPU potrebbero faticare con il volume enorme di dati e con la necessità di elaborazione a latenza zero senza multiplexing temporale o buffering eccessivo. La sfida consiste nello sviluppare una soluzione di elaborazione parallela scalabile, capace di ricostruire le tracce in tempo reale direttamente dall'acquisizione del rivelatore.

Metodologia
Gli autori presentano un dimostratore basato sull'architettura "Retina Artificiale" (Retina), un processore di tracciamento personalizzato altamente parallelizzato implementato su Field-Programmable Gate Arrays (FPGA).

• Approccio Algoritmico: L'architettura Retina discretizza lo spazio dei parametri delle tracce in una matrice di celle ($M \times N$). Ogni cella rappresenta una traccia di riferimento e contiene un motore di calcolo che calcola un "livello di eccitazione" basato sulla compatibilità tra i segnali (hit) in arrivo dal rivelatore e quella traccia di riferimento. Questo simula una trasformata di Hough. Gli hit contribuiscono all'accumulatore con un peso determinato dalla loro distanza dal "recettore" della traccia (l'intersezione con lo strato del rivelatore), utilizzando una distribuzione gaussiana. I massimi locali nella mappa di eccitazione sono identificati dalle Unità di Elaborazione Tracce (TPU) per stimare i parametri delle tracce candidate.
• Implementazione Hardware: Il dimostratore utilizza otto schede FPGA Stratix 10 ospitate via PCIe (Bittware 520N) contenute in un singolo server, interconnesse tramite una rete ottica veloce. Il sistema è integrato nella struttura Coprocessor TestBed di LHCb, permettendogli di elaborare dati live in modo opportunistico durante le prese dati fisiche senza interferire con il sistema standard di Acquisizione Dati (DAQ).
• Rete di Distribuzione: Un componente fondamentale è la rete di distribuzione personalizzata costruita con splitter modulari (2s), merger (2m) e dispatcher (2d, 4d, 8d). Questa rete instrada gli hit dall'acquisizione DAQ alle celle FPGA pertinenti. Per prevenire la congestione della rete causata dalla moltiplicazione degli hit (dove un singolo hit può contribuire a più tracce), gli autori hanno implementato una strategia di ottimizzazione. Questa prevede l'ordinamento delle TPU per accoppiare quelle con gli hit più comuni, ritardando così la duplicazione degli hit agli strati più vicini alle TPU. Inoltre, il Post-Switch è stato modificato in una configurazione dispatcher 8x16 per limitare l'occupazione delle linee.
• Elaborazione Dati: Il sistema è stato testato in due modalità:
  1. Dati Simulati: Eventi generati alla luminosità nominale della Run 3 ($2 \times 10^{33} \text{ cm}^{-2}\text{s}^{-1}$) sono stati caricati nelle RAM interne.
  2. Dati Live: È stata sviluppata una catena dati personalizzata per alimentare il dimostratore con dati reali di collisione LHCb provenienti dalla farm di monitoraggio. Questa catena includeva un "AlignmentChecker" per recuperare le costanti di allineamento in tempo reale dal Database delle Condizioni e un "DecodeTransform" per convertire le coordinate locali dei sensori nel sistema globale LHCb.

Contributi Chiave

• Dimostratore Prototipo: Costruzione di un dimostratore di dimensioni considerevoli che copre 16 dei 38 moduli VELO (Vertex LOcator) (specificamente il quadrante a valle del lato destro), rappresentando una porzione significativa del rivelatore reale.
• Rete di Distribuzione Ottimizzata: Sviluppo di un algoritmo di ordinamento specifico per la rete di switching che minimizza i fattori di moltiplicazione degli hit negli strati intermedi, migliorando significativamente la velocità di elaborazione.
• Integrazione in Tempo Reale: Integrazione riuscita del sistema basato su FPGA con l'ambiente DAQ live di LHCb, dimostrando la capacità di elaborare dati di collisione reali con costanti di allineamento aggiornate in tempo reale.
• Sincronizzazione: Implementazione di un meccanismo per sincronizzare la ricostruzione delle tracce con le costanti di allineamento del rivelatore più aggiornate, un requisito critico per un'analisi fisica accurata.

Risultati

• Velocità di Elaborazione: Il sistema ha raggiunto una frequenza di eventi di 19,0 MHz elaborando dati simulati alla luminosità nominale della Run 3. Questo rappresenta un miglioramento massiccio rispetto a una configurazione di switching non ottimizzata, che ha prodotto solo 170 kHz nelle stesse condizioni.
• Affidabilità: Il sistema è stato eseguito senza interruzioni per 10 giorni su dati simulati e ha funzionato regolarmente per circa 60 giorni durante la presa dati live (metà luglio e settembre) senza crash o comportamenti anomali.
• Accuratezza: Le tracce ricostruite dal dimostratore hanno mostrato un accordo qualitativo con la ricostruzione software standard di LHCb (HLT2) in termini di distribuzione bidimensionale dei parametri delle tracce (spazio $u-v$). La coerenza a livello di bit è stata confermata iniettando periodicamente pacchetti di dati simulati nel flusso di dati live, che corrispondevano all'output di un emulatore bitwise C++.
• Limitazioni: La frequenza raggiunta di 19,0 MHz è attualmente inferiore di un fattore 1,58 rispetto alla frequenza media target di incrocio dei fasci del LHC di 30 MHz. Gli autori notano che la logica di selezione finale (tagli di accettazione, eliminazione dei cloni) non era ancora implementata in questo dimostratore.

Significato e Affermazioni
Il documento afferma che la tecnologia Retina ha raggiunto un livello di maturità adatto ad applicazioni nel mondo reale per futuri esperimenti HEP. La dimostrazione riuscita dell'elaborazione di dati live di LHCb ad alte frequenze, combinata con l'identificazione di ottimizzazioni specifiche del firmware e dell'architettura (come ulteriori aumenti della frequenza di clock e miglioramenti della catena logica), suggerisce che la frequenza target di 30 MHz è raggiungibile utilizzando la generazione hardware corrente.

Di conseguenza, la collaborazione LHCb ha presentato una proposta al comitato scientifico del LHC per implementare una prima applicazione fisica dell'architettura Retina nella Run 4. Questa applicazione mira a scaricare parti della ricostruzione delle tracce su FPGA che operano in modo trasparente a livello di acquisizione, risparmiando così potenza di calcolo per l'HLT1. Il lavoro convalida la fattibilità dell'uso di architetture "Retina Artificiale" basate su FPGA per gestire le velocità di dati estreme previste nelle future corse ad alta luminosità.