Zusammenfassung

  • Die UCIe legt gemeinsame Regeln für die physische Schicht, den Adapter, die Protokolle und das Management der Verbindung zwischen Dies fest; Funktion, Gehäusetechnik und Verantwortung der Anbieter fallen nicht in ihr Mandat
  • Von Version 1.0 bis 3.0 hat der Standard günstigere Gehäuseoptionen, automotives Health-Monitoring, 3D-Unterstützung sowie Verwaltung und Betrieb mit 64 GT/s aufgenommen
  • Sein kommerzieller Wert wird in reproduzierbaren Konformitätsprofilen, Multi-Anbieter-Packages mit echtem Support und klarer Verantwortlichkeit sichtbar, wenn ein gemeinsames System ausfällt

Die 64-GT/s-Version machte das Geschwindigkeitsrennen zu einer Systemfrage

Am 5. August 2025 veröffentlichte ein Standardisierungskonsortium, das öffentlich erst seit etwas mehr als drei Jahren bestand, seine dritte Hauptspezifikation. Die Universal Chiplet Interconnect Express, kurz UCIe, ergänzte 48 und 64 Gigatransfers pro Sekunde für die Kanalklassen der Standard- und der Advanced-Packaging-Umgebung. Die Version erweiterte außerdem die Reichweite des Sideband-Kanals, erweiterte den kontinuierlichen Raw-Verkehr und ergänzte Management-Funktionen. Die Schlagzeile war die Geschwindigkeit.

Die folgenreichere Geschichte war der Versuch, ein Package aus mehreren unabhängig entworfenen Dies wie ein einziges beherrschbares System zu betreiben.

Die Unterscheidung ist wichtig, weil ein schnellerer Datenlink nur ein Teil eines Chiplet-basierten Produkts ist. Der Käufer muss weiterhin wissen, was jedes Die tut, wie viel es verbraucht, wie es gekühlt wird, welche Software es erkennt, wie die Firmware aktualisiert wird, was passiert, wenn eine Komponente ausfällt, und welcher Anbieter die Garantie übernimmt. Die UCIe liefert gemeinsame Regeln, um Informationen zwischen Dies zu bewegen, und für einen Teil der Verwaltungsarbeit rund um diesen Datenfluss. Allein macht sie aus einem Tablett unzusammenhängender Siliziumstücke noch keinen fertigen Prozessor.

Die öffentliche Sprache des Konsortiums verweist auf ein „offenes Chiplet-Ökosystem“. Als Ambition ist der Begriff nützlich, kann aber mit der Beschreibung eines bereits existierenden Marktes verwechselt werden. Die für dieses Profil geprüften öffentlichen Unterlagen boten weder eine vollständige unabhängige Bestandsaufnahme von UCIe-Multi-Anbieter-Packages in Auslieferung, noch eine universelle Liste zertifizierter Produkte oder einen Katalog, in dem ein Entwickler austauschbare Dies auswählen könnte. Sie zeigten Spezifikationen, Mitgliederaktivität, Implementierungsschulungen und Demonstrationen.

Das sind notwendige Schritte, aber kein Beleg für wiederholbare Einkäufe und Produktion.

Die zentrale Frage ist daher enger gefasst als die Frage, ob Chiplets wichtig werden. Sie sind bereits wichtig als Mittel, komplexe Systeme zu partitionieren. Die Frage ist, wie viel Modularität eine gemeinsame Verbindung schaffen kann, wenn das umgebende Package ein eng integriertes Engineering-Objekt bleibt. Die UCIe kann zur gemeinsamen Sprache an der Grenze zwischen Dies werden und dennoch den größten Teil des physischen Systems und der Geschäftsbeziehungen proprietär lassen. Deshalb sollte die Schnittstelle als eine Kette von Übertragungen bewertet werden und nicht als ein einziges Versprechen von Austauschbarkeit.

Das Wort Austauschbarkeit bündelt mehrere verschiedene Tests. Der erste ist elektrischer Natur: Können Sender, Empfänger und der Kanal des Packages unter demselben physikalischen Profil eine Verbindung aufbauen? Der zweite betrifft das Protokoll: Verstehen beide Enden dasselbe PCIe-, CXL- oder Raw-Mapping? Der dritte ist operativ: Kann das Package die Dies über kompatible Management-Funktionen erkennen, testen, überwachen und aktualisieren? Der vierte ist funktional und softwarebezogen: Legt das Chiplet ein Verhalten offen, das Firmware, Treiber und Anwendungen nutzen können?

Der fünfte ist kommerziell: Kann der Käufer das Bauteil mit ausreichend Testnachweisen, Stückzahlen, Support und Garantie beziehen, um es in ein Produkt aufzunehmen?

Die UCIe befasst sich direkt mit den ersten beiden und macht Fortschritte bei der dritten. Sie kann elektrische Aushandlung, Protokolltransport und Management-Übertragungen weniger abhängig von einem privaten bilateralen Design machen. Die vierte Schicht liegt teils in PCIe, CXL und der produktspezifischen Software. Die fünfte gehört zu Anbietern, Foundries, Gehäuseherstellern und Käufern.

Wer die Schichten vermischt, begeht zwei gegensätzliche Fehler. Der eine verwirft den Standard, weil er keinen fertigen Markt schafft, und übersieht den Wert, eine sich wiederholende physische und protokolltechnische Barriere zu beseitigen. Der andere erklärt den Markt für vollständig, weil zwei Dies eine konforme Verbindung aufbauen können, und übersieht alle Entscheidungen, die nötig sind, um diese Verbindung in ein unterstütztes System zu verwandeln.

Eine professionelle Bewertung muss sagen, welches Versprechen belegt wurde. Eine Demonstration der physischen Schnittstelle beweist weniger als ein Protokoll-Pairing. Das Pairing beweist weniger als ein über den gesamten Lebenszyklus verwaltbares Package. Ein verwaltbares Package beweist weniger als eine austauschbare Komponente ohne neue Software oder neue Verträge. Diese Hierarchie ist keine Kritik an der UCIe; sie ist der klarste Weg, zu zeigen, was das Konsortium kontrolliert und was es dem Markt überlässt.

Die Fünf-Schichten-Sicht erklärt auch, warum Fortschritt real sein kann, ohne wie Plug-and-Play-Einkauf auszusehen. Eine neue Version kann die ersten drei Versprechen stärken, während das vierte und fünfte langsam reifen. Der Chiplet-Markt wird nicht mit einer Ankündigung entstehen. Er wird durch eine Abfolge engerer Übertragungen aufgebaut, die wiederholbar genug werden, um Vertrauen zu verdienen.

Chiplets verschieben die Komplexität vom Silizium in die Gehäusetechnik

Ein monolithischer Chip bündelt die Systemfunktionen auf einem großen Stück Silizium. Das kann die interne Kommunikation vereinfachen, zwingt aber alle Funktionen, einem einzigen Fertigungsplan zu folgen. Mit zunehmendem Entwurfs-, Masken- und Ausbeute-Druck bei modernen Knoten wird es teuer und schwierig, jeden Block auf einem großen Die unterzubringen. Chiplets bieten einen anderen Weg: Rechenwerke, Speicher, Ein-/Ausgabe, analoge Funktionen, Sicherheit und Beschleuniger können getrennt, im jeweils geeignetsten Prozess gefertigt und in einem System-in-Package zusammengeführt werden.

Die Partitionierung beseitigt die Komplexität nicht; sie verschiebt einen Teil davon vom Die ins Package. Jede Grenze braucht Signalisierung, Takt, Fehlerbehandlung, Stromversorgung, thermische Planung, Testabdeckung und für Software sichtbares Verhalten. Ein großer monolithischer Die kann mit zunehmender Größe Ausbeute verlieren; ein Multi-Die-Package kann an Wert verlieren, weil eine integrierte Komponente defekt, am Limit oder falsch montiert ist. Der Entwickler gewinnt die Option, Prozessknoten zu kombinieren und Blöcke wiederzuverwenden, akzeptiert aber neue Abhängigkeiten auf Gehäuseebene.

Deshalb ist „modular“ mit Vorsicht zu verwenden. Eine Leiterplatte ist unter anderem deshalb modular, weil die Bauteile standardisierte physische Formen, elektrische Konventionen, erkennbare Funktionen und ausgereifte Handelsbedingungen haben. Anbieter veröffentlichen Datenblätter, Distributoren halten Lagerbestand, und Integratoren verstehen Sockel, Steckverbinder und Fehlergrenzen. Ein Chiplet in einem Advanced Package arbeitet in einer viel engeren Umgebung mit geringerer Fehlertoleranz.

Es kann Energie, Wärme, Verwaltung und Hochgeschwindigkeitskanäle mit dem Nachbarn teilen – ohne die Möglichkeit von Inspektion oder Austausch nach der Montage, wie sie bei einem Leiterplattenbauteil besteht.

Die UCIe befasst sich mit einer der schwierigsten wiederkehrenden Grenzen: der kurzen, dichten Verbindung zwischen Dies. Sie zu standardisieren, kann doppelte Schnittstellenentwürfe reduzieren und Werkzeugen, IP-Anbietern und Systemunternehmen ein gemeinsames Ziel geben. Es lässt die anderen Probleme nicht verschwinden. Der Wert des Standards liegt darin, eine bestimmte Klasse bilateraler Ingenieurarbeit zu reduzieren, nicht darin, das Package in eine lose Sammlung unabhängiger Teile zu verwandeln.

Vor einer gemeinsamen Schnittstelle konnte ein Unternehmen ein System in mehrere Dies aufteilen und weiterhin vertikal integriert bleiben. Die Verbindung konnte nach den elektrischen Annahmen, dem Protokoll, dem Gehäuseprozess und dem Testablauf eines einzigen Anbieters entworfen werden. Das gibt Freiheit, Latenz, Energie und Fläche eines bestimmten Produkts zu optimieren, erschwert aber den Einstieg eines anderen Anbieters, ohne einen privaten Vertrag zu lernen und zu implementieren.

Die Falle ist ebenso wirtschaftlich wie technisch. Ein Unternehmen kann sein Produkt als chipletbasiert bezeichnen, ohne das nützliche Modul Dritten zugänglich zu machen. Wiederverwendung findet zwischen eigenen Generationen statt, während der externe Markt ein geschlossenes Package sieht. Die Architektur ist innerhalb der Unternehmensgrenze modular und außerhalb unteilbar.

Die Gründer der UCIe versuchten, eine gemeinsame Grenze zu schaffen, ohne das gesamte System vorzuschreiben. Das Konsortium definiert das Verhalten der physischen Schicht, einen Adapter und Protokoll-Mappings. Die Anbieter entscheiden weiterhin, was das Chiplet tut, wie das Package gebaut wird und welche Funktionen es offenlegt. Die gemeinsame Schicht muss dünn genug sein, um unterschiedliche Produkte zu ermöglichen, und detailliert genug, damit unabhängige Implementierungen der Verbindung dieselbe Spezifikation erfüllen.

Die Balance ist schwierig. Ein Standard, der wenig spezifiziert, lässt jede Paarung wie eine maßgeschneiderte Integration aussehen; einer, der zu viel spezifiziert, kann Entscheidungen einfrieren, frühe Implementierer bevorzugen oder die Differenzierung verringern. Die schnelle Ausweitung der UCIe – von den Grundlagen der Verbindung und des Protokolls zu Verwaltbarkeit, DFx und 3D – zeigt, dass die ursprüngliche Grenze für ein vollständig betriebsfähiges Package nicht ausreichte. Das Konsortium musste mehr Übertragungen standardisieren, als der Markt entdeckte, wo private Annahmen die Wiederverwendung weiterhin blockierten.

Rivalisierende Unternehmen schufen eine gemeinnützige Organisation um eine bewusst enge Grenze

Die UCIe wurde am 2. März 2022 mit Version 1.0 öffentlich vorgestellt. Die Universal Chiplet Interconnect Express, Inc. wurde am 2. August als gemeinnützige Organisation in Delaware gegründet und eröffnete eine formale Mitgliedschaftsstruktur. Die Gründungsgruppe versammelte Unternehmen aus den Bereichen Prozessoren, Cloud, Foundries, Assembly und Test, Speicher und Beschleuniger. Das aktuelle Material nennt AMD, ASE, Alibaba Cloud, Arm, Google Cloud, Intel, Meta, Microsoft, NVIDIA, Qualcomm, Samsung und TSMC.

Die Breite ist das größte institutionelle Kapital des Konsortiums. Eine Verbindung zwischen Dies wird nicht allein durch das Handeln eines Prozessordesigners nützlich. Foundries brauchen Kanäle und Regeln, die sie fertigen können. Assembly- und Testunternehmen brauchen qualifizierbare Abläufe. EDA- und IP-Anbieter brauchen Spezifikationen, die sich in Controller, PHYs und Verifikationsprodukte umsetzen lassen. Cloud- und Systemunternehmen brauchen Packages, die reale Arbeitslasten erfüllen.

Dieselbe Gruppe vereint widersprüchliche Anreize. Ein Hyperscaler kann wiederverwendbare Blöcke wollen und zugleich die private Architektur bewahren. Eine Foundry kann die gemeinsame Verbindung unterstützen und Design-Kits, Kapazität und Prozesswissen proprietär halten. Ein Prozessorunternehmen kann von mehr Anbietern profitieren und zugleich interne Verbindungen haben, die in ausgewählten Anwendungen überlegen sind. Das Konsortium schafft den Raum, in dem diese Parteien eine Grenze vereinbaren; es macht ihre Interessen nicht identisch.

Deshalb sollte Mitgliedschaft nicht als Beleg für Bereitstellung gelesen werden. Das Promoter-Logo zeigt Teilnahme an Governance und technischer Arbeit. Ein Contributor kann Werkzeuge oder IP liefern. Ein Adopter kann die Spezifikation nur evaluieren. Keine Kategorie für sich beweist, dass ein Produktions-Package unabhängige UCIe-Chiplets verwendet oder dass die Teile kommerziell austauschbar sind. Diese institutionelle Grenze hat nur Wert, wenn der technische Stack mit unterschiedlichen Gehäuseoptionen nutzbar bleibt.

Der derzeitige Vorstand listet Debendra Das Sharma von Intel als Chair, Cheolmin Park von Samsung als President, Dong Wei von Arm als Secretary und Lihong Cao von ASE Group als Treasurer. Weitere Direktoren vertreten Google Cloud, Qualcomm, Alibaba Cloud, Meta, TSMC, AMD und NVIDIA. Das sind Ämter, die über die Mitgliedsorganisationen wahrgenommen werden, kein persönliches Eigentum an der Spezifikation und auch keine alleinige Urheberschaft ihres Inhalts.

Die gemeinnützige Struktur gibt Mitgliedschaft, IP-Vereinbarungen und technischer Arbeit eine rechtliche Grundlage. Die Stufen Promoter, Contributor und Adopter schaffen unterschiedliche Formen der Beteiligung. Öffentliche Evaluierungskopien ermöglichen Außenstehenden, die Architektur kennenzulernen, aber die Bedingungen unterscheiden das Studium von den weiterreichenden Rechten zur Implementierung und Mitgliedschaft. Die Lizenz ist auf die interne Evaluierung beschränkt und stellt die Spezifikation nicht als patentfreies Design der öffentlichen Domäne dar.

Diese Grenze wiegt für kleinere Anbieter schwer. Das öffentliche Dokument senkt die Kosten, Anforderungen zu verstehen, beseitigt aber weder rechtliche Unsicherheit, stellt automatisch Verifikationswerkzeuge bereit, noch finanziert es Hochgeschwindigkeits-Engineering. Ein Startup kann dieselbe Spezifikation lesen wie ein Promoter, ohne dasselbe Patentportfolio, dieselben Gehäusebeziehungen oder dasselbe Validierungsbudget zu haben.

Die UCIe wird von Mitgliedern getragen, aber die für dieses Profil verwendeten öffentlichen Unterlagen enthalten keine geprüften Einnahmen, Rücklagen, Personalzahlen oder Ausgaben nach Generation. Das begrenzt Aussagen über den finanziellen Umfang der Organisation, nicht über den wirtschaftlichen Wert rund um den Standard.

Die teure Arbeit geschieht bei Mitgliedern und Anbietern. Halbleiterunternehmen entwickeln Controller und Dies; Anbieter physischer Schnittstellen bauen wiederverwendbares IP; EDA-Firmen ergänzen Modellierung und Verifikation; Foundries und Montagebetriebe entwickeln Prozesse; Systemunternehmen zahlen für Integration, Qualifizierung und Software. Eine gemeinsame Verbindung reduziert Duplikation, aber die Ersparnis zeigt sich im Produkt, nicht in den Einnahmen des Konsortiums.

Die Mitgliedschaft verteilt auch Rechte und Risiken. Promoter und Contributoren beteiligen sich unter den Vereinbarungen des Konsortiums an der Entwicklung. Der öffentliche Evaluierungszugang zeigt die Spezifikation, während Implementierungsrechte und IP-Schutz von den geltenden Instrumenten abhängen. Das Ergebnis ist eine offene technische Referenz, umgeben von einer Mitgliederökonomie, die auf Implementierung ausgerichtet ist.

Das ist für die Nachhaltigkeit wichtig. Das Konsortium braucht nicht die Einnahmen eines Chip-Herstellers; es braucht fortlaufende Unterstützung, um Spezifikationen zu pflegen, Interpretationen zu klären, Konformität zu entwickeln und die nächste Generation zu koordinieren. Das Risiko ist nicht der gewöhnliche Fehlschlag eines Produkts, sondern die Entscheidung, dass ein proprietärer Weg mehr einbringt oder dass die Qualifizierungskosten schneller wachsen als der Wert der Interoperabilität.

Die Spezifikation nutzt ausgereifte Protokolle wieder und überlässt die Gehäusetechnik den Herstellern

Die erste Spezifikation versuchte nicht, jede höherwertige Transaktion neu zu erfinden. Sie definierte eine physische Verbindung und einen Adapter, die etablierte Familien wie PCI Express und Compute Express Link sowie Raw-Verkehr transportieren können. Damit verband sie eine neue Package-Grenze mit Software- und Gerätemodellen, die Entwickler bereits kannten.

PCIe liefert vertraute Host-Device- und I/O-Semantik. CXL ergänzt kohärenten Speicher und Cache in unterstützten Systemen. Die UCIe ersetzt keines der beiden; sie erlaubt, dass deren Pakete und Bedeutungen innerhalb desselben Gehäuses über Dies hinweg reisen. Eine Funktion, die vom Haupt-Die verlagert wurde, kann in der bestehenden Enumeration- und Software-Umgebung erscheinen, ohne dass allein wegen der neuen physischen Position ein neues Host-Modell nötig wäre.

Der Vorteil ist Kontinuität, nicht automatische Kompatibilität. Das Package braucht weiterhin Firmware, Enumeration, Speicherpolitik, Fehlerbehandlung und Software, die das Protokoll verstehen. Zwei UCIe-Verbindungen können elektrisch kompatibel sein, während die eine PCIe transportiert, die andere CXL und eine dritte Raw-Nachrichten. Ein Betriebssystem, das eine Geräteklasse kennt, muss die Funktion eines anderen Chiplets nicht kennen.

Die Wiederverwendung ausgereifter Semantik stellt die UCIe auch in eine Abhängigkeitskette. Änderungen an PCIe oder CXL beeinflussen künftige Mappings. Der Entwickler muss die Verbindung und das darüberliegende Protokoll qualifizieren. Konformität beim Transport korrigiert weder einen Kohärenzfehler noch einen fehlenden Treiber. Der Standard macht einen bestehenden Softwarevertrag über eine neue physische Grenze hinweg portabel; er macht ihn nicht trivial.

Die UCIe-Architektur ist geschichtet. Die physische Schicht befasst sich mit dem kurzen elektrischen Kanal zwischen Dies. Ein Die-to-Die-Adapter verwaltet die Verbindung und vermittelt den Datenverkehr zwischen der physischen Schicht und den darüberliegenden Protokollen. Darüber liegen die Mappings, die für Software sichtbare Bedeutung erzeugen. Diese Trennung trägt die Portabilität: Eine Verbindungsarchitektur kann mehrere Verkehrsarten transportieren, ohne ein Protokoll an eine Gehäusetechnologie zu binden.

Der Adapter ist keine passive Hülle. Die Untersuchung beschreibt ihn als Instanz, die Management, Fehler, Wiederholung und Protokollanpassung behandelt. Das ist wichtig, weil die Grenze zwischen Dies nicht wie ein unzuverlässiger Draht agieren darf, der vor der Software verborgen ist. Das Package muss die Verbindung aufbauen, Fähigkeiten mitteilen und Fehler eingrenzen, bevor eine höhere Schicht dem Pfad vertraut.

Die Schichten schaffen auch Abweichungspunkte. Eine physische Schnittstelle kann nur eine bestimmte Rate oder Klasse unterstützen; der Adapter kann unterschiedliche Sätze von Zuverlässigkeit und Management implementieren; der Stack kann PCIe unterstützen, aber nicht CXL; der Anbieter kann nur die nötige Teilmenge offenlegen. „UCIe“ bezeichnet eine Spezifikationsfamilie, keine einheitliche Funktionsmenge.

Für Käufer und Integratoren lautet die nützliche Frage nicht, ob ein Gerät UCIe unterstützt, sondern welche Generation, Klasse, Rate, Breite, welches Mapping, welche Management-Funktion und welche Testbedingung implementiert wurden. Der Standard wird zu betrieblicher Infrastruktur, wenn diese Details angegeben, getestet und verglichen werden können. Bis dahin sagt eine allgemeine Behauptung weniger, als sie scheint.

Der Versionsabgleich bringt seine eigene Integrationslast mit sich. Ein Systemunternehmen kann einen Controller für eine UCIe-Generation und eine Gehäuseklasse qualifizieren, während ein neues Chiplet mit späteren optionalen Funktionen ankommt. Discovery und Aushandlung von Fähigkeiten ermitteln die gemeinsame Schnittmenge, erzeugen aber keine Funktion, die auf einer Seite fehlt. Produktteams brauchen eine unterstützte Schnittmenge: deklarierte und über Firmware- und Siliziumrevisionen stabile Raten, Protokolle, Management-Funktionen und Fallback-Verhalten.

Eine Inkompatibilität zu entdecken, nachdem die Dies in einem Package festgelegt wurden, kostet weit mehr, als sie an einem Platinenstecker zu finden.

Softwareportabilität folgt demselben Muster. Die PCIe- und CXL-Mappings können bekannte Gerätemodelle bewahren, während der Raw-Modus oder anbieterspezifische Management-Daten maßgeschneiderte Arbeit wieder einführen. Ein Package kann korrekt enumerieren und dennoch neue Treiber, Firmware, Topologiebeschreibungen oder Fehlerrichtlinien erfordern. Der praktische Test ist, ob derselbe Softwarevertrag einen Anbieterwechsel und die nächste Produktrevision überlebt – nicht nur, ob die Software das Die einmal erkannt hat.

Die UCIe liefert Transport und Fähigkeitsstruktur; funktionale Benennung und Lebenszyklus-Politik müssen aus anderen Standards oder expliziten Vereinbarungen kommen.

Das Konsortium definiert zwei große Klassen. UCIe-S zielt auf Standard-Gehäusetechnik mit weniger dichten und kostengünstigeren Ansätzen. UCIe-A zielt auf Advanced Packaging mit feinerem Bump-Pitch und höherer Bandbreitendichte. Damit bedient eine Spezifikationsfamilie Produkte, die nicht denselben Interposer, dasselbe Bridge- oder Bonding-Verfahren rechtfertigen.

Das ist eine wichtige kommerzielle Entscheidung. Ein Standard, der auf die teuerste Gehäusetechnik beschränkt wäre, hätte starke Leistung, aber einen schmalen Markt. Ein Standard nur für gängige organische Substrate könnte die Dichte verlieren, die fortschrittliche Computertechnik verlangt. Die zwei Klassen anerkennen, dass Interoperabilität unter unterschiedlichen Kosten und physischen Randbedingungen funktionieren muss.

Die Randbedingungen verschwinden nicht. Standard- und Advanced-Packages haben unterschiedliche Kanalbudgets, Bump-Maps und Toleranzen. Ein für UCIe-A qualifiziertes Design kann nicht unverändert auf UCIe-S übertragen werden. Der Hersteller wählt weiterhin Interposer, Bridge, organisches Substrat, Hybrid-Bonding oder eine andere Konstruktion. Foundry- und OSAT-Regeln bleiben entscheidend.

Das Ergebnis ist eine Wahl, die durch klare Grenzen begrenzt wird. Die UCIe bietet eine gemeinsame Sprache für zwei Umgebungen und erlaubt prozessspezifische Implementierung. Sie verspricht nicht, dass ein Chiplet für die eine Umgebung auch in der anderen wirtschaftlich, mechanisch kompatibel oder elektrisch qualifiziert ist. Die Package-Klasse gehört zur Identität des Produkts.

UCIe 3.0 hob die maximale Rate pro Lane von 32 GT/s auf 48 und 64 GT/s in beiden Klassen an. Das kann die aggregierte Bandbreite erhöhen, ohne die Verbindungen am Die-Rand im selben Maße zu vergrößern – attraktiv in KI und HPC, wo Rechenwerke, Speicher und Beschleuniger große Datenmengen über einen begrenzten Rand austauschen.

Eine Spezifikationsrate ist kein gemessenes Produktergebnis. Die nutzbare Bandbreite hängt von der Anzahl der Lanes, Kodierung, Overhead, Kanalqualität, Controller und Verkehrsmuster ab. Energie pro Bit hängt von Implementierung und Bedingungen ab; Ausbeute hängt davon ab, den vollständigen Kanal wiederholt zu fertigen und zu testen. Die Angabe „64 GT/s“ beweist, dass der Modus definiert wurde, nicht, dass jedes Package ihn wirtschaftlich ausführen wird.

Der schnellere Modus verschärft die Verifikation. Signalintegrität, Timing-Marge, Routing und Thermik werden mit der Dichte schwieriger. Etwas kann in einer Demonstration funktionieren und in der Produktion anderer Alterung, Spannung und Temperatur ausgesetzt sein. Schulungsmaterial und Demos zeigen Fortschritt, keine universelle Feldzuverlässigkeitshistorie.

Hier treffen Wert und Grenze aufeinander. Ein gemeinsames 64-GT/s-Ziel bündelt Investitionen und macht Probleme vergleichbar, muss aber weiterhin der physischen Realität jedes Packages standhalten.

Verwaltung wurde so wichtig wie Bandbreite

Die schnellen Kanäle tragen die Last, aber das Multi-Die-Package braucht auch einen langsameren Pfad für Steuerung und Verwaltung. Die UCIe enthält einen separaten Sideband-Mechanismus. Version 3.0 erweiterte die definierte Reichweite unter den maßgeblichen Bedingungen auf bis zu 100 Millimeter und ermöglicht so mehr Flexibilität bei der inneren Anordnung verwalteter Komponenten.

Eine Komponente muss möglicherweise erkannt, abgefragt oder in einen sicheren Zustand versetzt werden, bevor die schnelle Verbindung bereit ist. Die Verwaltung sollte nicht vollständig von dem Pfad abhängen, den sie zu diagnostizieren versucht. Signalisierung mit geringer Latenz und Notfallsteuerungen sind wichtig, wenn Chiplets Ressourcen teilen und sich eines unerwartet verhält.

Die erweiterte Reichweite verspricht nicht, dass der 64-GT/s-Kanal derselben Geometrie folgt. Sideband- und Datenpfade haben unterschiedliche Zwecke und elektrische Anforderungen. Die Verwaltung kann eine größere interne Entfernung überbrücken, während schnelle Verbindungen kurz und dicht bleiben.

In Systembegriffen zeigt der Sideband, dass Integration nicht mit Datenübertragung endet. Das Package braucht einen Betriebsplan. Der Standard liefert die gemeinsame Route, aber jeder Anbieter definiert weiterhin einen großen Teil des Zustands, der Politik und der Korrektur hinter den Nachrichten. Ein gemeinsamer Nerv bringt nicht alle Organe dazu, dieselbe Diagnose zu melden.

Die am 8. August 2023 veröffentlichte UCIe 1.1 ergänzte automotives Health-Monitoring und Optionen für kostengünstigere Konfigurationen. Sie war innerhalb der Familie abwärtskompatibel und erweiterte das Ziel über die teuersten Hochleistungs-Packages hinaus.

Automotivsysteme legen unterschiedliches Gewicht auf Monitoring, Zuverlässigkeit und lange Nutzungsdauern. Das Aufnehmen von Health erkannte an, dass die Verbindung dort arbeiten kann, wo latente Fehler und Diagnose im Feld ebenso wichtig sind wie maximale Bandbreite. Die kostengünstigeren Optionen antworteten auf den gegenteiligen Druck: Interoperabilität hat wenig Reichweite, wenn sie nur Premium-Gehäusetechnik verlangt.

Eine Funktion in der Spezifikation beweist keine Industrieübernahme. Fahrzeugplattformen, Qualifizierungszyklen und Anbieterverantwortung liegen außerhalb der Kontrolle der UCIe. Die Bedeutung von 1.1 liegt in der Richtung: Das Konsortium lernte bereits, dass eine gemeinsame Verbindung Package-Flexibilität und Lebenszyklus-Signale brauchte, um mehr als eine Nische zu bedienen.

Der Standard wurde in 2.0 und 3.0 fortgeführt. Jede Generation standardisierte einen weiteren Teil der Integration, der zuvor privater Vereinbarung überlassen war. Die Spezifikation wuchs, weil die schwierigsten Probleme um die ursprüngliche Verbindung herum und in ihr lagen. Ab der zweiten großen Revision ging es nicht mehr nur darum, die Verbindung herzustellen, sondern auch um den Betrieb des Packages über den gesamten Lebenszyklus.

Die am 6. August 2024 veröffentlichte UCIe 2.0 ergänzte eine Managability-Architektur und Unterstützung für 3D-Gehäusetechnik. Die Arbeit umfasste Discovery, Test, Telemetrie, Firmware-Operationen, Debugging und Lebenszyklussteuerung über mehrere Dies hinweg. Sie enthielt ein Management Transport Protocol und eine Design-Architektur für Test, Debug und Telemetrie, zusammengefasst unter dem Kürzel DFx.

Das veränderte die Definition von Interoperabilität in wichtiger Weise. Ein Package kann Daten korrekt transportieren und dennoch unmöglich zu betreiben sein. Fertigungsteams müssen Dies vor und nach der Montage testen; Firmware muss Versionen identifizieren und Aktualisierungen koordinieren; Betreiber brauchen Telemetrie und Fehlerisolation; der Entwickler muss wissen, ob eine defekte Komponente eingedämmt werden kann, ohne alles lahmzulegen.

Die gemeinsame Architektur bietet Transport und ein geteiltes Strukturmodell. Sie definiert nicht jedes Verwaltungsobjekt, jede Update-Politik oder jedes Serviceverfahren. Ein Anbieter kann detaillierte Telemetrie offenlegen, ein anderer nur minimalen Status. Das Systemunternehmen kann koordinierte Updates erlauben oder das Package auf freigegebene Images begrenzen. Der Standard ermöglicht Nachrichten zwischen Anbietern, behält aber die Politikgrenze zwischen ihnen bei.

Der praktische Test ist die Verantwortung. Wenn die Telemetrie eine grenzwertige Verbindung anzeigt, wer diagnostiziert dann: der Die-Anbieter, der Montagebetrieb oder das Systemunternehmen? Wenn ein Update das Verhalten ändert, wer qualifiziert das Package neu? UCIe 2.0 schuf den technischen Ort, um diese Fragen zu stellen, nicht die vertragliche Antwort.

Design für Test, Debugging, Telemetrie und andere Lebenszyklusfunktionen wirken wie Werksangelegenheiten. In einem Multi-Die-System sind sie Teil der Architektur. Das Package kann Dies enthalten, die in verschiedenen Prozessen gefertigt, von unterschiedlichen Unternehmen geliefert und mit eigenen internen Methoden getestet wurden. Nach der Montage muss bestimmt werden, ob ein Fehler zu einem Die, der Verbindung, dem Kanal, der gemeinsamen Stromversorgung oder der koordinierenden Software gehört.

Die DFx-Architektur versucht, eine gemeinsame Grundlage zu schaffen. Der Verwaltungspfad transportiert Zustand und Diagnose; Test und Debugging können ein geteiltes Modell nutzen, statt für jedes Paar eine proprietäre Verbindung zu haben. Das reduziert maßgeschneiderte Übertragungen und erleichtert es, Belege während Fertigung und Betrieb zu bewahren.

Der Standard schafft keine Observability, die im Chiplet fehlt, und garantiert nicht, dass das Signal die Ursache zeigt. Ein Die kann einen Fehler melden, der durch Energierauschen an anderer Stelle verursacht wurde. Die Verbindung kann sich um eine grenzwertige Bedingung herum neu trainieren, ohne zu zeigen, wie nahe sie am Ausfall ist. Der Montagebetrieb kann ein Ausbeuteproblem sehen, das im Labor des Integrators nicht auftritt. Gemeinsamer Transport bewegt Belege; er macht sie nicht vollständig.

DFx verändert auch die kommerzielle Grenze. Testabdeckung, Telemetriezugriff und Firmware-Kontrolle müssen möglicherweise in die Kauf spezifikation. Ein konformes Die ohne zugängliche Diagnose kann weniger wert sein als ein proprietäres Die mit besserer Lebenszyklusunterstützung. Die Architektur öffnet den Weg; die Qualität der Verwaltung bleibt eine Produktentscheidung.

3D-Integration erweitert Entwurfsraum und Fehlerfläche

Dieselbe Generation ergänzte Unterstützung für 3D-Gehäusetechnik, einschließlich vertikal gestapelter Dies und sehr kurzer, dichter Verbindungen. Das Stapeln bringt Rechenwerke und Speicher näher zusammen, erhöht die Bandbreitendichte und reduziert die Fläche. Es koppelt Wärme, mechanische Spannung und Ausbeute stärker als 2D- oder 2,5D-Anordnungen.

Der Standard hilft zu definieren, was die vertikale Grenze überquert, definiert aber weder Bonding-Prozess, thermischen Stack, Stromversorgungsnetz noch die Reihenfolge, gute Dies vor der Montage zu identifizieren. Diese Entscheidungen liegen bei Foundries, OSATs, Entwicklern und Systemunternehmen.

Die Reparatur ist ein kritischer Punkt. Platinenmodularität legt den Austausch von Teilen nahe; ein dicht verbundenes Package kann den Austausch eines internen Die im Feld nicht zulassen. Die Verwaltung kann die Komponente identifizieren, aber die kommerzielle Lösung bleibt, das gesamte Package zu tauschen. Bessere Diagnose verkürzt die Untersuchung, ändert aber nicht die physische Reparierbarkeit.

Die Spezifikation unterstützt also 3D-Integration, ohne sie einfach zu machen. Sie hält die Kommunikations- und Verwaltungsgrenzen erkennbar, wenn sich die Geometrie ändert. Das Fertigungsproblem darum herum wird anspruchsvoller, nicht geringer.

PCIe und CXL bieten etablierte Softwarepfade, aber nicht jedes Chiplet verhält sich wie ein I/O-Gerät oder kohärenter Speicher. Signalverarbeitung, Netzwerke und spezialisierte Beschleuniger können kontinuierlichen oder spezifischen Datenverkehr benötigen. Der Raw-Modus transportiert diese Daten, ohne PCIe- oder CXL-Semantik aufzuerlegen. Version 3.0 erweiterte die kontinuierlichen Mappings, auch für Analog-Digital- und Digital-Analog-Pfade.

Der Raw-Modus erhöht die Zahl der Systeme, die die physische Schicht nutzen können, und legt den Unterschied zwischen elektrischer und funktionaler Interoperabilität offen. Zwei Anbieter können denselben Kanal erfüllen und oberhalb des Transports unterschiedliches Framing, unterschiedliche Flusskontrolle und unterschiedliche Bedeutung definieren. Die Verbindung verbindet; die Funktionen brauchen weiterhin eine separate Vereinbarung.

Das ist nicht unbedingt ein Fehler. Eine gemeinsame physische Basis reduziert Duplikation auch mit spezialisiertem Protokoll. Das Risiko entsteht, wenn „unterstützt UCIe“ eine Portabilität suggeriert, die Raw nicht liefert. Der Käufer muss wissen, ob das Mapping ein gemeinsames Profil, ein bilateraler Vertrag oder ein proprietäres Protokoll ist.

Raw kann das Ökosystem vergrößern, indem es mehr Chiplet-Typen aufnimmt, und zugleich private funktionale Inseln bewahren. Das Ergebnis hängt von geteilten Profilen und ausreichend Informationen für eine unabhängige Integration ab.

Die Branche ist voller Abkürzungen, und es ist verlockend, sie als Konkurrenten zu behandeln. PCI-SIG definiert PCI Express und sein Gerätemodell; das CXL Consortium definiert kohärenten Speicher und verwandte Semantik; die UCIe definiert den kurzen Kanal innerhalb des Packages und die Mappings, die diese Protokolle transportieren.

Diese Arbeitsteilung erklärt einen Teil des Tempos der UCIe. Sie musste Betriebssysteme und Hersteller nicht überzeugen, für jede Transaktion eine neue Bedeutung zu übernehmen; sie trug Semantik, die bereits durch Software, Validierung und Industrieverbände abgestützt war.

Sie erbt auch Veränderung und Komplexität der oberen Schicht. Ein CXL-Package braucht weiterhin eine kohärente Architektur; ein PCIe-Chiplet braucht Enumeration, Treiber und Fehlerbehandlung. Ein Defekt weiter oben wird nicht allein deshalb zu einem UCIe-Fehler, weil er die Grenze zwischen Dies überquert hat.

Die Beziehung ist ein Stapel von Verantwortlichkeiten. Die UCIe regelt, wie Bits und Pakete das Package durchqueren; PCIe oder CXL regeln, was die Pakete bedeuten; Firmware und Betriebssoftware regeln, wie das System dargestellt und genutzt wird. Keine Schicht kann das Ergebnis der drei allein für sich beanspruchen.

Ein schneller Kanal muss nachweisen, dass beide Enden unter realen elektrischen Bedingungen kommunizieren. Die Untersuchung beschreibt Fähigkeitsaushandlung, Training, Rekalibrierung zur Laufzeit und Drosselung. UCIe 3.0 ergänzte Rekalibrierung des Senders und Energieanpassungen, um Prozess-, Spannungs-, Temperatur- und Betriebsschwankungen zu folgen.

Anpassung ist essenziell: Die Temperatur ändert sich mit der Last, die Versorgung schwankt, und Bauteile altern. Die Verbindung muss Marge zurückgewinnen oder die Aktivität reduzieren, statt anzunehmen, dass der bei der Fertigung gemessene Zustand ein Leben lang hält.

Erfolgreiches Training ist ein begrenztes Ergebnis. Es zeigt, dass die Verbindung unter den getesteten Bedingungen hergestellt wurde, nicht, dass sie unter jeder Last, jedem thermischen Zyklus oder über die gesamte Lebensdauer zuverlässig ist. Rekalibrierung kann eine Drift korrigieren und eine andere unbemerkt lassen; Drosselung erhält den Betrieb auf Kosten der Leistung.

Der Käufer braucht einen präzisen Bericht: spezifizierte maximale Rate, im Package validierte Rate, Rekalibrierungsbedingungen und Verhalten bei unzureichender Marge. Eine adaptive Verbindung verwaltet Veränderung, verwandelt aber ungemessene Zuverlässigkeit nicht in eine Garantie.

Konformitätsnachweise müssen spezifisch genug sein, um einen Kauf zu leiten

Ein einziges Etikett beschreibt nicht alle Implementierungen. Eine vollständige Angabe muss Generation, Klasse, Rate, Lanes, Protokoll, optionale Merkmale und Testbedingungen nennen. Zwei Produkte können UCIe implementieren und am gewünschten Leistungspunkt keine nützliche Kombination teilen.

Ausgereifte Programme binden Konformität an definierte Fähigkeiten und Verfahren. Zum Redaktionsschluss baute die UCIe diese Grundlage noch auf. Es gab Interoperabilitätsarbeit, Veranstaltungen, Webinare und Demonstrationen von Controllern und PHYs, aber keine vollständige öffentliche Liste zertifizierter Produkte.

Ein nützliches Programm muss mehr testen als das einfachste Bring-up. Es muss Fehler, Aushandlung, Verwaltbarkeit und Protokollprofile definieren. Klasse und Kanalbedingungen sind wichtig. Das Ergebnis einer Paarung darf nicht ohne Beleg auf eine andere Rate oder ein anderes Package übertragen werden.

Das Fehlen einer universellen Liste bedeutet keine fiktiven Implementierungen; es bedeutet, dass die öffentliche Evidenz jung ist. Demos zeigen unabhängige Schnittstellen in Arbeit. Produktionsqualifizierung verlangt Wiederholbarkeit, Stückzahlen, Bedingungen und Verantwortung, wenn später etwas ausfällt.

Präzision schützt Käufer und Konsortium. Ein übertriebenes Etikett erzeugt Enttäuschung über etwas, das die Spezifikation nie zu verhindern versprochen hat. Ein genaues Profil macht sichtbar, was der Standard tatsächlich erreicht hat. Die verbleibende Hürde ist die Evidenz: Der Käufer muss die exakt getestete Konfiguration und ihre Grenzen kennen.

Seit der ersten Version ging die Aktivität von der Erklärung zur Implementierung über. Mitglieder kündigten Controller, physisches IP, Verifikationsplattformen und Package-Designs an. Veranstaltungen zeigten Demonstrationen und Sitzungen zu Signalintegrität, Gehäusetechnik und Interoperabilität. Das Material von 2025 präsentierte das als wachsende Übernahme.

Eine Demonstration beantwortet eine fokussierte Frage: Spricht dieser Controller mit jenem PHY? Erkennt die Plattform einen Fehler? Erreicht der Kanal im Labor die Rate? Das sind wertvolle Fragen; sie reduzieren Unsicherheit und zeigen Interpretationsunterschiede.

Produktion beantwortet mehr: Liefern Anbieter gute Dies termingerecht? Erreicht das Package Ausbeute und Energieziele? Aktualisiert die Firmware Komponenten sicher? Ist die Software zwischen Revisionen portabel? Wer ersetzt das System, wenn ein grenzwertiges Die intermittierend ausfällt? Die Demonstration trägt bei, löst aber nicht alles.

Es gab kein vollständiges Inventar von Multi-Anbieter-Packages in Auslieferung. Die sichere Schlussfolgerung ist, dass das Ökosystem Implementierungsfähigkeit aufbaut; nicht, dass bereits ein universeller Markt existiert.

Der Integrator kann ein Chiplet nicht allein anhand der Verbindung bewerten. Das Die muss für Funktion, Prozess-Ecke und Lebenszyklus gut sein, mit Belegen, die Wafer, Montage und Endsystem durchlaufen. Ein Defekt nach der Integration kann die anderen Dies und die Gehäusearbeit verderben.

Known-Good-Die ist eine kommerzielle und fertigungstechnische Anforderung. Anbieter müssen sich über Test, Margen, Darstellung der Ergebnisse und darüber einigen, wer den Verlust trägt. Die Management- und DFx-Architektur kann Belege transportieren, zertifiziert aber weder die interne Funktion noch verteilt sie Verantwortung.

Das ist ein Vorteil der vertikalen Integration: Ein Unternehmen kontrolliert Design, Testgrenzen, Montage und Garantie. Das Multi-Anbieter-Package muss private Übertragungen in Belege und explizite Verträge verwandeln.

Die fehlende Schicht ist nicht glamourös, entscheidet aber, ob Modularität kleinere Anbieter erreicht. Die Verbindung senkt eine Barriere; die Zusage eines guten Die entscheidet, ob der Käufer den Rest des Packages für ein unbekanntes Bauteil riskiert.

Sicherheit, Garantien und Software entscheiden, ob ein Markt entsteht

Ein Multi-Anbieter-Package schafft eine sehr intime Vertrauensgrenze. Chiplets tauschen Daten in hohem Volumen aus, teilen Verwaltungspfade und beeinflussen Ressourcen, die wie ein Gerät behandelt werden. Ein kompromittiertes Die kann zu einem Weg für Steuerung und Daten des Packages werden.

Die spätere Verwaltbarkeit unterstützt kontrollierte Erkennung, Firmware und Notfallsignalisierung. Das Material der Mitglieder nennt verbesserte Sicherheit als laufende Arbeit. Dennoch definiert sie keine vollständige Architektur. Identität, Secure Boot, Firmware-Herkunft, Attestierung, Isolation, Schlüssel und Anbietergarantie bleiben Systemverantwortung.

Sicherer Transport schützt Nachrichten, während ein autorisiertes, aber kompromittiertes Chiplet Fehlverhalten zeigt. Starke Identität sagt, welches Die vorhanden ist, nicht, dass die Firmware sicher ist. Eine attestierte Komponente kann Zugriff weiterhin missbrauchen. Sicherheit hängt davon ab, was sie nach der Vertrauensbildung tun kann.

Künftige Versionen können mehr definieren, aber die Belege legen weder Form noch Datum fest. „Konform zur UCIe“ ist keine Sicherheitszertifizierung des Packages. Der Käufer braucht ein separates Modell für jeden Anbieter und für das Gesamtsystem.

Die UCIe wird als offener Standard beschrieben, und ihre Spezifikationen können zu Evaluierungsbedingungen angefordert werden. Das erlaubt es, die Architektur zu studieren, Werkzeuge anzugleichen und Kompatibilität zu diskutieren, ohne einen einzigen Eigentümer der Schnittstelle.

Der Rest der Kette kann konzentriert bleiben. Fortschrittliche Fertigung, Hybrid-Bonding, Interposer, Montage, Test und EDA kommen von wenigen Unternehmen und Regionen. Exportkontrollen und Industriepolitik betreffen Knoten, Werkzeuge und IP. Eine gemeinsame Verbindung schafft weder eine Foundry noch eine Gehäuselinie.

Ein offener Standard verlangt keine offene Implementierung. Controller, PHY, Chiplet, Firmware oder Kit können proprietär sein. Die Vereinbarung unterscheidet das Lesen von der Implementierungslizenz. Das Unternehmen unterstützt die Verbindung und behält die Kontrolle darüber und darunter.

Das kann die realistische Stärke der UCIe sein: Sie muss nicht Open Source sein, um bilaterale Arbeit zu reduzieren. Das Risiko ist rhetorisch, wenn Offenheit in einer Schicht Wettbewerb oder Portabilität in geschlossenen Schichten suggeriert. Das Package muss schichtweise abgebildet werden. Wenn die Konformität eingegrenzt ist, werden Vertrauen, kommerzieller Support und die Frage, wer das Integrationsrisiko absorbiert, zu den schwierigsten Fragen.

Die Promoter machen die UCIe glaubwürdig, indem sie Engineering, Schnittstellen, Qualifizierung und Nachfrage beisteuern. Sie haben auch die stärksten Alternativen zu einem offenen Markt. Große Unternehmen können Chiplets, Verbindungen und proprietäre Abläufe nutzen, wenn ihnen das einen Vorteil verschafft.

Die Teilnahme ist nicht unaufrichtig. Ein Unternehmen kann UCIe an externen Grenzen nutzen und die interne Schnittstelle privat halten. Es kann ein gemeinsames Protokoll transportieren und Topologie, Speicher oder Politik differenzieren. Die Übernahme kann selektiv und geschichtet sein.

Die Herausforderung ist, die Grenze für diejenigen nützlich zu halten, die nicht den gesamten Stack kontrollieren. Die Vielfalt des Vorstands hilft, aber es gibt kein vollständiges öffentliches Register über Beitragsgewicht, Abstimmungen oder Streitbeilegung. Gleiche Logo-Platzierung bedeutet nicht gleiche Macht.

Der Standard kann auch mit privaten Vorteilen Erfolg haben. Der größere Test ist, ob ein kleiner Anbieter ein Chiplet entwickeln, ein Profil nachweisen, Zugang zu Gehäusetechnik erhalten und an mehr als ein System verkaufen kann, ohne unzumutbares rechtliches und Integrationsrisiko auf den Käufer zu übertragen.

Für den kommerziellen Austausch braucht der Käufer weit mehr als die Verbindung. Das Bauteil braucht funktionale Metadaten: was es tut, Protokolle und Raten, Erkennung, Firmware und Health. Der Entwickler braucht elektrische, energetische, thermische und mechanische Grenzwerte. Die Software braucht stabile Enumeration und Verwaltung. Einkäufe brauchen Preis, Stückzahlen, Zyklus, Garantie und Verantwortung.

Die UCIe kann einen Teil über Discovery, Profile und Verwaltung liefern. Sie definiert weder eine vollständige funktionale API noch einen universellen Katalog, weist weder Garantien noch Foundry-Kapazität zu. Das Material spricht von einem tragfähigen Markt, aber die Evidenz endet vor der vollständigen transaktionalen Schicht.

Deshalb ist sie wichtig und unzureichend. Standards schaffen Marktbedingungen, nicht den Markt. Anbieter, Foundries, Werkzeuge und Käufer müssen die Schnittstelle investierbar, testbar und unterstützbar machen.

In einem reifen Markt ist die Verantwortung lesbar. Wenn das Package ausfällt, weiß man, ob die Ursache Chiplet, Verbindung, Montage, Firmware oder Integration ist, und der Vertrag legt die Kosten fest. Ohne diese Übertragungen kann technische Modularität das Risiko des Käufers erhöhen.

Produktionsübertragungen werden den Wert der UCIe bestimmen

Das Konsortium ging von der Basis 2022 über die Automobil- und Kostensenkungsoptionen 2023, die Verwaltbarkeit und 3D 2024 hin zu 64 GT/s, Raw und Verwaltung 2025. 2026 konzentrierte sich die öffentliche Arbeit auf Schulung, Implementierung und Validierung, nicht auf eine neue Zahl.

Die Abfolge zeigt einen jungen Standard, der lernt, wo die Integration bricht. Die Verbindung brauchte Protokolle und Klassen; das Package brauchte Health, Verwaltung, DFx und 3D; höhere Raten brauchten Rekalibrierung, Energie und flexiblen Sideband. Jede Ergänzung brachte eine private Annahme in den gemeinsamen Vertrag.

Die nächste Prüfung ist anderer Art. Die Konformität muss Profile zeigen; unabhängige Anbieter müssen Dies liefern, die die Montage überleben; die Software muss erkennen und verwalten ohne Neuschreiben; die Verträge müssen Fehler und Lebenszyklus verteilen; kleinere Anbieter müssen teilnehmen, ohne die gesamte Unsicherheit beim Käufer zu lassen.

Die UCIe hat das Gespräch bereits verändert, indem sie eine gemeinsame Verbindung anbot, wo es proprietäre Verbindungen gab. Der Markt wird erscheinen, wenn der erste anbieterübergreifende Fehler diagnostiziert, zugeordnet und behoben werden kann, ohne auf einen einzigen vertikalen Integrator zurückzugreifen. Dann hört der Standard auf, eine vielversprechende Schnittstelle zu sein, und wird zur Infrastruktur.