A Comparative Analysis of the CERN ATLAS ITk MOPS Readout: A Feasibility Study on Production and Development Setups

Dit artikel introduceert een gestructureerde testomgeving en verificatiemethodologie om de prestaties van de MOPS-lezing voor de ATLAS ITk te vergelijken tussen een Raspberry Pi-basismodel en de definitieve FPGA-productie-opzet, met als doel de geschiktheid voor de High-Luminosity LHC-upgrade te waarborgen.

De kern

De Grote Opdracht: De ATLAS Detector voor de Toekomst

Stel je voor dat de Large Hadron Collider (LHC) bij CERN een enorme, supersnelle auto is die deeltjes tegen elkaar laat botsen. De ATLAS-detector is als het oog van deze auto; het moet alles zien wat er gebeurt. Maar de komende jaren gaat deze auto nog sneller rijden (de "High-Luminosity" upgrade). Dat betekent meer botsingen, meer straling en een enorme hoeveelheid data.

Het huidige "oog" (de Inner Detector) is te oud en te kwetsbaar voor deze nieuwe snelheid. Daarom bouwen ze een nieuw, supersterk oog: de ITk (Inner Tracker).

Het Probleem: De Nerveuze Koerier

In dit nieuwe oog zitten duizenden kleine sensoren (pixelmodules) die temperatuur en spanning meten. Deze sensoren moeten hun gegevens sturen naar een centrale computer in de controlekamer.

• De Boodschapper (MOPS): Dit is het systeem dat de gegevens verzamelt. Het werkt via een speciale telefoonlijn (een CAN-bus) die bestand is tegen straling.
• Het Dilemma: Er zijn twee ontwerpen voor de "centrale post" die deze gegevens ontvangt:
  1. De "Mock-up" (Het prototype): Dit werkt met een Raspberry Pi (een kleine, goedkope computer die vaak voor hobbyprojecten wordt gebruikt). Het is als een vrijwilliger die post bezorgt. Hij is handig en goedkoop, maar hij moet alles één voor één doen. Als er te veel post tegelijk binnenkomt, raakt hij in paniek, vergeet hij brieven of wordt hij traag.
  2. De "MH" (De definitieve versie): Dit werkt met een FPGA (een geavanceerde chip die je kunt programmeren). Dit is als een super-efficiënte robot. Hij kan duizenden brieven tegelijk sorteren, zonder ooit te vergeten of te vertragen.

De Uitdaging: Hoe weten we wie de beste is?

De wetenschappers willen niet zomaar hopen dat de robot (FPGA) beter is. Ze moeten het bewijzen met cijfers. Maar hoe meet je precies hoe snel een systeem is zonder zelf de meting te verstoren?

• Het probleem met gewone meetapparatuur: Als je een gewone laptop gebruikt om de snelheid te meten, is de laptop zelf vaak traag of onvoorspelbaar (net als een drukke postbode die zelf ook nog koffie moet halen). Dat maakt de meting onbetrouwbaar.
• De oplossing: Ze hebben een speciale testbank gebouwd. Denk hierbij aan een stopwatch die door één persoon wordt bediend, in plaats van twee mensen die tegen elkaar praten. Deze testbank gebruikt één krachtige microchip (een STM32) die alles tegelijk meet met microseconde-nauwkeurigheid. Zo weten ze precies hoe lang het duurt van "bericht verzonden" tot "bericht ontvangen".

De Drie Tests (Het Examen)

Om te zien of de robot (MH) klaar is voor de echte wereld, moeten ze drie specifieke tests doen:

1. De Rusttest (Baseline):

   • Wat: Stuur maar één berichtje.
   • Doel: Kijk hoe snel en soepel het systeem reageert als er niets anders gebeurt.
   • Verwachting: De robot moet razendsnel zijn. De Raspberry Pi is ook snel, maar misschien niet altijd even snel.

2. De Stress-test (Full Crate):

   • Wat: Stuur duizenden berichten tegelijk, 8 uur lang.
   • Doel: Dit is als een rushuur op het treinstation. Zakt de robot onder de druk? Verliest hij brieven? Wordt hij traag na een paar uur?
   • Verwachting: De Raspberry Pi (de vrijwilliger) zal waarschijnlijk vastlopen of brieven verliezen omdat hij niet kan multitasken. De FPGA (de robot) moet de druk volhouden zonder te zweten.

3. De Isolatie-test (CIC):

   • Wat: Stuur berichten door kanaal A en kijk of kanaal B ook iets hoort.
   • Doel: Zorgen dat de verschillende lijnen niet met elkaar "kletsen" (geen storingen).
   • Verwachting: Kanaal B moet volledig stil blijven. Als er geluid is, betekent dit dat de elektrische isolatie faalt, wat gevaarlijk kan zijn voor de gevoelige apparatuur.

Waarom is dit belangrijk?

Dit artikel is geen verslag van de resultaten zelf, maar het plan voor hoe ze die resultaten gaan halen.

• De boodschap: Je kunt niet zomaar een hobby-computer (Raspberry Pi) gebruiken voor een kritiek systeem in een stralingsomgeving. Je hebt een professionele, parallelle oplossing (FPGA) nodig.
• Het doel: Met deze strikte testmethode kunnen ze met zekerheid zeggen: "Ja, de nieuwe robot is klaar om de ATLAS-detector veilig te houden." Als ze dit niet doen, zou de hele detector in het donker kunnen vallen als er iets misgaat.

Kort samengevat:
De auteurs hebben een perfecte meetmethode bedacht om te bewijzen dat hun nieuwe, dure robot (FPGA) veel betrouwbaarder is dan hun oude, goedkope prototype (Raspberry Pi). Ze bouwen een speciale testbank om dit te bewijzen, zodat ze in de toekomst geen fouten maken in het grootste wetenschappelijke experiment ter wereld.

Technische samenvatting

Titel

Een vergelijkende analyse van de CERN ATLAS ITk MOPS-uitlezing: Een haalbaarheidsstudie voor productie- en ontwikkelomgevingen.

1. Het Probleem

De Large Hadron Collider (LHC) ondergaat een grote upgrade naar de High-Luminosity (HL-LHC) fase. Hierdoor moet de huidige ATLAS Inner Detector worden vervangen door een nieuwe, volledig op silicium gebaseerde Inner Tracker (ITk). Dit stelt strenge eisen aan het Detector Control System (DCS), dat verantwoordelijk is voor bewaking, besturing en veiligheid.

Een kritiek sub-systeem is de Monitoring of Pixel System (MOPS), die lokale spanningen en temperaturen van de pixelmodules bewaakt via een speciaal ASIC. De data wordt verzonden via een aangepaste 1,2V CAN-bus (Controller Area Network) om stralingshardheid te garanderen (standaard 5V CAN-bussen zijn niet geschikt voor de dunne gate-oxides van de nieuwe MOS-transistors).

De uitdaging ligt in de validatie van de uitleesarchitectuur. Er zijn twee benaderingen ontwikkeld:

1. MH Mock-up: Een prototype gebaseerd op een Raspberry Pi (Linux OS), bedoeld als tussenoplossing voor vroege validatie.
2. MH (MOPS-Hub): De definitieve productieoplossing gebaseerd op een FPGA (Field-Programmable Gate Array) voor deterministische prestaties.

Het probleem is dat standaard meettools (zoals USB-CAN-adapters op PC's) niet geschikt zijn om de sub-millisecond latentie en jitter van deze systemen nauwkeurig te meten vanwege de niet-deterministische aard van USB-protocollen en besturingssystemen zoals Linux. Er is een rigoureuze, reproduceerbare methodologie nodig om te bewijzen dat de FPGA-architectuur voldoet aan de eisen voor de productie, terwijl de beperkingen van de Raspberry Pi-prototype worden aangetoond.

2. Methodologie

De auteurs presenteren een dedicated testbed en een verificatiemethodologie om de prestaties van beide systemen objectief te vergelijken.

• Testbed-ontwerp ("Readout Hub"):

  • Om meetfouten door externe hardware te elimineren, is een testbed gebouwd rondom een STM32F767ZIT6 microcontroller (ARM Cortex-M7).
  • Deze microcontroller fungeert als een "single-clock" bron voor alle tijdstempels, wat relatieve timingfouten uitsluit.
  • Het systeem monitort niet-invasief de 1,2V CAN-bus en de UART-debug-poort van het apparaat onder test (DUT).
  • Het meet de tijd tussen het ontvangen van een CAN-bericht ($t_1$) en het verwerken/uitgeven ervan door de controller ($t_2$), waardoor de end-to-end latentie ($\Delta t = t_2 - t_1$) en jitter nauwkeurig worden bepaald.

• Drie-staps Evaluatieplan:

  1. Baseline Performance: Eén kanaal, één node. Meting van gemiddelde latentie en jitter onder ideale omstandigheden. Doel: < 7 ms (inclusief veiligheidsmarge).
  2. Full Crate Stress Test: Maximale belasting (8 CIC's, 64 nodes). Een "soak test" van 8 uur om stabiliteit, geheugenlekken en prestatiedegrade onder continue piekbelasting te detecteren. Doel: Geen pakketverlies en 99,9e percentiel < 7 ms.
  3. CIC Isolation Test: Verificatie van de elektrische isolatie tussen kanalen A en B van een CIC-module. Een kanaal wordt belast met 200 Hz, terwijl het andere wordt gemonitord op kruispraat (crosstalk).

3. Belangrijkste Bijdragen

• Gedetailleerde Testinfrastructuur: Ontwikkeling van een microcontroller-gebaseerde testset-up die sub-millisecond latentie en jitter kan meten over de 1,2V CAN-naar-UART-paad, wat standaard PC-tools niet kunnen.
• Gestructureerde Validatie: Een drie-fasen testplan dat niet alleen snelheid meet, maar ook schaalbaarheid, langetermijnstabiliteit en hardware-isolatie (veiligheid).
• Data-analyse Pijplijn: Een geautomatiseerde Python-pijplijn voor het loggen, verwerken en visualiseren van ruwe timing-data, wat leidt tot kwantitatieve acceptatiecriteria.
• Vergelijkende Analyse: Een duidelijke definitie van de prestatieverschillen tussen een software-gedreven prototype (Raspberry Pi) en een hardware-gedreven productie-oplossing (FPGA).

4. Verwachte Resultaten

Hoewel de paper de methodologie beschrijft en de verwachte resultaten schetst (de daadwerkelijke experimentele data wordt in een companion paper gepresenteerd), zijn de voorspellingen als volgt:

• MH Mock-up (Raspberry Pi): Verwacht wordt dat dit systeem faalt bij hoge belastingen. De afhankelijkheid van software-context switching (multiplexing) en de niet-deterministische Linux-scheduler zullen leiden tot pakketverlies en hoge jitter wanneer meerdere CAN-bussen tegelijk worden afgehandeld. Het wordt geacht ongeschikt te zijn voor de definitieve productie.
• MH (FPGA): De FPGA-architectuur zal superieure prestaties tonen dankzij parallelle verwerking. De latentie wordt beperkt door de fysieke snelheid van de CAN-bus (theoretisch minimum ~2,2 ms voor een round-trip) en niet door verwerkingstijd.
  • Verwacht wordt nul pakketverlies zelfs onder maximale belasting (64 nodes).
  • De latentie zal deterministisch zijn met zeer lage jitter.
  • De isolatietests zullen aantonen dat de CIC-modules voldoen aan de strikte elektrische eisen voor het voorkomen van aardlussen en ruis.

5. Betekenis en Conclusie

De betekenis van dit werk ligt in het bieden van een kwantitatief en reproduceerbaar bewijs om de FPGA-gebaseerde MOPS-Hub te kwalificeren voor productie in de ATLAS ITk DCS.

• Overgang naar Productie: Het paper definieert de cruciale tussenstap tussen componentkwaliteitscontrole en volledige systeemcommissie.
• Veiligheid en Betrouwbaarheid: Door de methodologie toe te passen, wordt gegarandeerd dat het uiteindelijke systeem voldoet aan de strenge eisen van de HL-LHC-omgeving, inclusief stralingshardheid en data-integriteit.
• Toekomst: De succesvolle uitvoering van deze tests vormt de basis voor de integratie met de bredere CERN DCS-infrastructuur (via OPC UA) en de uiteindelijke installatie in de ATLAS-cave.

Kortom, dit paper legt de technische grondslag voor het bewijzen dat de FPGA-oplossing de enige geschikte keuze is voor de robuuste, schaalbare en deterministische data-uitlees van de toekomstige ATLAS ITk-detector.