MOSAIX Qualification System for ALICE ITS3

Dieses Papier präsentiert die Entwicklungs- und Verifizierungsstrategie des MOSAIX-Qualifizierungssystems, welches eine FPGA-basierte Testinfrastruktur und einen Emulator nutzt, um die Testumgebung für den Wafer-Scale-MAPS-Prototyp zu validieren, der für das ALICE ITS3-Upgrade vor der Chipproduktion vorgesehen ist.

Das Wesentliche

Stellen Sie sich vor, Sie bauen ein riesiges, ultradünnes, selbsttragendes Zelt für ein hochkarätiges Wissenschaftsexperiment. Dieses Zelt namens ITS3 ist darauf ausgelegt, winzige Teilchen zu verfolgen, die durch den Large Hadizer Collider sausen. Um das Zelt so leicht wie möglich zu machen (damit es den Teilchen nicht im Weg steht), verwenden die Erbauer ein revolutionäres neues Material: riesige, flexible Schichten aus Siliziumsensoren.

Der Star der Show ist ein spezieller Chip namens MOSAIX. Er ist nicht nur ein kleiner Sensor; er ist ein „System-on-Chip“, der 266 Millimeter lang ist – im Grunde eine ganze Fabrik aus Sensoren, die auf einem einzigen Stück Silizium zusammengenäht wurde.

Hier liegt das Problem: MOSAIX ist unglaublich komplex. Es ist wie eine Stadt mit 144 verschiedenen Stadtvierteln (genannt „Tiles“), von denen jedes über sein eigenes Stromnetz, Ampeln und Datenautobahnen verfügt. Alle Stadtviertel sind mit einem zentralen Knotenpunkt verbunden. Wenn ein Stadtviertel ein Problem mit der Stromversorgung hat oder die Datenautobahn verstopft ist, kommt die gesamte Stadt zum Stillstand.

Die Herausforderung: Testen vor dem Bau
Normalerweise, wenn Ingenieure eine komplexe Maschine bauen, testen sie zuerst die einzelnen Teile. Aber bei MOSAIX können Sie die Teile nicht separat testen, da sie alle auf einem einzigen riesigen Chip verschmolzen sind. Sie müssen die gesamte Stadt auf einmal testen.

Viel schlimmer noch: Der Chip war noch nicht fertig. Das Team musste die Software schreiben und die Testausrüstung bauen, bevor die eigentlichen Siliziumchips eintrafen. Wenn sie gewartet hätten, bis die Chips ankommen, um mit dem Testen zu beginnen, hätten sie Monate an Zeit verschwendet.

Die Lösung: Der „Digitale Zwilling“ (Der Emulator)
Um dieses Problem zu lösen, baute das Team einen MOSAIX-Emulator. Stellen Sie sich dies als eine hyperrealistische Videospiel-Simulation des Chips vor.

• Das Original: Der tatsächliche MOSAIX-Chip (der noch gar nicht existierte).
• Der Emulator: Ein leistungsstarker Computerchip (ein FPGA), der exakt wie der echte MOSAIX fungiert. Er ahmt die 144 Stadtviertel, die Stromschalter und die Datenautobahnen nach.

Das Team nutzte diesen „Digitalen Zwilling“, um die ganze harte Arbeit vorab zu erledigen:

1. Training: Über 50 Ingenieure lernten, das System am Simulator zu bedienen, Monate bevor der echte Chip ankam.
2. Fehlersuche (Debugging): Sie entdeckten, dass der echte Chip sehr strenge Regeln beim Einschalten hat (man kann nicht einfach einen Hauptschalter umlegen; man muss bestimmte Stadtviertel in einer bestimmten Reihenfolge einschalten). Sie fanden diese kniffligen Regeln am Simulator, was Monate gedauert hätte, wenn sie erst mit dem echten Chip begonnen hätten.
3. Systemprüfung: Sie bauten die physische Testausrüstung (den „Kontrollraum“) und schlossen ihn an den Simulator an, um sicherzustellen, dass alles perfekt zusammenarbeitet.

Das Ergebnis: „Bereitschaft am ersten Tag“
Weil sie den Emulator verwendeten, erreichte das Team etwas, das man „Day-One Readiness“ nennt. Das bedeutet, dass das Team, sobald die ersten echten MOSAIX-Chips eintreffen (erwartet für Anfang 2026), nicht erst Zeit damit verbringen muss, herauszufinden, wie man sie testet. Sie werden in der Lage sein, sofort mit dem Testen zu beginnen.

Zusammenfassend
Das Paper beschreibt, wie die ALICE-Kollaboration ein hochentwickeltes Testsystem für einen riesigen, komplexen Sensorchip gebaut hat. Anstatt zu warten, bis der echte Chip eintrifft, um zu lernen, wie man ihn testet, bauten sie einen perfekten digitalen Zwilling (den Emulator), um an ihm zu üben. Dies ermöglichte es ihnen, Fehler zu finden, ihr Team zu schulen und ihre Werkzeuge im Voraus zu entwickeln, um sicherzustellen, dass sie bereit sind, die Sensoren sofort zu inspizieren, sobald die echte „Stadt“ der Sensoren endlich geliefert wird.

Technische Zusammenfassung

Technische Zusammenfassung: MOSAIX-Qualifizierungssystem für ALICE ITS3

Problemstellung
Das Upgrade des ALICE Inner Tracking System für LHC Run 4 (ITS3) führt eine neuartige Detektorarchitektur ein, die gestitchte, wafer-skalige Monolithic Active Pixel Sensors (MAPS) nutzt, um einen beispiellosen Materialbudget von 0,09 % $X/X_0$ pro Schicht zu erreichen. Die Kernkomponente, MOSAIX, ist ein 266 mm langer, wafer-skaliger System-on-Chip (SoC), der 144 unabhängig versorgte Pixel-Tiles, komplexe Leistungsverteilungsnetzwerke und Hochgeschwindigkeits-Datenaggregation integriert.

Die in dieser Arbeit behandelte primäre Herausforderung ist die Qualifizierung von MOSAIX. Im Gegensatz zu herkömmlichen Sensoren, bei denen Komponenten vorab getestet werden können, bedeutet der hohe Integrationsgrad von MOSAIX, dass einzelne Komponenten (wie die 144 Tiles, 48 Service-Nodes und das gestitchte Backbone) nicht isoliert vor der Integration getestet werden können. Das System erfordert eine komplexe, sequentielle Einschalt- und Steuerungsstrategie, bei der die Funktionalität der gesamten Service-Schicht eine Voraussetzung für den Zugriff auf die einzelnen Pixelmatrizen ist. Darüber hinaus erfordert die Notwendigkeit, die Ausbeute und Leistung zu bestimmen, bevor die Wafer in endgültige Detektorschichten geschnitten werden, eine robuste Testinfrastruktur, die unmittelbar bei Verfügbarkeit des Siliziums einsatzbereit ist („Day-One-Readiness“).

Methodik und Systemarchitektur
Um diese Herausforderungen zu bewältigen, haben die Autoren ein vereinheitlichtes Qualifizierungssystem entwickelt, das einer „Ein System, viele Ziele“-Philosophie folgt. Die Hardware-Architektur besteht aus:

• Control Core: Ein Intel Arria 10 FPGA System-on-Module, montiert auf einem Enclustra Baseboard, das die Steuerung und Datenerfassung übernimmt.
• Interface: Ein standardisierter FMC-Connector auf dem Readout-Board ermöglicht es demselben Kernsystem, mit MOSAIX in verschiedenen Stadien zu interagieren: kundenspezifische Probe Cards für Tests auf Wafer-Ebene, dedizierte Carrier Boards für geschnittene Chips (um spezifische Messungen wie den IR-Drop entlang der z-Achse des Sensors zu ermöglichen) und das finale Qualifizierungsmodell des ITS3-Detektors.
• Software-Stack: Eine hardwareagnostische C++ API abstrahiert die Low-Level-FPGA-Interaktionen. Testsequenzen sind vom Kern-API in einem separaten Repository getrennt, um die Community-Beiträge zu erleichtern und unbeabsichtigte Modifikationen kritischer Abläufe zu verhindern. Die FPGA-Firmware wurde unter Verwendung einer UVM-basierten Umgebung und kontinuierlicher CI-Regressionsprüfung streng verifiziert.

Der MOSAIX-Emulator
Ein zentraler methodischer Beitrag ist die Entwicklung eines hochpräzisen, FPGA-basierten MOSAIX-Emulators. Dieser wurde über ein Jahr vor dem MOSAIX-Tapeout entwickelt und adressiert das Risiko verzögerter Entdeckung von Integrationsproblemen.

• Implementierung: Der Emulator basiert auf einer identischen Arria 10 Plattform und verbindet sich direkt mit dem Backend des Testsystems. Er verwendet echte RTL-Kopien für die Steuerungs- und Datenpfadlogik, während für den Auslesevorgang der Pixelmatrix leichtgewichtige Verhaltensmodelle eingesetzt werden.
• Funktionalität: Entscheidend ist, dass der Emulator leistungs- und zustandsbewusste Modellierungen enthält. Er erzwingt korrekte Betriebssequenzen (z. B. die Verweigerung von Befehlen an Tiles mit „Off“-Leistungsschaltern), wodurch die Steuerungssoftware gezwungen wird, die komplexen Abhängigkeiten des echten Chips zu verwalten.
• Entwicklungsablauf: Ein halbautomatisierter CI-Flow steuerte die „Moving Target“-Natur des MOSAIX-RTL-Designs, indem er SystemRDL- und RTL-Updates in FPGA-Formate mit Debug-Funktionen umwandelte, um sicherzustellen, dass der Emulator mit der neuesten Dokumentation synchron bleibt.

Wesentliche Beiträge und Ergebnisse
Die Arbeit präsentiert die abgeschlossene Basisinfrastruktur für die MOSAIX-Qualifizierungskampagne. Die wichtigsten Ergebnisse sind:

1. Validierte Infrastruktur: Die Hardware, die Firmware und die Kern-Software-API wurden vollständig gegen den FPGA-Emulator getestet und validiert. Primäre Testsequenzen sind auf dem vollständigen Setup operabel.
2. Frühzeitige Integrationsverifizierung: Der Emulator diente erfolgreich als Echtzeit-Anwendungsumgebung und deckte operative Komplexitäten auf (wie die strikte Abhängigkeit der Service-Schicht von der Aktivierung der globalen digitalen Versorgung), die bei einer Entdeckung erst nach der Silizium-Lieferung signifikante Verzögerungen verursacht hätten.
3. Training und Bereitschaft: Der Emulator fungierte als Trainingswerkzeug, das es über 50 Nutzern ermöglichte, Monate vor der physischen Ankunft des Chips praktische Erfahrungen mit dem Chip zu sammeln.
4. Strategische Ausrichtung: Das System ist darauf ausgelegt, die spezifischen Qualifizierungsziele zu unterstützen: Verifizierung von Chip-Features, Schätzung der Produktionsausbeute, Identifizierung einer lebensfähigen Pixel-Variante und Qualifizierung der acht 10 Gb/s Hochgeschwindigkeitsverbindungen, um die Dicing-Strategien zu informieren.

Bedeutung
Die Arbeit betont, dass die primäre Bedeutung dieser Arbeit in dem Wert der durch den hochpräzisen Emulator ermöglichten frühen Systemintegration liegt. Durch die Entkopplung der Entwicklung der Testinfrastruktur von der Verfügbarkeit des physischen Siliziums hat die Kollaboration die Risiken im Zusammenhang mit der operationalen Komplexität des Chips und dem erforderlichen Softwareentwicklungsaufwand effektiv gemindert.

Da die ersten MOSAIX-Wafer für Anfang 2026 erwartet werden, ist das Qualifizierungssystem positioniert, um die Charakterisierungskampagne sofort zu beginnen. Diese „Day-One-Readiness“ ist entscheidend, um notwendiges Design-Feedback bis Mitte 2026 zu liefern und sicherzustellen, dass das ALICE ITS3-Upgrade im Zeitplan bleibt. Die Arbeit kommt zu dem Schluss, dass der Emulator-Ansatz essenziell war, um die komplexen Abhängigkeiten zwischen den Subsystemen des Chips zu verwalten und die Teststrategie zu validieren, bevor der endgültige Prototyp verfügbar war.