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

Dieser Beitrag stellt einen Echtzeit-Demonstrator auf FPGA-Basis für die Spur-Rekonstruktion mit 30 MHz im VELO-Detektor von LHCb vor und beschreibt dessen Architektur, Datenverteilung sowie die Synchronisation mit Ausrichtungskonstanten während der Verarbeitung von Live-Daten im Rahmen des LHCb-Runs 3.

Das Wesentliche

Stellen Sie sich den Large Hadron Collider (LHC) als einen massiven, Hochgeschwindigkeits-Bahnhof vor, in dem Teilchen die Fahrgäste sind. Jede Sekunde prallen 30 Millionen „Bündel" dieser Teilchen miteinander zusammen und erzeugen eine chaotische Explosion von Daten. Das LHCb-Experiment ist wie eine riesige Kamera, die versucht, von jedem einzelnen Zusammenstoß ein Foto zu machen, um herauszufinden, was passiert ist.

Das Problem? Es gibt zu viele Daten. Wenn Sie versuchen würden, jedes einzelne Foto zu speichern, würde sich Ihre Festplatte sofort füllen und der Computer einfrieren. Normalerweise steht ein „Türsteher" (ein Computerprogramm) an der Tür und wirft die meisten Fotos weg, behält nur die interessanten. Doch je voller der Bahnhof wird (mehr Kollisionen), desto schneller und schlauer muss der Türsteher arbeiten.

Diese Arbeit beschreibt einen neuen, superschnellen „Türsteher", der mit speziellen Computerchips namens FPGAs gebaut wurde. So funktioniert es, einfach erklärt:

1. Die „künstliche Netzhaut" (Das intelligente Auge)

Das Team hat ein System entwickelt, das sie „künstliche Netzhaut" nennen. Stellen Sie sich dies wie ein riesiges, hochtechnisches Sicherheitsgitter vor.

• Das Gitter: Stellen Sie sich ein Schachbrett vor, bei dem jedes Feld ein winziger, unabhängiger Arbeiter ist.
• Die Aufgabe: Jeder Arbeiter ist einem bestimmten „Muster" einer Teilchenbahn (einer Spur) zugewiesen.
• Der Prozess: Wenn ein Teilchen einen Sensor trifft, sendet es ein Signal (ein „Hit"). Das System sucht nicht nur nach einem Muster; es prüft, ob dieser Hit viele verschiedene Muster gleichzeitig passt.
• Das Ergebnis: Wenn ein Hit gut zu einem Muster passt, wird dieser Arbeiter „erregt" (wie eine Glühbirne, die angeht). Wenn genug Arbeiter für ein bestimmtes Muster erregt werden, sagt das System: „Aha! Wir haben eine Spur gefunden!"

2. Das Verkehrssystem (Das Verteilnetzwerk)

Der schwierigste Teil ist es, die Daten von den Sensoren zu den richtigen Arbeitern zu bringen.

• Das Problem: Ein Teilchen-Hit könnte zu mehreren verschiedenen Mustern passen, was bedeutet, dass er kopiert und an mehrere Arbeiter gesendet werden muss. Dies erzeugt einen Stau.
• Die Lösung: Das Team hat ein maßgeschneidertes „Autobahnsystem" aus Glasfaserkabeln (datenübertragung mit Lichtgeschwindigkeit) gebaut. Sie entwarfen eine intelligente Sortiermaschine (einen Switch), die den Verkehr organisiert.
• Die Optimierung: Anstatt Daten zufällig zu senden, ordneten sie die Arbeiter so an, dass ähnliche Muster gruppiert sind. Das ist wie das Organisieren einer Bibliothek, bei der Bücher zum selben Thema im selben Regal stehen, was es viel schneller macht, das Gefundene zu finden. Dies verhinderte, dass das System verstopfte.

3. Die Testfahrt (Der Demonstrator)

Das Team baute einen Prototyp (einen „Demonstrator"), um diese Idee zu testen.

• Das Setup: Sie verwendeten 8 leistungsstarke Computerplatinen, die über Glasfaserkabel verbunden waren und alle in ein einziges Server-Rack passten.
• Das Ziel: Sie konzentrierten sich auf einen bestimmten Teil des Detektors, den VELO (Vertex Locator), der wie die „Vordertür" des Experiments ist, wo die Kollisionen zuerst stattfinden. Sie deckten etwa 1/4 dieses Bereichs ab.
• Die Simulation: Zuerst speisten sie das System mit gefälschten Daten, die echte LHC-Kollisionen nachahmen. Das System lief 10 Tage lang ohne Absturz und verarbeitete Daten mit einer Rate von 19 Millionen Ereignissen pro Sekunde. Das ist unglaublich schnell! (Das Ziel sind 30 Millionen, aber sie sind sehr nah dran).

4. Der Realwelt-Test (Live-Daten)

Der eigentliche Test bestand darin, das System mit Live-Daten zu betreiben, während der LHC tatsächlich physikalische Experimente durchführte.

• Die Herausforderung: Reale Daten sind unordentlich und ändern sich ständig. Das System musste auch die aktuellsten „Ausrichtungs-Konstanten" (denken Sie daran als die neuesten Kartenkoordinaten) verwenden, um genau zu wissen, wo sich die Sensoren befinden.
• Das Ergebnis: Sie bauten eine spezielle Brücke, um Live-Daten vom Überwachungssystem des Experiments in ihren Prototyp zu leiten. Das System lief während der echten Physik-Läufe im Juli und September reibungslos.
• Das Ergebnis: Die Spuren, die der Prototyp fand, sahen genau so aus wie die Spuren, die von der Standard-, langsameren Software gefunden wurden. Es bewies, dass das System in der realen Welt funktioniert, ohne etwas zu beschädigen.

Das Fazit

Diese Arbeit zeigt, dass eine neue Art von Hardware (FPGAs), die in einem „Netzhaut"-Muster angeordnet ist, als superschneller Filter für Teilchenphysik-Daten fungieren kann. Sie verarbeitete erfolgreich Echtzeitdaten vom LHC und bewältigte Millionen von Kollisionen pro Sekunde, ohne überfordert zu werden.

Das Team kommt zu dem Schluss, dass diese Technologie bereit für das nächste große Upgrade des LHC (Run 4) ist. Indem sie diese schwere Arbeit auf diese schnellen Chips verlagern, können sie die Leistung der Hauptcomputer für andere Aufgaben sparen und ermöglichen dem Experiment, in Zukunft noch mehr Kollisionen zu bewältigen.

Technische Zusammenfassung

Technische Zusammenfassung: Ein Echtzeit-Demonstrator für die Spur-Rekonstruktion mit FPGAs am LHCb

Problemstellung
Experimente der Hochenergiephysik (HEP) sehen sich zunehmend Herausforderungen im Datenfluss und in der Komplexität gegenüber, während das Mooresche Gesetz Anzeichen einer Verlangsamung zeigt. Das LHCb-Experiment benötigt, insbesondere für seinen Run 3 und das zukünftige „Upgrade II" (das die Luminosität um einen Faktor von 5 bis 10 erhöhen wird), fortschrittliche heterogene Rechenarchitekturen, um die Echtzeit-Datenverarbeitung bei der vollen LHC-Kollisionsrate (30 MHz) zu bewältigen. Herkömmliche auf CPU/GPU basierende High-Level-Triggers (HLT) könnten mit dem schieren Datenvolumen und dem Bedarf an latenzfreier Verarbeitung ohne Zeitmultiplexing oder übermäßige Pufferung Schwierigkeiten haben. Die Herausforderung besteht darin, eine skalierbare, parallele Verarbeitungslösung zu entwickeln, die in der Lage ist, Spuren in Echtzeit direkt aus der Detektor-Auslesung zu rekonstruieren.

Methodik
Die Autoren präsentieren einen Demonstrator, der auf der „Artificial Retina" (Retina)-Architektur basiert, einem hochparallelisierten, benutzerdefinierten Spur-Verarbeitungsprozessor, der auf Field-Programmable Gate Arrays (FPGAs) implementiert ist.

• Algorithmischer Ansatz: Die Retina-Architektur diskretisiert den Spur-Parameterraum in eine Matrix von Zellen ($M \times N$). Jede Zelle repräsentiert eine Referenzspur und enthält eine Recheneinheit, die ein „Erregungsniveau" basierend auf der Kompatibilität eingehender Detektor-Hits mit dieser Referenzspur berechnet. Dies imitiert eine Hough-Transformation. Hits tragen mit einem Gewicht, das durch ihren Abstand vom „Rezeptor" der Spur (Schnittpunkt mit der Detektorschicht) bestimmt wird, unter Verwendung einer Gauß-Verteilung zum Akkumulator bei. Lokale Maxima in der Erregungskarte werden von Spur-Verarbeitungseinheiten (TPUs) identifiziert, um Kandidaten-Parameter für Spuren zu schätzen.
• Hardware-Implementierung: Der Demonstrator nutzt acht PCIe-hosted Stratix 10 FPGA-Boards (Bittware 520N), die in einem einzelnen Server untergebracht und über ein schnelles optisches Netzwerk miteinander verbunden sind. Das System ist in die LHCb-Coprocessor-Testbed-Einrichtung integriert, was es ermöglicht, während physikalischer Runs opportunistisch Live-Daten zu verarbeiten, ohne das Standard-Datenerfassungssystem (DAQ) zu beeinträchtigen.
• Verteilungsnetzwerk: Ein Kernbestandteil ist das benutzerdefinierte Verteilungsnetzwerk, das aus modularen Splittern (2s), Mergern (2m) und Dispatchern (2d, 4d, 8d) aufgebaut ist. Dieses Netzwerk leitet Hits vom DAQ-Ausleseweg zu den relevanten FPGA-Zellen weiter. Um Netzwerkkongestionen durch Hit-Multiplikation (wobei ein Hit zu mehreren Spuren beitragen kann) zu verhindern, implementierten die Autoren eine Optimierungsstrategie. Diese beinhaltet das Anordnen der TPUs, um jene mit den häufigsten Hits zu paaren, wodurch die Hit-Duplizierung zu den Schichten in der Nähe der TPUs verzögert wird. Zudem wurde der Post-Switch auf eine 8x16-Dispatcher-Konfiguration modifiziert, um die Leitungsbelegung zu begrenzen.
• Datenverarbeitung: Das System wurde in zwei Modi getestet:
  1. Simulierte Daten: Ereignisse, die bei der nominalen Run-3-Luminosität ($2 \times 10^{33} \text{ cm}^{-2}\text{s}^{-1}$) generiert wurden, wurden in interne RAMs geladen.
  2. Live-Daten: Eine benutzerdefinierte Datenkette wurde entwickelt, um echte LHCb-Kollisionsdaten vom Monitoring-Farm zum Demonstrator zu leiten. Diese Kette umfasste einen „AlignmentChecker", um Echtzeit-Ausrichtungskonstanten aus der Condition-Database abzurufen, sowie einen „DecodeTransform", um lokale Sensor-Koordinaten in das globale LHCb-System umzuwandeln.

Hauptbeiträge

• Prototyp-Demonstrator: Bau eines beträchtlichen Demonstrators, der 16 der 38 VELO-Module (Vertex LOcator) abdeckt (insbesondere das rechte, stromabwärts gelegene Quadrant), was einen signifikanten Teil des tatsächlichen Detektors repräsentiert.
• Optimiertes Verteilungsnetzwerk: Entwicklung eines spezifischen Ordnungsalgorithmus für das Switch-Netzwerk, der die Hit-Multiplikationsfaktoren in Zwischenschichten minimiert und den Durchsatz erheblich verbessert.
• Echtzeit-Integration: Erfolgreiche Integration des FPGA-basierten Systems mit der Live-LHCb-DAQ-Umgebung, was die Fähigkeit demonstriert, echte Kollisionsdaten mit aktualisierten Ausrichtungskonstanten in Echtzeit zu verarbeiten.
• Synchronisation: Implementierung eines Mechanismus zur Synchronisation der Spur-Rekonstruktion mit den aktuellsten Detektor-Ausrichtungskonstanten, einer kritischen Anforderung für eine präzise physikalische Analyse.

Ergebnisse

• Durchsatz: Das System erreichte eine Ereignisrate von 19,0 MHz bei der Verarbeitung simulierter Daten mit nominaler Run-3-Luminosität. Dies stellt eine massive Verbesserung gegenüber einer nicht optimierten Switch-Konfiguration dar, die unter denselben Bedingungen nur 170 kHz erzielte.
• Zuverlässigkeit: Das System lief 10 Tage lang ununterbrochen mit simulierten Daten und operierte etwa 60 Tage lang während der Live-Datenerfassung (Mitte Juli und September) reibungslos, ohne abzustürzen oder anomales Verhalten zu zeigen.
• Genauigkeit: Die rekonstruierten Spuren des Demonstrators zeigten eine qualitative Übereinstimmung mit der Standard-LHCb-Software-Rekonstruktion (HLT2) hinsichtlich der zweidimensionalen Verteilung der Spurparameter ($u-v$-Raum). Die Bit-Ebene-Konsistenz wurde durch das regelmäßige Einspeisen simulierter Datenpakete in den Live-Datenstrom bestätigt, was mit dem Output eines C++-Bitweise-Emulators übereinstimmte.
• Einschränkungen: Die erreichte Rate von 19,0 MHz liegt derzeit um einen Faktor von 1,58 unter der Ziel-LHC-Durchschnitts-Strahlkreuzungsrate von 30 MHz. Die Autoren stellen fest, dass die endgültige Selektionslogik (Akzeptanz-Schnitte, Klon-Tötung) in diesem Demonstrator noch nicht implementiert war.

Bedeutung und Behauptungen
Die Arbeit behauptet, dass die Retina-Technologie ein Reifegrad erreicht hat, der für reale Anwendungen in zukünftigen HEP-Experimenten geeignet ist. Die erfolgreiche Demonstration der Verarbeitung von Live-LHCb-Daten mit hohen Raten, kombiniert mit der Identifizierung spezifischer Firmware- und Architekturoptimierungen (wie weitere Erhöhungen der Taktfrequenz und Verbesserungen der Logikketten), legt nahe, dass die Zielrate von 30 MHz mit der aktuellen Hardware-Generation erreichbar ist.

Folglich hat die LHCb-Kollaboration einen Vorschlag an das LHC-Wissenschaftskomitee eingereicht, um eine erste physikalische Anwendung der Retina-Architektur in Run 4 zu implementieren. Diese Anwendung zielt darauf ab, Teile der Spur-Rekonstruktion auf FPGAs zu verlagern, die transparent auf der Ausleseebene operieren, wodurch Rechenleistung für HLT1 eingespart wird. Die Arbeit validiert die Machbarkeit der Verwendung von FPGA-basierten „Artificial Retina"-Architekturen zur Bewältigung der extremen Datenraten, die in zukünftigen Runs mit hoher Luminosität erwartet werden.