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

Dit artikel presenteert een real-time FPGA-gebaseerde demonstrator voor spoorreconstructie van 30 MHz in de LHCb-VELO-detector, waarin de architectuur, datadistributie en synchronisatie met uitlijningsconstanten worden toegelicht tijdens de verwerking van live-data gedurende de Run 3-operaties van LHCb.

De kern

Stel je de Large Hadron Collider (LHC) voor als een enorm, snel treinstation waar deeltjes de passagiers zijn. Elke seconde botsen 30 miljoen "bundels" van deze deeltjes op elkaar, wat resulteert in een chaotische explosie van data. Het LHCb-experiment is als een gigantische camera die probeert van elke enkele botsing een foto te maken om uit te zoeken wat er gebeurd is.

Het probleem? Er is te veel data. Als je elke enkele foto zou proberen op te slaan, zou je harde schijf direct vollopen en zou de computer bevriezen. Normaal staat er een "portier" (een computerprogramma) bij de deur die de meeste foto's weggooit en alleen de interessante bewaart. Maar naarmate het treinstation drukker wordt (meer botsingen), moet de portier sneller en slimmer werken.

Dit artikel beschrijft een nieuwe, supersnelle "portier" gebouwd met speciale computerchips die FPGAs heten. Hier is hoe het werkt, eenvoudig uitgelegd:

1. Het "Kunstmatige Netvlies" (Het Slimme Oog)

Het team bouwde een systeem dat ze het "Kunstmatige Netvlies" noemen. Denk hierbij aan een gigantisch, high-tech beveiligingsrooster.

• Het Rooster: Stel je een schaakbord voor waar elk vakje een kleine, onafhankelijke werknemer is.
• De Taak: Elke werknemer krijgt een specifiek "patroon" van een deeltjesbaan (een spoor) toegewezen.
• Het Proces: Wanneer een deeltje een sensor raakt, stuurt het een signaal (een "hit"). Het systeem kijkt niet alleen naar één patroon; het controleert of die hit op precies hetzelfde moment past bij veel verschillende patronen.
• Het Resultaat: Als een hit goed past bij een patroon, raakt die werknemer "geëxciteerd" (zoals een gloeilamp die oplicht). Als genoeg werknemers voor een specifiek patroon geëxciteerd raken, zegt het systeem: "Aha! We hebben een spoor gevonden!"

2. Het Verkeerssysteem (Het Distributienetwerk)

Het moeilijkste deel is het krijgen van de data van de sensoren naar de juiste werknemers.

• Het Probleem: Eén deeltjeshit kan bij verschillende patronen passen, wat betekent dat het gekopieerd en naar meerdere werknemers moet worden gestuurd. Dit veroorzaakt een file.
• De Oplossing: Het team bouwde een aangepast "snelwegsysteem" gemaakt van optische kabels (data met lichtsnelheid). Ze ontwierpen een slim sorteerapparaat (een switch) dat het verkeer organiseert.
• De Optimalisatie: In plaats van willekeurig data te sturen, hebben ze de werknemers zo gerangschikt dat vergelijkbare patronen bij elkaar staan. Dit is als het organiseren van een bibliotheek zodat boeken over hetzelfde onderwerp op hetzelfde plankje staan, waardoor het veel sneller is om te vinden wat je nodig hebt. Dit voorkwam dat het systeem verstopt raakte.

3. De Proefrit (De Demonstrator)

Het team bouwde een prototype (een "demonstrator") om dit idee te testen.

• De Opstelling: Ze gebruikten 8 krachtige computerborden die met glasvezelkabels verbonden waren, die allemaal in één enkele serverrack pasten.
• Het Doel: Ze richtten zich op een specifiek deel van de detector dat de VELO (Vertex Locator) heet, wat als de "voordeur" van het experiment fungeert waar de botsingen eerst plaatsvinden. Ze dekten ongeveer 1/4 van dit gebied af.
• De Simulatie: Eerst voerden ze nepdata in die de echte LHC-botsingen nabootste. Het systeem liep 10 dagen achter elkaar zonder crashen, met een verwerkingssnelheid van 19 miljoen gebeurtenissen per seconde. Dat is ongelooflijk snel! (Het doel is 30 miljoen, maar ze zitten er heel dichtbij).

4. De Realiteitstest (Live Data)

De echte test was het gebruik van het systeem op live data terwijl de LHC daadwerkelijk natuurkundige experimenten uitvoerde.

• De Uitdaging: Echte data is rommelig en verandert voortdurend. Het systeem moest ook de meest actuele "uitlijningsconstanten" gebruiken (denk hierbij aan de nieuwste kaartcoördinaten) om precies te weten waar de sensoren zich bevonden.
• Het Resultaat: Ze bouwden een speciale brug om live data van het bewakingssysteem van het experiment naar hun prototype te voeren. Het systeem liep soepel tijdens echte natuurkundige runs in juli en september.
• De Uitkomst: De sporen die het prototype vond, leken precies op de sporen die door de standaard, langzamere software werden gevonden. Het bewees dat het systeem in de echte wereld werkt zonder iets te breken.

De Conclusie

Dit artikel toont aan dat een nieuw type hardware (FPGAs) gerangschikt in een "Retina"-patroon kan fungeren als een supersnel filter voor deeltjesfysica-data. Het slaagde erin om realtime data van de LHC te verwerken, met miljoenen botsingen per seconde zonder overweldigd te raken.

Het team concludeert dat deze technologie klaar is voor de volgende grote upgrade van de LHC (Run 4). Door dit zware werk naar deze snelle chips te verplaatsen, kunnen ze de kracht van de hoofdcomputers sparen voor andere taken, waardoor het experiment in de toekomst nog meer botsingen aankan.

Technische samenvatting

Technische Samenvatting: Een Real-time Demonstrator voor Spoorherconstructie met FPGAs bij LHCb

Probleemstelling
Experimenten op het gebied van de Hoge-Energiefysica (HEP) staan voor toenemende uitdagingen op het gebied van gegevensstroom en complexiteit, terwijl de wet van Moore tekenen van vertraging vertoont. Het LHCb-experiment vereist, specifiek voor Run 3 en de toekomstige "Upgrade II" (die de lichtsterkte met een factor 5 tot 10 zal verhogen), geavanceerde heterogene rekenarchitecturen om real-time gegevensverwerking te hanteren bij het volledige LHC-botsingsfrequentie (30 MHz). Traditionele CPU/GPU-gebaseerde High Level Triggers (HLT) kunnen moeite hebben met de enorme hoeveelheid gegevens en de behoefte aan verwerking zonder latentie, zonder tijdsmultiplexing of overmatige buffering. De uitdaging is een schaalbare, parallelle verwerkingsoplossing te ontwikkelen die in staat is om sporen in real-time direct te reconstrueren vanuit de detectoruitlezing.

Methodologie
De auteurs presenteren een demonstrator gebaseerd op de "Artificial Retina" (Retina)-architectuur, een sterk geparalleliseerde aangepaste spoorprocessor geïmplementeerd op Field-Programmable Gate Arrays (FPGAs).

• Algoritmische Aanpak: De Retina-architectuur discretiseert de spoorparameterruimte in een matrix van cellen ($M \times N$). Elke cel vertegenwoordigt een referentiespoor en bevat een rekenmotor die een "excitatieniveau" berekent op basis van de compatibiliteit van binnenkomende detectorhits met dat referentiespoor. Dit nabootst een Hough-transformatie. Hits dragen bij aan de accumulator met een gewicht dat wordt bepaald door hun afstand tot de "receptor" van het spoor (snijpunt met de detectorlaag), gebruikmakend van een Gauss-verdeling. Lokale maxima in het excitatiekaart worden geïdentificeerd door Track Processing Units (TPUs) om kandidaat-spoorparameters te schatten.
• Hardware-implementatie: De demonstrator maakt gebruik van acht PCIe-hosted Stratix 10 FPGA-kaarten (Bittware 520N) gehuisvest in één server, onderling verbonden via een snel optisch netwerk. Het systeem is geïntegreerd in de LHCb Coprocessor TestBed-faciliteit, waardoor het tijdens natuurkundige runs opportunistisch live gegevens kan verwerken zonder te interfereren met het standaard Data Acquisition (DAQ)-systeem.
• Distributienetwerk: Een kerncomponent is het aangepaste distributienetwerk opgebouwd uit modulaire splitsers (2s), mergers (2m) en dispatchers (2d, 4d, 8d). Dit netwerk routeert hits van de DAQ-uitlezing naar de relevante FPGA-cellen. Om netwerkcongestie veroorzaakt door hitvermenigvuldiging (waarbij één hit kan bijdragen aan meerdere sporen) te voorkomen, hebben de auteurs een optimalisatiestrategie geïmplementeerd. Dit houdt in dat TPUs worden gesorteerd om die met de meest voorkomende hits te koppelen, waardoor hitverdubbeling wordt uitgesteld tot de lagen het dichtst bij de TPUs. Bovendien is de Post-Switch gewijzigd naar een 8x16 dispatcher-configuratie om de lijnbezetting te beperken.
• Gegevensverwerking: Het systeem is getest in twee modi:
  1. Gesimuleerde Data: Gebeurtenissen gegenereerd bij de nominale Run 3-lichtsterkte ($2 \times 10^{33} \text{ cm}^{-2}\text{s}^{-1}$) werden geladen in interne RAM's.
  2. Live Data: Een aangepaste gegevensketen is ontwikkeld om echte LHCb-botsingsgegevens van het monitoringfarm naar de demonstrator te voeren. Deze keten omvatte een "AlignmentChecker" om real-time afstemmingsconstanten op te halen uit de Condition Database en een "DecodeTransform" om lokale sensordata om te zetten naar het globale LHCb-systeem.

Belangrijkste Bijdragen

• Prototype Demonstrator: Constructie van een aanzienlijke demonstrator die 16 van de 38 VELO (Vertex LOcator)-modules bestrijkt (specifiek het rechteronderste kwadrant), wat een significant deel van de daadwerkelijke detector vertegenwoordigt.
• Geoptimaliseerd Distributienetwerk: Ontwikkeling van een specifiek sorteeralgoritme voor het switchnetwerk dat de factoren voor hitvermenigvuldiging in tussenliggende lagen minimaliseert, waardoor de doorvoer aanzienlijk verbetert.
• Real-time Integratie: Succesvolle integratie van het FPGA-gebaseerde systeem met de live LHCb DAQ-omgeving, waarbij het vermogen wordt aangetoond om echte botsingsgegevens met bijgewerkte afstemmingsconstanten in real-time te verwerken.
• Synchronisatie: Implementatie van een mechanisme om spoorherconstructie te synchroniseren met de meest up-to-date detectorafstemmingsconstanten, een kritieke vereiste voor nauwkeurige natuurkundige analyse.

Resultaten

• Doorvoer: Het systeem bereikte een gebeurtenisfrequentie van 19,0 MHz bij het verwerken van gesimuleerde data bij de nominale Run 3-lichtsterkte. Dit vertegenwoordigt een enorme verbetering ten opzichte van een niet-geoptimaliseerde switch-configuratie, die onder dezelfde omstandigheden slechts 170 kHz opleverde.
• Betrouwbaarheid: Het systeem draaide 10 dagen ononderbroken op gesimuleerde data en opereerde soepel gedurende ongeveer 60 dagen tijdens live dataverzameling (medio juli en september) zonder crashes of abnormaal gedrag.
• Nauwkeurigheid: De gereconstrueerde sporen van de demonstrator toonden kwalitatieve overeenstemming met de standaard LHCb-softwareherconstructie (HLT2) wat betreft de tweedimensionale verdeling van spoorparameters ($u-v$-ruimte). Bit-niveau consistentie werd bevestigd door periodiek gesimuleerde datapakketten in de live datastroom te injecteren, die overeenkwamen met de output van een C++ bitwise-emulator.
• Beperkingen: De bereikte snelheid van 19,0 MHz ligt momenteel een factor 1,58 onder de doelwit-LHC gemiddelde bundelkruisingsfrequentie van 30 MHz. De auteurs merken op dat de definitieve selectielogica (acceptatiecuts, clone killing) nog niet was geïmplementeerd in deze demonstrator.

Betekenis en Beweringen
Het artikel beweert dat de Retina-technologie een volwassenheidsniveau heeft bereikt dat geschikt is voor toepassingen in de echte wereld bij toekomstige HEP-experimenten. De succesvolle demonstratie van het verwerken van live LHCb-data met hoge snelheden, gecombineerd met de identificatie van specifieke firmware- en architecturale optimalisaties (zoals verdere verhoging van de klokkfrequentie en verbetering van logische ketens), suggereert dat de doelwitfrequentie van 30 MHz haalbaar is met de huidige hardwaregeneratie.

Bijgevolg heeft de LHCb-samenwerking een voorstel ingediend bij het LHC-wetenschappelijk comité om een eerste natuurkundige toepassing van de Retina-architectuur in Run 4 te implementeren. Deze toepassing heeft tot doel delen van de spoorherconstructie uit te besteden aan FPGAs die transparant opereren op het uitleesniveau, waardoor HLT1-rekenkracht wordt bespaard. Het werk valideert de haalbaarheid van het gebruik van FPGA-gebaseerde "Artificial Retina"-architecturen om de extreme gegevenssnelheden aan te kunnen die worden verwacht bij toekomstige runs met hoge lichtsterkte.