Résumé

  • UCIe définit des règles communes pour la PHY, l’adaptateur, les protocoles et la gestion des interconnexions die à die; la fonction des chiplets, le packaging et la responsabilité des fournisseurs restent hors de son mandat
  • Des versions 1.0 à 3.0, ont été ajoutées des options de packaging moins coûteuses, la surveillance automobile, la prise en charge de la 3D, la gérabilité et le fonctionnement à 64 GT/s
  • La valeur de marché se mesure à des profils de conformité reproductibles, des produits en série multi-fournisseurs pris en charge et une responsabilité claire en cas de défaillance inter-fournisseurs

Avec 64 GT/s, la course à la vitesse est devenue une question de système

Le 5 août 2025, un consortium de normalisation qui n’existait publiquement que depuis un peu plus de trois ans a publié sa troisième spécification majeure. Universal Chiplet Interconnect Express, ou UCIe, a ajouté 48 et 64 gigatransferts par seconde pour les canaux de packaging standard et avancé. La version a également étendu la portée du chemin sideband lent, élargi la transmission continue en mode raw et ajouté des contrôles de gestion. Le titre, c’était la vitesse. Plus important encore, il s’agissait de traiter un package composé de plusieurs dies développés indépendamment comme un système unique et contrôlable.

Cette distinction compte, car une connexion plus rapide n’est qu’une partie d’un produit à chiplets. L’acheteur doit toujours savoir quelle fonction remplit chaque die, quelle puissance il consomme, comment il est refroidi, quel logiciel le reconnaît, comment le firmware est mis à jour, ce qui se passe en cas de défaillance et quel fournisseur assume la garantie. UCIe crée des règles communes pour le transfert d’informations entre dies et pour une partie de la gestion qui l’entoure. À lui seul, le standard ne transforme pas une collection de blocs de silicium sans lien en un processeur fini.

Le discours public du consortium vise un « écosystème ouvert de chiplets ». Comme ambition, c’est utile, mais la formulation peut donner l’impression de décrire un marché déjà existant. Dans les documents publics examinés pour ce profil, il n’existait ni inventaire indépendant complet des packages multi-fournisseurs UCIe livrés, ni liste universelle de produits certifiés, ni catalogue de dies interchangeables. Ce qui était visible: des spécifications, l’activité des membres, des formations à la mise en œuvre et des démonstrations.

Ce sont des étapes nécessaires, mais d’une autre nature que des preuves d’achat répétable et de production en série.

La question centrale est donc plus étroite que celle de savoir si les chiplets vont devenir importants. Comme moyen de diviser des systèmes complexes, ils le sont déjà. Ce qui compte, c’est l’ampleur de la modularité qu’une interconnexion commune peut créer lorsque le package qui l’entoure reste un produit d’ingénierie étroitement intégré. UCIe peut devenir le langage commun à la frontière du die tout en laissant l’essentiel du système physique et des relations commerciales propriétaire. L’interface doit donc être évaluée comme une chaîne de transferts, et non comme une promesse générale d’interchangeabilité.

Le terme d’interchangeabilité recouvre plusieurs tests. Premièrement, le test électrique: l’émetteur, le récepteur et le canal du package peuvent-ils se connecter selon le même profil physique? Deuxièmement, le test protocolaire: les deux côtés comprennent-ils le même mapping PCIe, CXL ou raw? Troisièmement, le test opérationnel: le package peut-il détecter, tester, surveiller et mettre à jour les dies avec des fonctions de gestion compatibles? Quatrièmement, le test fonctionnel et logiciel: le chiplet fournit-il un comportement exploitable par le firmware, les pilotes et les applications?

Cinquièmement, le test commercial: le composant est-il disponible avec des preuves de test suffisantes, des volumes, un support et une garantie?

UCIe traite directement les deux premiers niveaux et, de plus en plus, le troisième. La négociation électrique, le transport des protocoles et les transferts de gestion peuvent ainsi moins dépendre d’une conception bilatérale privée. Le quatrième niveau relève en partie de PCIe, de CXL et des logiciels spécifiques aux produits. Le cinquième appartient aux fournisseurs, aux fonderies, aux entreprises de packaging et aux acheteurs.

Confondre les niveaux mène à deux erreurs opposées. L’une consiste à rejeter le standard parce qu’il ne crée pas un marché achevé, en négligeant la valeur de la barrière physique et protocolaire supprimée. L’autre consiste à déclarer le marché achevé dès que deux dies établissent une connexion conforme, en ignorant toutes les décisions qui transforment le lien en un système maintenable.

Une évaluation professionnelle devrait préciser quelle promesse est démontrée. Une démonstration PHY prouve moins qu’un couplage protocolaire. Un couplage protocolaire prouve moins qu’un package gérable sur l’ensemble de son cycle de vie. Et un package gérable prouve moins qu’un composant remplaçable sans nouveau logiciel ni nouveau contrat. Cette hiérarchie n’est pas une critique d’UCIe; elle montre le plus clairement ce que le consortium contrôle et ce qu’il laisse au marché.

Les cinq niveaux expliquent aussi pourquoi les progrès réels ne ressemblent pas encore à un approvisionnement plug-and-play. Une version de spécification peut renforcer les trois premières promesses, tandis que les deux autres mûrissent plus lentement. Un marché des chiplets ne naît pas d’une annonce, mais de transferts plus étroits qui deviennent répétables et donc dignes de confiance.

Les chiplets déplacent la complexité du silicium vers le package

Une puce monolithique répartit les fonctions d’un système sur une grande pièce de silicium. Cela peut simplifier la communication, mais impose à toutes les fonctions le même plan de fabrication. Avec la hausse des coûts et des risques de conception, de masques et de rendement sur les nœuds avancés, il devient cher et difficile de loger chaque bloc sur un grand die. Les chiplets offrent une autre voie: la logique de calcul, la mémoire, les E/S, les fonctions analogiques, la sécurité et les accélérateurs peuvent être séparés, fabriqués sur des processus adaptés à chacun, puis interconnectés dans un système en package (system-in-package).

Le découpage ne supprime pas la complexité; il en déplace une partie du die vers le package. Chaque frontière exige signalisation, horloge, gestion des erreurs, alimentation, planification thermique, couverture de test et un comportement visible par le logiciel. Un grand die monolithique peut perdre du rendement à mesure que la surface augmente; un package multi-dies peut perdre de la valeur parce qu’un seul die intégré est défectueux, limite ou mal assemblé. Le développeur de système gagne la possibilité de mélanger les nœuds de processus et de réutiliser des blocs, mais assume en contrepartie de nouvelles dépendances au niveau du package.

C’est pourquoi « modulaire » exige de la précision. Une carte de circuit imprimé est modulaire aussi parce que les composants ont des formes standardisées, des conventions électriques, des fonctions reconnaissables et des conditions commerciales matures. Les fournisseurs publient des fiches techniques, les distributeurs tiennent des stocks, les intégrateurs connaissent les sockets, les connecteurs et les limites de défaillance. Un chiplet dans un package avancé se trouve dans un environnement physique beaucoup plus contraint, avec une tolérance à l’erreur nettement plus faible.

Il peut partager alimentation, chaleur, gestion et canaux à haut débit avec son voisin, et ne peut pas, après assemblage, être inspecté ou remplacé comme un composant sur une carte.

UCIe traite l’une des frontières récurrentes les plus difficiles: l’interconnexion die à die courte et dense. Sa normalisation peut réduire le développement répété d’interfaces et donner aux fournisseurs d’outils, aux fournisseurs d’IP et aux entreprises de systèmes un objectif commun. Les autres problèmes d’intégration ne disparaissent pas. La valeur réside dans la réduction d’une classe particulière de développements bilatéraux, non dans la transformation du package en un ensemble de pièces faiblement indépendantes.

Sans interface commune, une entreprise pouvait découper un système en plusieurs dies tout en restant intégrée verticalement. Le lien pouvait être optimisé en fonction des hypothèses électriques, du protocole, du processus de packaging et du flux de test d’un seul fournisseur. Cela donne une liberté en termes de latence, de performances et de surface, mais rend difficile pour un autre fournisseur de fournir un die tant qu’il ne connaît pas et n’implémente pas le contrat privé.

Le piège est tout autant économique que technique. Une entreprise de systèmes peut qualifier sa conception de « à base de chiplets » sans proposer le module utile à d’autres. La réutilisation se fait au fil de ses propres générations de produits; le marché externe voit un package fermé. À l’intérieur des frontières de l’entreprise, l’architecture est modulaire; à l’extérieur, elle est indivisible.

Les fondateurs d’UCIe voulaient créer une frontière commune sans prescrire l’ensemble du système. Le consortium définit le comportement PHY, l’adaptateur et les mappings de protocole. Les fournisseurs continuent de décider de la fonction, du packaging et des caractéristiques visibles. La couche commune doit être suffisamment fine pour des produits différents et suffisamment détaillée pour des implémentations indépendantes conformes à la même spécification.

L’équilibre est difficile. Trop peu d’exigences font de chaque appairage une intégration sur mesure. Trop d’exigences peuvent figer les choix de conception, favoriser les premiers implémenteurs ou réduire la différenciation. Le fait qu’UCIe soit rapidement passé du lien et du protocole à la gérabilité, au DFx et au packaging 3D montre que la frontière initiale ne suffisait pas pour un package pleinement opérationnel. Le consortium a dû normaliser davantage de transferts que le marché ne le percevait, là où des hypothèses privées empêchaient la réutilisation.

Des concurrents ont créé une organisation à but non lucratif pour une frontière volontairement étroite

UCIe a démarré le 2 mars 2022 avec la version 1.0. Universal Chiplet Interconnect Express, Inc. a été enregistrée le 2 août de la même année comme société à but non lucratif dans le Delaware et a ouvert une adhésion formelle. Les promoteurs venaient du développement de processeurs, du cloud, de la fabrication en fonderie, de l’assemblage et des tests, du stockage et des accélérateurs. Les documents actuels citent AMD, ASE, Alibaba Cloud, Arm, Google Cloud, Intel, Meta, Microsoft, NVIDIA, Qualcomm, Samsung et TSMC.

Cette largeur est le plus grand capital institutionnel. Une interconnexion die à die ne devient utile par le seul fait d’un développeur de processeurs. Les fonderies ont besoin de canaux et de règles qu’elles peuvent fabriquer. Les entreprises d’assemblage et de test ont besoin de processus qualifiables. Les fournisseurs d’EDA et d’IP d’interface ont besoin de spécifications pour les contrôleurs, les PHY et la vérification. Les entreprises de cloud et de systèmes doivent pouvoir déployer les packages obtenus pour des charges de travail réelles.

La même liste contient des incitations contradictoires. Un hyperscaler peut vouloir des blocs réutilisables tout en gardant privée l’architecture du système. Une fonderie peut soutenir le lien commun tout en protégeant ses design kits, sa capacité et son savoir-faire de processus. Un fournisseur de processeurs établi bénéficie d’un plus grand nombre de fournisseurs, mais peut disposer de liens internes meilleurs pour certains produits. Le consortium crée un espace dans lequel ces intérêts s’accordent sur une frontière; il ne les rend pas identiques.

L’adhésion n’est donc pas une preuve de déploiement. Le logo de promoteur atteste d’une participation à la gouvernance et à la technique. Un contributeur peut fournir des outils ou de l’IP. Un adoptant peut encore être en phase d’évaluation. Aucune catégorie ne prouve à elle seule qu’un package de série contient des chiplets UCIe achetés de manière indépendante, ni que les pièces sont commercialement interchangeables. Cette frontière institutionnelle ne prend de la valeur que si la pile technique reste utilisable avec différentes décisions de packaging.

Au conseil actuel, Debendra Das Sharma (Intel) est président du conseil, Cheolmin Park (Samsung) est président, Dong Wei (Arm) est secrétaire et Lihong Cao (ASE Group) est trésorier. D’autres administrateurs représentent Google Cloud, Qualcomm, Alibaba Cloud, Meta, TSMC, AMD et NVIDIA. Ces fonctions sont exercées au travers des organisations membres. Elles ne signifient ni propriété personnelle de la spécification, ni paternité exclusive.

La structure à but non lucratif donne un cadre juridique à l’adhésion, aux règles de propriété intellectuelle et au travail technique. Promoteurs, contributeurs et adoptants ont des formes de participation différentes. Les copies publiques d’évaluation rendent l’architecture visible, mais les conditions distinguent l’étude des droits d’implémentation et d’adhésion plus étendus. La licence est limitée à l’évaluation interne et ne fait pas de la spécification un bien commun libre de brevets.

C’est important pour les petits fournisseurs. Un document public réduit le coût de compréhension des exigences, mais ne supprime pas automatiquement l’incertitude juridique, ne fournit pas d’outils de vérification et ne finance pas le développement à haut débit. Une start-up peut lire la même spécification qu’un promoteur sans posséder pour autant son portefeuille de brevets, ses relations de packaging ou son budget de validation.

UCIe est portée par l’adhésion, mais les documents utilisés ne contiennent aucun revenu vérifié, aucune réserve, aucun effectif ni aucune dépense par génération de spécification. Cela limite les affirmations sur la taille financière de l’organisation, non sur les intérêts économiques autour du standard.

Le travail coûteux se fait chez les membres et les fournisseurs. Les entreprises de semi-conducteurs développent des contrôleurs et des dies, les fournisseurs de PHY de l’IP réutilisable, les sociétés d’EDA la modélisation et la vérification, les fonderies et les entreprises d’assemblage les processus de packaging. Les entreprises de systèmes paient pour l’intégration, la qualification et le logiciel. Le lien commun peut réduire les doublons, mais l’avantage apparaît dans l’économie des produits, pas dans le chiffre d’affaires du consortium.

L’adhésion répartit aussi les droits et les risques. Promoteurs et contributeurs travaillent sur la technique dans le cadre d’accords de consortium. L’évaluation publique donne un aperçu; les droits d’implémentation et la protection de la propriété intellectuelle dépendent des accords respectifs. On obtient ainsi une référence technique ouverte avec une économie d’adhésion structurée autour de l’implémentation.

C’est essentiel pour la pérennité. L’influence n’exige pas le chiffre d’affaires d’un fabricant de puces, mais un soutien continu suffisant pour maintenir les spécifications, clarifier les interprétations, développer la conformité et coordonner la génération suivante. Le risque n’est pas une défaillance produit classique, mais que les entreprises, face aux coûts d’implémentation, jugent une voie propriétaire plus rentable, ou que les coûts de qualification augmentent plus vite que la valeur d’une interopérabilité large.

La spécification s’appuie sur des protocoles établis et laisse les choix de packaging aux fabricants

La première version n’a pas cherché à réinventer chaque transaction de plus haut niveau. Elle a défini un lien physique die à die et un adaptateur pour des protocoles établis, dont PCI Express et Compute Express Link, ainsi que pour le trafic raw. Une nouvelle frontière de package a ainsi été raccordée à des modèles logiciels et de périphériques que les développeurs de systèmes connaissaient déjà.

PCIe apporte une sémantique connue d’hôte-périphérique et d’E/S. CXL ajoute la mémoire cohérente et la sémantique de cache dans les systèmes pris en charge. UCIe ne remplace aucune de ces organisations ou spécifications; il laisse leurs paquets et leur signification circuler entre des dies au sein du même package. Une fonction peut apparaître hors du die principal tout en utilisant l’énumération et les logiciels existants.

L’avantage est la continuité, pas une compatibilité automatique. Le package a toujours besoin de firmware, d’énumération, de politique mémoire, de gestion des erreurs et de logiciels pour le protocole choisi. Deux liens électriquement compatibles UCIe peuvent transporter des messages PCIe, CXL ou raw. Un système d’exploitation qui connaît une classe de périphériques ne comprend pas nécessairement un autre chiplet.

La réutilisation d’une sémantique mature inscrit aussi UCIe dans des dépendances. Les évolutions de PCIe ou de CXL peuvent affecter les mappings futurs. Le développeur du package doit qualifier le lien et le protocole supérieur. La conformité du transport ne répare ni une erreur de cohérence, ni un pilote manquant. Le standard rend un contrat logiciel existant portable à travers une nouvelle frontière physique; il ne le rend pas trivial.

L’architecture d’UCIe est en couches. La couche physique traite le canal électrique court. Un adaptateur die à die gère le lien et fait l’interface avec le trafic de protocole supérieur. Au-dessus se trouvent les mappings qui donnent aux bits transmis une signification logicielle. Cette séparation est essentielle à la portabilité: la même architecture de lien peut transporter différents types de trafic sans lier un protocole à une technique de packaging.

L’adaptateur est plus qu’une enveloppe passive. La recherche décrit la gestion du lien, les erreurs, la retransmission et l’adaptation de protocole. Une frontière de die ne doit pas ressembler à un fil peu fiable et invisible pour le logiciel. Le package a besoin de voies définies pour l’établissement du lien, la déclaration des capacités et la limitation des erreurs avant qu’une couche supérieure ne fasse confiance au chemin.

La stratification crée aussi des points de divergence. Une PHY peut ne prendre en charge qu’un débit ou une classe. Un adaptateur peut avoir d’autres fonctions optionnelles de fiabilité et de gestion. Un moteur peut maîtriser PCIe, mais pas CXL. Un intégrateur de systèmes peut n’exposer que la partie nécessaire. « UCIe » désigne donc une famille de spécifications, et non un ensemble de fonctions uniforme.

Pour les acheteurs professionnels, ce qui compte n’est pas de savoir si un appareil prend en charge UCIe, mais quelle génération, quelle classe de packaging, quel débit, quelle largeur, quel mapping de protocole, quelle fonction de gestion et quelle condition de test sont implémentés. Un standard devient une infrastructure opérationnelle lorsque ces détails peuvent être déclarés, testés et comparés. Jusqu’à ce moment, l’affirmation générale en dit moins qu’elle ne le laisse croire.

L’alignement des versions crée une charge d’intégration propre. Un intégrateur peut qualifier un contrôleur pour une génération d’UCIe et une classe de package, puis recevoir un nouveau chiplet doté de fonctions optionnelles plus récentes. La découverte des capacités et la négociation trouvent l’ensemble commun, mais ne peuvent pas créer une fonction qui manque d’un côté. Les équipes produit ont donc besoin d’une intersection prise en charge: débits, protocoles, fonctions de gestion et comportements de repli déclarés, qui restent stables à travers les révisions de firmware et de silicium.

Découvrir un écart seulement après avoir fixé les dies dans un package coûte nettement plus cher qu’à un connecteur sur une carte.

La portabilité logicielle suit le même schéma. Les mappings PCIe et CXL peuvent préserver des modèles de périphériques familiers, tandis que le mode raw ou les données de gestion spécifiques au fournisseur réintroduisent du travail sur mesure. Un package peut énumérer correctement et exiger malgré tout de nouveaux pilotes, du firmware, des descriptions de topologie ou des règles d’erreur. Le test pratique consiste à savoir si un contrat logiciel survit à un changement de fournisseur et à la révision suivante du produit, et non si le logiciel a pu voir le die une fois.

UCIe fournit le transport et le cadre de capacités; la désignation des fonctions et la politique de cycle de vie doivent venir d’autres standards ou d’accords explicites.

Le consortium définit deux classes. UCIe-S vise le packaging standard, à densité plus faible et coût moindre. UCIe-A vise le packaging avancé, avec un pas de bump plus serré et une densité de bande passante plus élevée. Une famille de spécifications peut ainsi servir des produits qui ne justifient pas les mêmes coûts d’interposeur, de pont ou de bonding.

C’est une décision commerciale importante. Un standard réservé au packaging le plus coûteux aurait un fort potentiel, mais un petit marché. Un standard réservé aux substrats organiques ordinaires pourrait manquer la densité requise pour les systèmes de calcul avancés. Les deux classes reconnaissent que l’interopérabilité doit fonctionner sous des contraintes physiques et de coût différentes.

Les frontières ne disparaissent pas. Les packages standard et avancés ont des budgets de canal, des cartes de bumps et des tolérances différents. Une conception UCIe-A ne peut pas être reprise telle quelle en UCIe-S. L’interposeur, le pont, le substrat organique, le hybrid bonding ou d’autres constructions restent des décisions du fournisseur de package. Les règles des fonderies et des OSAT restent déterminantes.

Le résultat est une liberté de choix limitée. UCIe crée un vocabulaire commun pour deux environnements et permet une implémentation spécifique au processus. Il ne garantit pas qu’un chiplet d’un environnement soit économiquement viable, mécaniquement compatible ou électriquement qualifié dans l’autre. La classe de packaging fait partie de l’identité du produit.

UCIe 3.0 a porté le débit maximal par lane de 32 à 48 et 64 GT/s pour UCIe-S et UCIe-A. Des débits plus élevés peuvent augmenter la bande passante globale sans accroître proportionnellement le nombre de connexions sur le bord du die. C’est intéressant pour les packages d’IA et de HPC, où la logique de calcul, la mémoire et les accélérateurs échangent de grandes quantités de données dans un périmètre de package limité.

Un débit de spécification n’est pas un résultat produit mesuré. La bande passante utile dépend du nombre de lanes, du codage, des frais généraux, de la qualité du canal, du contrôleur et des schémas de trafic. L’énergie par bit dépend de l’implémentation et des conditions; le rendement dépend de la capacité à fabriquer et tester le canal complet de manière répétée. Les 64 GT/s du document prouvent la définition du mode, pas son fonctionnement économique dans chaque package.

Le mode plus rapide durcit la vérification. L’intégrité du signal, les marges de timing, le routage et la thermique deviennent plus difficiles à haute densité. Une démo peut réussir alors que les produits de série subissent d’autres conditions de vieillissement, de tension et de température. Les formations et les démonstrations montrent des progrès, mais pas une preuve universelle de fiabilité sur le terrain.

C’est ici que se rencontrent la valeur et la limite. Un objectif commun de 64 GT/s concentre les investissements des outils et des fournisseurs et rend les problèmes de vérification comparables. Il doit néanmoins tenir compte de la réalité physique de chaque package.

La gérabilité est devenue aussi importante que la bande passante

Les canaux à haut débit transportent la charge utile, mais un package multi-dies a aussi besoin d’un chemin de contrôle et de gestion plus lent. UCIe comprend un mécanisme sideband séparé du chemin de données principal. La version 3.0 a étendu la portée définie jusqu’à 100 millimètres dans les conditions pertinentes et permet un placement plus flexible des composants gérés.

Un composant peut devoir être détecté, interrogé ou placé dans un état sûr avant que le lien rapide ne soit prêt. La gestion ne devrait pas dépendre entièrement du chemin qu’elle est censée diagnostiquer. Face à des ressources partagées et au comportement inattendu d’un chiplet, les signaux à faible latence et les contrôles d’urgence sont particulièrement importants.

La portée accrue n’est pas une promesse que le canal principal à 64 GT/s puisse utiliser la même géométrie. Le sideband et le chemin de données ont des finalités et des exigences électriques différentes. La gestion peut couvrir une distance interne plus longue, tandis que les liens rapides restent courts et denses.

Sur le plan systémique, le chemin sideband montre que l’intégration des chiplets ne s’arrête pas au transfert de données. Un package a besoin d’un niveau opérationnel. Le standard peut créer un chemin commun, mais les fournisseurs continuent de définir une grande partie des états, des politiques et des mesures correctives derrière les messages. Un nerf commun ne signifie pas que chaque organe rapporte le même diagnostic.

UCIe 1.1 est parue le 8 août 2023 et a ajouté la surveillance de santé pour l’automobile ainsi que des options pour des packages moins coûteux. La version était rétrocompatible au sein de la famille et élargissait la cible au-delà des packages hautes performances les plus coûteux.

Les systèmes automobiles accordent un poids différent à la surveillance, à la fiabilité et à la longue durée d’utilisation que les produits accélérateurs à courte durée de vie. Les données de santé dans le standard reconnaissent que les défauts latents et le diagnostic sur le terrain peuvent être aussi importants que la bande passante de pointe. Les options moins coûteuses ont répondu à la pression économique inverse: l’interopérabilité reste limitée si elle suppose un packaging premium.

Une fonction dans la spécification ne prouve pas l’adoption par l’industrie. Les plateformes automobiles, les cycles de qualification et la responsabilité des fournisseurs échappent au contrôle d’UCIe. L’importance de la 1.1 tient à la direction prise. Le consortium a reconnu très tôt qu’un lien commun à haut débit a besoin de flexibilité dans le packaging et de signaux de cycle de vie pour servir plus qu’un segment étroit.

Le schéma s’est poursuivi en 2.0 et 3.0. Chaque génération a normalisé une part supplémentaire de la charge d’intégration auparavant réglée en privé. La spécification a grandi parce que les problèmes de marché les plus difficiles se situaient à la fois à l’intérieur et autour du lien d’origine. Avec la deuxième grande révision, la tâche est passée de l’établissement du lien à l’exploitation de l’ensemble du package sur son cycle de vie.

UCIe 2.0 a été publiée le 6 août 2024 et a ajouté une architecture système de gérabilité ainsi qu’une prise en charge du packaging 3D. Elle traitait la détection, le test, la télémétrie, les opérations de firmware, le débogage et le contrôle du cycle de vie à travers plusieurs dies. Cela incluait un protocole de transport de gestion (Management Transport Protocol) et une architecture pour le design-for-test, le débogage et la télémétrie, souvent regroupés sous le terme DFx.

La signification de l’interopérabilité s’en est trouvée modifiée. Un package peut transmettre correctement des données et rester pourtant ingérable. Les équipes de fabrication doivent tester les dies avant et après assemblage. Les équipes firmware doivent détecter les versions et coordonner les mises à jour. Les exploitants ont besoin de télémétrie et d’isolation des erreurs. Les développeurs de systèmes doivent savoir si un composant défectueux peut être isolé sans faire tomber tout le package.

L’architecture commune donne à ces activités un cadre partagé de transport et de structure. Elle ne définit pas chaque objet de gestion, chaque politique de mise à jour ou chaque procédure de service. Un fournisseur peut fournir des données de santé détaillées, un autre seulement des états minimaux. Un intégrateur peut autoriser des mises à jour coordonnées ou limiter le package à des images validées. Le standard transporte des messages de gestion entre fournisseurs, mais ne supprime pas leurs frontières de politique.

Le test pratique, c’est la responsabilité. Lorsque la télémétrie indique un lien limite, est-ce le fournisseur du die, le partenaire d’assemblage ou l’entreprise de systèmes qui diagnostique? Si une mise à jour modifie le comportement, qui requalifie l’ensemble du package? UCIe 2.0 a créé un lieu technique commun pour ces questions, pas une réponse contractuelle.

Le design-for-test, le débogage, la télémétrie et les fonctions de cycle de vie associées semblent volontiers des sujets d’usine. Dans un système multi-dies, ils font partie de l’architecture du produit. Un package peut contenir des dies issus de processus différents, d’entreprises différentes et dotés de méthodes de test internes divergentes. Après assemblage, le système doit déterminer si un incident relève d’un die, du lien, du canal du package, de l’alimentation partagée ou du logiciel de coordination.

L’architecture DFx d’UCIe vise à donner à ces fonctions une base commune. Un chemin de gestion transporte les données d’état et de diagnostic. Les tests et le débogage peuvent être conçus autour d’un modèle de package commun, au lieu d’exiger une connexion propriétaire pour chaque appairage. Cela réduit les transferts sur mesure et facilite l’obtention de preuves à travers la fabrication et l’exploitation.

Le standard ne peut pas créer une observabilité qu’un chiplet n’implémente pas, ni garantir qu’un signal rapporté nomme la cause. Un die peut signaler une erreur causée par un bruit d’alimentation ailleurs. Un lien peut se ré-entraîner autour d’un état limite sans montrer sa proximité de la défaillance. Une entreprise d’assemblage peut voir un problème de rendement qui ne se reproduit pas dans le laboratoire de l’intégrateur. Le transport commun déplace les preuves, mais ne les complète pas.

Le DFx modifie aussi la frontière commerciale. La couverture de test, l’accès à la télémétrie et le contrôle du firmware deviennent des critères d’achat. Un die conforme UCIe sans diagnostic accessible peut être moins utile qu’un die propriétaire doté d’un meilleur support de cycle de vie. L’architecture commune ouvre un chemin de gestion; sa qualité reste une décision produit.

L’intégration 3D élargit à la fois l’espace de conception et la surface de défaillance

UCIe 2.0 prenait aussi en charge le packaging 3D, notamment des dies empilés verticalement et des connexions très courtes et denses. L’empilement peut rapprocher la logique de calcul et la mémoire, augmenter la densité de bande passante et réduire la surface. En même temps, il couple la chaleur, les contraintes mécaniques et le rendement plus étroitement que les configurations 2D ou 2,5D.

Un standard d’interface aide à déterminer ce qui franchit la frontière verticale. Il ne définit ni le processus de bonding, ni l’empilement thermique, ni le réseau de distribution d’alimentation, ni l’ordre dans lequel les bons dies sont vérifiés avant l’assemblage final. Ces décisions restent aux fonderies, aux fournisseurs d’assemblage et de test, aux développeurs de puces et aux entreprises de systèmes.

C’est particulièrement visible en matière de réparation. La modularité au niveau de la carte suggère le remplacement; un package multi-dies densément bondé ne permet pas de remplacer en pratique un die interne sur le terrain. Le système de gestion peut identifier le composant défectueux, mais le recours commercial reste le remplacement de l’ensemble du package. Un meilleur diagnostic réduit le temps d’investigation, mais ne change pas la réparabilité physique.

Le standard prend en charge l’intégration 3D sans la rendre simple. Il maintient des frontières de communication et de gestion reconnaissables lorsque la géométrie change. La tâche de fabrication environnante devient plus exigeante, pas plus facile.

PCIe et CXL fournissent des chemins logiciels établis, mais tous les chiplets ne se comportent pas comme un périphérique d’E/S ordinaire ou une mémoire cohérente. Le traitement du signal, les réseaux et les accélérateurs spécialisés peuvent avoir besoin d’un trafic continu ou spécifique à l’application. Le mode raw le transporte sans sémantique PCIe ni CXL. La version 3.0 a étendu les mappings continus, notamment pour les chemins de données analogique-numérique et numérique-analogique.

Le mode raw élargit le cercle des systèmes utilisables et expose la séparation entre interopérabilité électrique et fonctionnelle. Deux fournisseurs peuvent satisfaire aux mêmes exigences de canal et définir, au-dessus du transport raw, un autre encadrement, un autre contrôle de flux ou une autre signification applicative. Le lien connecte; les fonctions exigent toujours un accord séparé.

Ce n’est pas nécessairement un échec. Une base physique commune réduit les doublons même pour des protocoles d’application spécialisés. Le risque apparaît lorsque le « support UCIe » suggère une portabilité que le mode raw ne fournit pas. Les acheteurs doivent savoir si le mapping est un profil commun, un accord bilatéral ou un protocole propriétaire.

Le mode raw peut donc avoir deux effets opposés: davantage de types de chiplets sur le même lien et, en même temps, des îlots fonctionnels privés au-dessus. Ce qui compte, c’est de savoir si les implémenteurs créent des profils raw communs et publient assez d’informations pour une intégration indépendante.

L’industrie des semi-conducteurs regorge d’abréviations d’interconnexion qui semblent aisément des concurrentes directes. Le PCI-SIG définit PCI Express et le modèle de périphérique. Le CXL Consortium définit la mémoire cohérente et la sémantique de protocole associée. UCIe définit le canal die à die court dans le package et les mappings de ces protocoles.

Cette stratification explique la rapidité des progrès d’UCIe. Les systèmes d’exploitation et les fabricants d’appareils n’ont pas eu à adopter une signification entièrement nouvelle pour chaque transaction; le standard transportait une sémantique avec des logiciels, des vérifications et une organisation industrielle existantes.

UCIe hérite en retour des évolutions et de la complexité de la couche supérieure. Un package compatible CXL a toujours besoin d’une conception système cohérente. Un chiplet mappé PCIe a besoin d’énumération, de pilotes et de gestion des erreurs. Une erreur dans le protocole supérieur ne devient pas une erreur UCIe simplement parce que le paquet franchit une frontière de die.

La relation peut se comprendre comme une pile de responsabilités. UCIe répond à la question de savoir comment les bits et les paquets de protocole franchissent la frontière du package dans des conditions définies. PCIe ou CXL répondent à ce que signifient beaucoup de ces paquets. Le firmware et le logiciel d’exploitation déterminent comment le système global est visible et utilisé. Aucune couche ne peut revendiquer à elle seule le résultat des trois.

Un canal à haut débit doit établir que les deux côtés communiquent dans les conditions électriques réelles. L’analyse de la spécification décrit la négociation des capacités, l’entraînement du lien, la recalibration en cours d’exécution et l’étranglement (throttling). UCIe 3.0 a ajouté une recalibration côté émetteur et des raffinements liés à la performance pour compenser les variations de processus, de tension, de température et de fonctionnement.

L’adaptation est nécessaire parce qu’un package n’est pas statique. La température suit la charge, l’alimentation varie, les composants vieillissent. Le lien a besoin de mécanismes pour retrouver de la marge ou réduire l’activité, plutôt que de supposer l’état de fabrication pendant toute la durée de vie.

Un entraînement réussi reste cependant un résultat limité. Il prouve le lien dans des conditions de test, pas la fiabilité pour chaque charge, chaque cycle thermique et toute la durée de vie. La recalibration peut corriger une dérive et laisser intact un autre mécanisme de défaillance. L’étranglement peut préserver le fonctionnement au détriment des performances.

Pour les acheteurs, cela crée une obligation de rapport. Une spécification produit devrait distinguer le débit maximal de spécification, le débit validé dans le package, les conditions de recalibration et le comportement en cas de marge insuffisante. Un lien adaptatif peut gérer le changement, mais il ne peut pas garantir une fiabilité non mesurée.

Les preuves de conformité doivent devenir assez précises pour les décisions d’achat

Un label ne peut pas décrire chaque implémentation d’UCIe. Une déclaration complète de conformité exige au minimum la génération, la classe de packaging, le débit de données, la configuration des lanes, le mapping de protocole, les fonctions de gestion optionnelles et les conditions de test. Deux produits peuvent tous deux implémenter UCIe et ne présenter aucune communauté utilisable au point de performance souhaité.

Les programmes d’interconnexion matures attachent la conformité à des capacités et des procédures de test définies. À la date de référence, l’écosystème public d’UCIe construisait encore cette base de preuves. Il y avait des travaux d’interopérabilité, des sommets, des webinaires et des démonstrations de contrôleurs/PHY, mais pas de liste publique complète de produits certifiés dans les documents.

Un programme utile doit tester plus que le bring-up le plus simple. Le comportement en erreur, la négociation des capacités, la gestion et les profils de protocole pris en charge doivent être définis. La classe de packaging et les conditions de canal comptent. Un résultat obtenu pour un appairage ne peut pas, sans preuve, être transféré à d’autres débits ou packages.

L’absence de liste universelle ne signifie pas que les implémentations sont fictives, mais que les preuves publiques sont jeunes. Les démos des membres peuvent montrer la coopération d’outils et d’interfaces indépendants. La qualification en série exige de la répétabilité, du volume, des conditions d’exploitation et une responsabilité clarifiée en cas de défaillance ultérieure.

Cette distinction protège les acheteurs et le consortium. Un label UCIe trop étendu crée des déceptions sur des choses que le standard n’a jamais eu vocation à empêcher. Un profil précis rend visible la performance réelle. La difficulté restante est la preuve: les acheteurs doivent connaître la configuration exactement testée et ses limites.

Depuis la première version, l’activité est passée de la déclaration à l’implémentation. Les membres ont annoncé des contrôleurs, de l’IP PHY, des plateformes de vérification et des travaux de packaging. Les événements ont montré des démonstrations UCIe et des sessions sur l’intégrité du signal, le packaging avancé et l’interopérabilité. Les contenus de 2025 y voyaient une adoption croissante.

Une démonstration répond à une question ciblée: ce contrôleur parle-t-il à cette PHY? La plateforme de test reconnaît-elle une erreur définie? Le canal atteint-il le débit cible au laboratoire? Ce sont des questions précieuses, qui réduisent l’incertitude d’implémentation et révèlent des différences d’interprétation de la spécification.

Un package de série répond à davantage de questions: plusieurs fournisseurs livrent-ils de bons dies dans les délais? L’assemblage atteint-il le rendement et l’objectif de performance? Le firmware peut-il mettre à jour toutes les composantes en toute sécurité? Le logiciel reste-t-il portable à travers les révisions? Qui remplace le système en cas d’erreur intermittente d’un die limite? Une démo fournit une partie des preuves, mais pas la réponse complète.

Les documents publics ne contiennent pas d’inventaire complet des packages multi-fournisseurs livrés. L’affirmation sûre est que l’écosystème construit sa capacité d’implémentation. Les preuves disponibles ne suffisent pas pour un marché universel.

Un intégrateur ne peut pas évaluer un chiplet uniquement selon que le lien s’établit ou non. Le die doit être jugé bon pour la fonction, la fenêtre de processus et le cycle de vie, avec des preuves du wafer à l’assemblage puis au système. Si un composant est défectueux après intégration, les autres dies et le travail de packaging peuvent être perdus avec.

Les preuves de die connu bon (known-good die) sont des exigences commerciales et de fabrication. Les fournisseurs doivent s’accorder sur ce qui a été testé, sur les marges applicables, sur la présentation des résultats et sur celui qui supporte la perte en cas de défaillance globale. La gestion UCIe et le DFx peuvent transporter des données de test et de télémétrie, mais ils ne certifient ni la fonction interne de chaque die, ni n’attribuent de responsabilité.

C’est un avantage des packages intégrés verticalement. Une entreprise peut contrôler la conception du die, les limites de test, l’assemblage et la garantie. Un package multi-fournisseurs doit traduire des transferts privés en preuves et contrats explicites.

La couche de marché manquante n’a rien de spectaculaire, mais elle décide si la modularité atteint les petits fournisseurs. Le lien électrique commun abaisse une barrière. Les garanties known-good déterminent si un acheteur peut engager le reste du package sur un composant inconnu.

Sécurité, garantie et logiciels déterminent l’émergence d’un marché

Un package multi-fournisseurs crée une frontière de confiance inhabituellement étroite. Les chiplets échangent de grandes quantités de données, partagent des chemins de gestion et influencent des ressources que le système final traite comme un seul appareil. Un die compromis ou malveillant peut menacer bien plus que sa propre fonction et devenir un point d’accès aux flux de contrôle et de données.

Les travaux ultérieurs de gérabilité peuvent soutenir la détection contrôlée, les opérations de firmware et les signaux d’urgence. Les documents des membres citent le renforcement de la sécurité comme un thème continu. Ces mécanismes ne définissent toutefois pas une architecture de sécurité complète du package. L’identité des appareils, le secure boot, la provenance du firmware, l’attestation, l’isolation, la gestion des clés et la sécurisation de la chaîne d’approvisionnement restent de la responsabilité du système.

Un transport sécurisé protège les messages, tandis qu’un chiplet autorisé mais compromis peut agir de manière malveillante. Une identité forte montre quel die est présent, pas que son firmware est sûr. Un composant attesté peut abuser d’un accès autorisé. La sécurité dépend de ce qui est permis une fois la confiance établie.

Une génération future pourra définir davantage de fonctions de sécurité; le calendrier et la forme ne sont pas établis. Aujourd’hui, « conforme UCIe » n’est pas une certification de sécurité du package. Les acheteurs ont besoin de leur propre modèle de confiance pour chaque fournisseur et pour l’ensemble du système.

UCIe est présenté comme un standard industriel ouvert; les spécifications sont publiquement disponibles sous conditions d’évaluation. Cela permet l’étude, des concepts d’outils communs et des discussions de compatibilité sans propriétaire unique de l’interface.

Le reste de la chaîne d’approvisionnement peut rester fortement concentré. La fabrication avancée des wafers, le hybrid bonding, les interposeurs, l’assemblage, les équipements de test et l’EDA proviennent de quelques entreprises et régions. Les contrôles à l’exportation et les politiques industrielles influencent l’accès aux nœuds, aux outils et à l’IP. Un lien commun ne crée ni nouvelle fonderie, ni nouvelle ligne de packaging.

Un standard ouvert n’exige pas une implémentation ouverte. Le contrôleur, la PHY, le chiplet, le firmware ou le design kit peuvent être propriétaires. L’accord d’évaluation sépare la lecture de la licence d’implémentation. Une entreprise peut soutenir le lien commun et conserver le contrôle au-dessus comme en dessous.

C’est peut-être la force réaliste. UCIe n’a pas besoin d’open source pour réduire le travail bilatéral. Le risque est rhétorique: l’ouverture à un niveau est présentée comme de la concurrence ou de la portabilité à des niveaux fermés. Le package doit être examiné couche par couche. Une fois la conformité décrite de manière limitée, il s’agit de confiance, de support commercial et de répartition du risque d’intégration.

Les promoteurs donnent sa crédibilité à UCIe. Ils apportent la technique, construisent des interfaces, qualifient des packages et créent la demande. En même temps, ils disposent des alternatives les plus fortes à un marché ouvert. Les grandes entreprises de processeurs, de cloud et de fonderie peuvent utiliser des chiplets propriétaires, des liens internes et des flux de package propriétaires lorsque cela présente des avantages.

Cela ne rend pas la participation malhonnête. Une entreprise peut utiliser UCIe sur certaines frontières externes et conserver en interne une interface privée. Le transport de protocole commun peut coexister avec une topologie, une architecture mémoire ou une politique de gestion différenciées. L’adoption peut être en couches et sélective.

La mission de gouvernance est de maintenir la frontière commune utile pour les entreprises qui ne contrôlent pas toute la pile. La diversité du conseil aide, mais il manque une preuve publique complète du poids des contributions, des votes et de la résolution des conflits dans les groupes de travail. Des logos d’égale taille ne signifient pas un pouvoir de négociation égal.

Un standard peut réussir malgré les avantages privés des plus grands. Le test le plus dur est de savoir si un petit fournisseur peut construire un chiplet, certifier un profil limité, obtenir un accès au packaging et vendre dans plusieurs systèmes sans transférer à l’acheteur des risques juridiques et d’intégration ingérables.

Pour une interchangeabilité commerciale, l’acheteur a besoin de plus qu’une spécification de lien. Le composant exige des métadonnées fonctionnelles: fonction, protocoles et débits, détection, besoins de firmware, rapport de santé. Les développeurs de package ont besoin des limites électriques, thermiques, mécaniques et de puissance. Le logiciel a besoin d’une énumération et d’une administration stables. Les achats ont besoin de prix, de volumes, de cycle de vie, de garantie et de responsabilité.

UCIe peut fournir une partie de cela via la découverte des capacités, la déclaration de profil et la gérabilité. Il ne définit pas une API fonctionnelle complète ni un catalogue de produits universel, n’attribue pas la garantie et ne garantit pas la capacité de fonderie. Les contenus et événements parlent de l’objectif d’un marché, mais les preuves s’arrêtent avant une couche transactionnelle complète.

C’est pourquoi UCIe est à la fois important et insuffisant. Les standards créent les conditions des marchés, pas les marchés eux-mêmes. Fournisseurs, fonderies, fournisseurs d’outils et acheteurs doivent rendre l’interface investissable, testable et soutenable.

Dans un marché mature, la responsabilité est lisible. En cas de défaillance, on sait si la cause est le chiplet, le lien, l’assemblage, le firmware ou l’intégration, et le contrat attribue les coûts. Sans ces transferts, la modularité technique peut accroître le risque d’intégration de l’acheteur.

Les transferts de production détermineront la valeur d’UCIe

Le consortium est passé de la base de 2022 à l’automobile et aux options moins coûteuses en 2023, à la gérabilité et à la 3D en 2024, puis aux 64 GT/s, au raw étendu et à la gestion en 2025. En 2026, le travail public s’est davantage orienté vers la formation, l’implémentation et la validation que vers un nouveau numéro.

La séquence montre comment un jeune standard apprend où l’intégration se brise. Le lien physique a eu besoin de mappings de protocole et de classes de packaging. Le package a eu besoin de surveillance de santé, de gérabilité, de DFx et de 3D. Les débits plus élevés ont exigé recalibration, contrôle des performances et un sideband plus flexible. Chaque ajout a fait entrer une hypothèse privée dans le contrat technique commun.

La prochaine preuve viendra d’une autre classe d’évidences. Une conformité limitée doit montrer quels profils fonctionnent. Des fournisseurs indépendants doivent livrer des dies qui passent l’assemblage et la validation système. Le logiciel doit détecter et gérer sans développement sur mesure. Les contrats doivent attribuer la responsabilité des erreurs et du cycle de vie. Les petits fournisseurs doivent pouvoir participer sans rejeter toutes les incertitudes sur l’acheteur.

UCIe a déjà changé le débat sur les chiplets et placé un lien commun crédible sur une frontière auparavant propriétaire. De là naîtra un marché lorsque la première défaillance inter-fournisseurs pourra être diagnostiquée, attribuée et résolue sans repli vers un fournisseur intégré verticalement. C’est alors que l’interface prometteuse deviendra une infrastructure.