Das Versprechen der Chiplets und das Integrationsproblem

Wird ein Prozessor in mehrere Dies aufgeteilt, lassen sich unterschiedliche Funktionen verschiedenen Siliziumblöcken zuweisen und potenziell Fertigungsprozesse kombinieren. Diese Modularität kann verhindern, dass ein gesamtes Design von einem einzigen großen Die abhängt. Sie beseitigt jedoch nicht den Integrationsaufwand: Chiplets müssen innerhalb des Packages unter strengen Leistungs-, Platz- und Signalgrenzen miteinander kommunizieren. Der Standard UCIe – Universal Chiplet Interconnect Express – soll eine gemeinsame Grundlage für diese Die-to-Die-Kommunikation und für einige zugehörige Protokolle und Funktionen bereitstellen. Für sich genommen ist er weder ein Prozessordesign noch ein universelles Package-Format oder eine Garantie dafür, dass zwei Komponenten verschiedener Anbieter ohne Anpassung zusammenarbeiten.

Diese Unterscheidung ist wichtig, wenn ein modulares Design bewertet wird: „Chiplets verwenden“ beschreibt eine Architektur; „UCIe verwenden“ beschreibt eine Schnittstelle nach einer konkreten Spezifikation. Selbst bei einer gemeinsamen Schnittstelle müssen Unternehmen die physische Implementierung, Signalverteilung, Stromversorgung, Wärmemanagement und Teststrategie festlegen. Die Kombination unterschiedlicher Prozesse oder Anbieter kann Flexibilität schaffen, bringt aber zusätzliche Design- und Validierungsarbeit mit sich. Kostensenkungen oder Leistungsverbesserungen sind deshalb als vom Einzelfall abhängige Möglichkeiten zu betrachten, nicht als automatische Folge der Standardnutzung. UCIe liefert einen gemeinsamen Baustein des Systems, ersetzt aber keine Prüfung der Umsetzbarkeit des gesamten Packages.

Was UCIe definiert: Schnittstelle, Protokolle und Verwaltung

Das Konsortium beschreibt UCIe als Interconnect-Spezifikation auf Package-Ebene, die eine physische Die-to-Die-I/O-Schicht, Die-to-Die-Protokolle und einen Software-Stack umfasst, der PCI Express und Compute Express Link nutzt. Praktisch soll die Spezifikation Teams dabei helfen, sich auf Verbindungs- und Transportdetails zu einigen, statt jede Verbindung zwischen Dies von Grund auf neu zu entwickeln. Version 1.1 ergänzte unter anderem Zuverlässigkeitsmechanismen und Architekturattribute zur Unterstützung von Test- und Konformitätsplänen. Version 2.0 führte eine standardisierte Verwaltungsarchitektur sowie Funktionen für Tests, Debugging und Telemetrie über den Lebenszyklus eines Systems im Package ein.

Diese Funktionen sind jedoch keine vollständige Verwaltungs- oder Sicherheitslösung für jedes Produkt: Das Design muss sie integrieren und festlegen, welche Daten erfasst werden, wie der Zugriff kontrolliert wird und wie das System bei Fehlern reagiert. Die entscheidende Abgrenzung besteht darin, zu unterscheiden, was die gemeinsame Schnittstelle definiert und was in der Verantwortung des Produkts bleibt: Richtlinien, Firmware, die Speicher-Kohärenz des Systems, Ende-zu-Ende-Sicherheit und das Verhalten von Anwendungen werden durch eine UCIe-Verbindung nicht automatisch gelöst. Die öffentliche Dokumentation der Organisation gibt den Umfang der Spezifikation an; für die Produktimplementierung müssen Teams die einschlägige Revision einsehen sowie Rechte an geistigem Eigentum und entsprechende Bedingungen prüfen.

Versionen und Datenraten: Was UCIe 3.0 bringt

UCIe 3.0 wurde am 5. August 2025 angekündigt. Laut Konsortium unterstützt die Version Raten von 48 und 64 GT/s, gegenüber maximal 32 GT/s bei UCIe 2.0, und umfasst Änderungen an der Architektur. Die Spezifikationsseite hebt einen Seitenkanal mit einer möglichen Länge von 100 mm, kontinuierliche Übertragung mithilfe von Mappings für Raw Mode, einen vorgezogenen Firmware-Download über das Management Transport Protocol, priorisierte Seitenbandsignalisierung und Energiesparmechanismen einschließlich einer Neukalibrierung während des Betriebs hervor. Diese Angaben beschreiben Fähigkeiten der Revision, nicht die Leistung eines fertigen Produkts: Effektive Bandbreite und Stromverbrauch hängen auch von der Implementierung und dem physischen System ab.

Die Bezeichnungen UCIe-S und UCIe-A unterscheiden Klassen für unterschiedliche Package-Konfigurationen; UCIe 3.0 nennt für beide Raten von 48/64 GT/s. UCIe 2.0 umfasst außerdem UCIe-3D für dreidimensionales Packaging und Hybrid Bonding. Diese Bezeichnungen sollten nicht auf einen simplen Gegensatz zwischen „langsam und günstig“ und „schnell und teuer“ reduziert werden: Die Wahl hängt von Designregeln, Materialien, Geometrie, Fertigungsverfügbarkeit und Produktzielen ab. Die öffentlichen Informationen des Konsortiums reichen aus, um die Fähigkeiten der Spezifikation zu erkennen, aber nicht, um abzuleiten, welche Rate eine bestimmte Kombination aus Dies und Package erreicht. Dafür ist eine Validierung der tatsächlichen Implementierung nötig, keine Extrapolation aus dem Versionsnamen.

Interoperabilität: Eine Spezifikation ist keine Gesamtzertifizierung

Praktische Kompatibilität umfasst mehrere Ebenen. Zwei Implementierungen müssen der Revision und den gemeinsamen Optionen entsprechen, für die sie sich entschieden haben; außerdem müssen Package, PHYs, Kanäle und Testwerkzeuge zur konkreten Konfiguration passen. Auch die Funktionen, die jedes Chiplet oberhalb der Verbindung anbietet, müssen abgestimmt werden. Die Ankündigung von UCIe-IP durch zwei Anbieter reicht daher nicht aus, um sicherzustellen, dass sich beliebige Produkte dieser Anbieter direkt verbinden lassen: Version, aktivierte Protokolle, Package, Lane-Konfiguration oder Signalanforderungen können voneinander abweichen. Der Standard verringert die Zahl der Vereinbarungen, die neu entwickelt werden müssen, beseitigt aber weder Kompatibilitätsmatrizen noch gemeinsame Tests.

Es gibt öffentliche Belege für die Integration zwischen Organisationen: Intel berichtete 2023 über den Testchip Pike Creek, der ein Chiplet mit in Intel 3 gefertigter UCIe-IP und ein weiteres mit in TSMC N3E gefertigter Synopsys-IP kombinierte; verbunden waren sie über EMIB. Das ist eine nützliche Demonstration einer konkreten Kombination, aber kein Beweis für die Interoperabilität jeder Verbindung aus Anbietern, Prozessen und Packages. Das Konsortium veröffentlicht Konformitätsmaterialien und beschreibt Testattribute in seinen Spezifikationen. Die ausgewerteten Informationen erlauben jedoch nicht die Behauptung, es gebe ein universelles öffentliches Register, das vollständige Produkte für alle Szenarien als interoperabel zertifiziert. Bei einer Kaufentscheidung sollten Testergebnisse und genaue Bedingungen angefordert werden: Revision, PHY, Protokolle, Prozess, Package, Temperatur und gemessene Signalgrenzen.

Ökosystem und Produkte: offener Standard, unterschiedliche Implementierungen

Die Einführung kann unterschiedliche Formen annehmen. Foundries, IP-Anbieter, Designunternehmen und Package-Hersteller können UCIe in bestimmten Teilen ihres Angebots einsetzen; daraus folgt nicht, dass sie alle ein Chiplet anbieten, das sich mit jedem beliebigen anderen kombinieren lässt. Die öffentliche Mitgliederliste und Ankündigungen des Konsortiums zeigen die Beteiligung der Industrie. Die kommerzielle Verfügbarkeit muss jedoch nach Fertigungsknoten, Prozess, Package und Zeitplan geprüft werden. Auch Integrationstechnologien wie EMIB oder SoIC bezeichnen Packaging-Ansätze und sind keine Synonyme für UCIe: Eine Lösung kann eine physische Packaging-Technologie mit einer Chiplet-Schnittstelle kombinieren; jede angekündigte Kombination muss einzeln überprüft werden.

Ein angekündigtes Produktbeispiel mit UCIe ist AMDs Versal-RF-Serie: Das Unternehmen teilte mit, dass bestimmte Geräte UCIe-1.1-Schnittstellen enthalten sollen und dass es Produktionschiplets im vierten Quartal 2027 erwartet. Dies ist eine Ankündigung mit einem Zeitpunkt in der Zukunft, bezogen auf diesen Artikel; sie darf weder als bereits verfügbares Produkt noch als Beleg universeller Kompatibilität dargestellt werden. NVIDIA wiederum präsentiert NVLink-C2C als eigene Chip-to-Chip-Verbindung für kohärente Verbindungen mit hoher Bandbreite innerhalb seiner Systeme. Diese Optionen zeigen, dass die Industrie je nach Produkt proprietäre oder offene Schnittstellen sowie Technologiekombinationen nutzen kann. Ohne den Vergleich gleichwertiger Spezifikationen und Messbedingungen lässt sich daraus keine faire Rangfolge der Leistung ableiten.

So lässt sich ein „UCIe-ready“-Design bewerten

Bei der Bewertung eines Vorschlags lautet die erste Frage nicht nur „Ist er UCIe-kompatibel?“, sondern „Mit welcher Revision, welcher PHY-Klasse, welchem Protokoll und welcher konkreten Konfiguration?“ Bitten Sie den Anbieter, die implementierte Revision und optionale Funktionen zu benennen und Einschränkungen der Abwärtskompatibilität zu erläutern. Prüfen Sie anschließend, ob die Implementierung für den Prozess und das Package des Projekts verfügbar ist und ob Kanalmodelle und Designabläufe diese Kombination abdecken. Eine Ankündigung zu IP oder Tool-Unterstützung ist ein Hinweis auf ein Ökosystem, aber weder eine automatische Freigabe des endgültigen Designs noch ein Leistungsversprechen für das Produkt.

Im zweiten Schritt muss Interoperabilität in überprüfbare Nachweise übersetzt werden. Legen Sie für jedes Chiplet eine Matrix der Schnittstellen und Versionen fest; verlangen Sie Verbindungstests mit den vorgesehenen Konfigurationen und Betriebsbedingungen; vereinbaren Sie, wer Fehler diagnostiziert und welche Protokolle verfügbar sind; und nehmen Sie Tests für Signalintegrität, Leistung, Temperatur und Fehlerbehebung auf. Bewerten Sie zuletzt die funktionale Integration separat: UCIe kann die Verbindung erleichtern, stellt aber nicht sicher, dass Blöcke ohne zusätzliche Arbeit Semantik, Kohärenz oder Software teilen. In der Praxis verringert die Spezifikation einen Teil des Integrationsrisikos; sie macht gemeinsame Entwicklungsarbeit nicht überflüssig. Das beste Zeichen für Einsatzbereitschaft ist kein Werbeetikett, sondern eine Dokumentation, die eine konkrete Implementierung mit reproduzierbaren Tests und Abnahmekriterien verknüpft.