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

Cet article présente un démonstrateur en temps réel basé sur FPGA pour la reconstruction de traces à 30 MHz dans le détecteur VELO de LHCb, détaillant son architecture, la distribution des données et la synchronisation avec les constantes d'alignement tout en traitant des données en direct durant les opérations de la Run 3 de LHCb.

L'essentiel

Imaginez le Grand collisionneur de hadrons (LHC) comme une immense gare ferroviaire à grande vitesse où les particules sont les passagers. Chaque seconde, 30 millions de « paquets » de ces particules entrent en collision les uns avec les autres, créant une explosion chaotique de données. L'expérience LHCb est comparable à un appareil photo géant tentant de capturer chaque collision individuelle pour déterminer ce qui s'est produit.

Le problème ? Il y a trop de données. Si vous essayiez de sauvegarder chaque photo, votre disque dur se remplirait instantanément et l'ordinateur se figerait. Habituellement, un « videur » (un programme informatique) se tient à l'entrée et rejette la plupart des photos, ne conservant que celles qui sont intéressantes. Mais à mesure que la gare devient plus fréquentée (plus de collisions), le videur doit travailler plus vite et plus intelligemment.

Ce papier décrit un nouveau « videur » ultra-rapide construit à l'aide de puces informatiques spéciales appelées FPGA. Voici comment cela fonctionne, expliqué simplement :

1. La « Rétine Artificielle » (L'Œil Intelligent)

L'équipe a construit un système qu'ils appellent la « Rétine Artificielle ». Imaginez-la comme une immense grille de sécurité high-tech.

• La Grille : Imaginez un damier où chaque case est un petit travailleur indépendant.
• La Tâche : Chaque travailleur est assigné à un « motif » spécifique d'une trajectoire de particule (une trace).
• Le Processus : Lorsqu'une particule frappe un capteur, elle envoie un signal (un « hit »). Le système ne cherche pas un seul motif ; il vérifie si ce hit correspond à plusieurs motifs différents exactement au même moment.
• Le Résultat : Si un hit correspond bien à un motif, ce travailleur s'« excite » (comme une ampoule qui s'allume). Si suffisamment de travailleurs pour un motif spécifique s'excitent, le système déclare : « Aha ! Nous avons trouvé une trace ! »

2. Le Système de Circulation (Le Réseau de Distribution)

La partie la plus difficile consiste à acheminer les données des capteurs vers les bons travailleurs.

• Le Problème : Un seul impact de particule peut correspondre à plusieurs motifs différents, ce qui signifie qu'il doit être copié et envoyé à plusieurs travailleurs. Cela crée un embouteillage.
• La Solution : L'équipe a construit un « réseau autoroutier » personnalisé composé de câbles optiques (données à la vitesse de la lumière). Ils ont conçu une machine de tri intelligente (un commutateur) qui organise la circulation.
• L'Optimisation : Au lieu d'envoyer les données au hasard, ils ont organisé les travailleurs de sorte que les motifs similaires soient regroupés. C'est comme organiser une bibliothèque pour que les livres sur le même sujet se trouvent sur la même étagère, rendant la recherche de ce dont vous avez besoin beaucoup plus rapide. Cela a empêché le système de se saturer.

3. L'Essai Routier (Le Démonstrateur)

L'équipe a construit un prototype (un « démonstrateur ») pour tester cette idée.

• La Configuration : Ils ont utilisé 8 cartes informatiques puissantes reliées par des câbles à fibre optique, toutes tenant dans un seul rack serveur.
• La Cible : Ils se sont concentrés sur une partie spécifique du détecteur appelée VELO (Vertex Locator), qui agit comme la « porte d'entrée » de l'expérience où les collisions se produisent en premier. Ils ont couvert environ 1/4 de cette zone.
• La Simulation : D'abord, ils ont alimenté le système avec de fausses données imitant les vraies collisions du LHC. Le système a fonctionné pendant 10 jours d'affilée sans planter, traitant des données à un rythme de 19 millions d'événements par seconde. C'est incroyablement rapide ! (L'objectif est de 30 millions, mais ils sont très proches).

4. Le Test en Conditions Réelles (Données en Direct)

Le véritable test consistait à utiliser le système sur des données en direct pendant que le LHC menait réellement des expériences de physique.

• Le Défi : Les données réelles sont désordonnées et changent constamment. Le système devait également utiliser les « constantes d'alignement » les plus récentes (pensez-y comme les dernières coordonnées de carte) pour savoir exactement où se trouvaient les capteurs.
• Le Résultat : Ils ont construit un pont spécial pour alimenter le prototype avec des données en direct provenant du système de surveillance de l'expérience. Le système a fonctionné sans accroc lors des runs physiques réels en juillet et septembre.
• Le Résultat Final : Les traces trouvées par le prototype ressemblaient exactement à celles trouvées par le logiciel standard, plus lent. Cela a prouvé que le système fonctionne dans le monde réel sans rien casser.

La Conclusion

Ce papier montre qu'un nouveau type de matériel (FPGA) disposé selon un motif « Rétine » peut agir comme un filtre ultra-rapide pour les données de physique des particules. Il a traité avec succès des données en temps réel du LHC, gérant des millions de collisions par seconde sans être submergé.

L'équipe conclut que cette technologie est prête pour la prochaine grande mise à niveau du LHC (Run 4). En déplaçant cette tâche lourde vers ces puces rapides, ils peuvent économiser la puissance des ordinateurs principaux pour d'autres tâches, permettant à l'expérience de gérer encore plus de collisions à l'avenir.

Résumé technique

Résumé technique : Un démonstrateur temps réel de reconstruction de traces avec des FPGA au LHCb

Énoncé du problème
Les expériences de physique des hautes énergies (PHE) font face à des défis croissants en matière de flux de données et de complexité, tandis que la loi de Moore montre des signes de ralentissement. L'expérience LHCb, spécifiquement pour sa Run 3 et le futur « Upgrade II » (qui augmentera la luminosité d'un facteur 5 à 10), nécessite des architectures de calcul hétérogènes avancées pour gérer le traitement des données en temps réel à la pleine fréquence de collisions du LHC (30 MHz). Les déclencheurs de haut niveau (HLT) traditionnels basés sur CPU/GPU pourraient avoir du mal à faire face au volume colossal de données et au besoin d'un traitement à latence nulle sans multiplexage temporel ni tamponnement excessif. Le défi consiste à développer une solution de traitement parallèle évolutive capable de reconstruire des traces en temps réel directement à partir de la lecture des détecteurs.

Méthodologie
Les auteurs présentent un démonstrateur basé sur l'architecture « Rétine artificielle » (Retina), un processeur de suivi personnalisé hautement parallélisé implémenté sur des réseaux de portes programmables en champ (FPGA).

• Approche algorithmique : L'architecture Rétine discrétise l'espace des paramètres de trace en une matrice de cellules ($M \times N$). Chaque cellule représente une trace de référence et contient un moteur de calcul qui calcule un « niveau d'excitation » basé sur la compatibilité des coups détecteurs entrants avec cette trace de référence. Cela imite une transformée de Hough. Les coups contribuent à l'accumulateur avec un poids déterminé par leur distance par rapport au « récepteur » de la trace (intersection avec la couche du détecteur), en utilisant une distribution gaussienne. Les maxima locaux de la carte d'excitation sont identifiés par des unités de traitement de traces (TPU) pour estimer les paramètres des traces candidates.
• Implémentation matérielle : Le démonstrateur utilise huit cartes FPGA Stratix 10 hébergées par PCIe (Bittware 520N) logées dans un seul serveur, interconnectées via un réseau optique rapide. Le système est intégré dans l'installation de test de coprocesseur du LHCb, lui permettant de traiter des données en direct de manière opportuniste pendant les prises de données physiques sans interférer avec le système d'acquisition de données (DAQ) standard.
• Réseau de distribution : Un composant central est le réseau de distribution personnalisé construit à partir de séparateurs modulaires (2s), de combinateurs (2m) et de répartiteurs (2d, 4d, 8d). Ce réseau achemine les coups depuis la lecture du DAQ vers les cellules FPGA pertinentes. Pour éviter la congestion du réseau causée par la multiplication des coups (où un coup peut contribuer à plusieurs traces), les auteurs ont mis en œuvre une stratégie d'optimisation. Cela implique d'ordonner les TPU pour qu'ils appairent ceux partageant le plus de coups communs, retardant ainsi la duplication des coups vers les couches les plus proches des TPU. De plus, le Post-Switch a été modifié en une configuration de répartiteur 8x16 pour limiter l'occupation des lignes.
• Traitement des données : Le système a été testé dans deux modes :
  1. Données simulées : Des événements générés à la luminosité nominale de la Run 3 ($2 \times 10^{33} \text{ cm}^{-2}\text{s}^{-1}$) ont été chargés dans des mémoires RAM internes.
  2. Données en direct : Une chaîne de données personnalisée a été développée pour alimenter le démonstrateur avec de vraies données de collisions LHCb provenant de la ferme de surveillance. Cette chaîne comprenait un « AlignmentChecker » pour récupérer les constantes d'alignement en temps réel depuis la base de données de conditions et un « DecodeTransform » pour convertir les coordonnées locales des capteurs vers le système global LHCb.

Contributions clés

• Démonstrateur prototype : Construction d'un démonstrateur de taille significative couvrant 16 des 38 modules VELO (Vertex LOcator) (spécifiquement le quadrant aval du côté droit), représentant une portion importante du détecteur réel.
• Réseau de distribution optimisé : Développement d'un algorithme d'ordonnancement spécifique pour le réseau de commutation qui minimise les facteurs de multiplication des coups dans les couches intermédiaires, améliorant considérablement le débit.
• Intégration temps réel : Intégration réussie du système basé sur FPGA avec l'environnement DAQ en direct du LHCb, démontrant la capacité à traiter des données de collisions réelles avec des constantes d'alignement mises à jour en temps réel.
• Synchronisation : Mise en œuvre d'un mécanisme pour synchroniser la reconstruction de traces avec les constantes d'alignement du détecteur les plus récentes, une exigence critique pour une analyse physique précise.

Résultats

• Débit : Le système a atteint un taux d'événements de 19,0 MHz lors du traitement de données simulées à la luminosité nominale de la Run 3. Cela représente une amélioration massive par rapport à une configuration de commutation non optimisée, qui n'obtenait que 170 kHz dans les mêmes conditions.
• Fiabilité : Le système a fonctionné sans interruption pendant 10 jours sur des données simulées et a opéré de manière fluide pendant environ 60 jours lors de la prise de données en direct (mi-juillet et septembre) sans plantage ni comportement anormal.
• Précision : Les traces reconstruites par le démonstrateur ont montré un accord qualitatif avec la reconstruction logicielle standard du LHCb (HLT2) en termes de distribution bidimensionnelle des paramètres de trace (espace $u-v$). La cohérence au niveau des bits a été confirmée en injectant périodiquement des paquets de données simulés dans le flux de données en direct, qui correspondaient à la sortie d'un émulateur binaire en C++.
• Limitations : Le taux atteint de 19,0 MHz est actuellement inférieur d'un facteur 1,58 au taux moyen de croisement de faisceau cible du LHC de 30 MHz. Les auteurs notent que la logique de sélection finale (coupes d'acceptation, élimination des clones) n'était pas encore implémentée dans ce démonstrateur.

Signification et revendications
L'article affirme que la technologie Rétine a atteint un niveau de maturité adapté aux applications réelles dans les futures expériences de PHE. La démonstration réussie du traitement de données LHCb en direct à hauts débits, combinée à l'identification d'optimisations spécifiques du firmware et de l'architecture (telles que des augmentations supplémentaires de la fréquence d'horloge et des améliorations de la chaîne logique), suggère que le taux cible de 30 MHz est à portée de main en utilisant la génération matérielle actuelle.

Par conséquent, la collaboration LHCb a soumis une proposition au comité scientifique du LHC pour mettre en œuvre une première application physique de l'architecture Rétine lors de la Run 4. Cette application vise à décharger une partie de la reconstruction de traces vers des FPGA opérant de manière transparente au niveau de la lecture, épargnant ainsi la puissance de calcul du HLT1. Ce travail valide la faisabilité de l'utilisation d'architectures « Rétine artificielle » basées sur FPGA pour gérer les débits de données extrêmes anticipés dans les futures runs à haute luminosité.