Résumé

  • UCIe fixe des règles communes pour la couche PHY, les adaptateurs, les protocoles et la gestion des liaisons die à die; la fonction des chiplets, le packaging et la responsabilité des fournisseurs restent hors de son mandat
  • De la version 1.0 à la version 3.0 se sont ajoutés des options de packaging moins coûteuses, la surveillance automobile, la prise en charge de la 3D, la gestion et un fonctionnement à 64 GT/s
  • La valeur de marché se mesurera à des profils de conformité reproductibles, à des produits de série multifournisseurs pris en charge et à une responsabilité claire en cas de défaillance entre 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 dont l’existence publique remontait à un peu plus de trois ans a publié sa troisième spécification majeure. Universal Chiplet Interconnect Express, ou UCIe, a ajouté des débits de 48 et 64 gigatransferts par seconde pour les canaux de packaging standard et avancé. Cette version a aussi accru la portée du chemin latéral à bas débit, étendu la transmission Raw continue et ajouté des contrôles de gestion. Le titre était la vitesse. L’enjeu le plus important était la tentative de traiter un package composé de plusieurs dies développés indépendamment comme un seul système administrable.

Cette distinction compte, car une liaison plus rapide n’est qu’un élément d’un produit à chiplets. Un acheteur doit encore savoir quelle fonction remplit chaque die, quelle puissance il exige, comment il est refroidi, quel logiciel le reconnaît, comment son firmware est mis à jour, ce qui se passe en cas de panne et quel fournisseur assume la garantie. UCIe crée des règles communes pour le transfert d’informations entre les dies et pour une partie de leur gestion. À lui seul, le standard ne transforme pas un ensemble de blocs de silicium sans relation en processeur achevé.

Le discours public du consortium vise un « écosystème ouvert de chiplets ». Cette ambition est utile, mais la formule peut donner l’impression qu’elle décrit un marché déjà constitué. Les documents publics examinés pour ce profil ne contenaient ni inventaire indépendant complet des packages UCIe multifournisseurs livrés, ni liste universelle de produits certifiés, ni catalogue de dies interchangeables. Ils montraient des spécifications, l’activité des membres, des formations à l’implémentation et des démonstrations.

Ce sont des étapes nécessaires, mais elles constituent une autre catégorie de preuves que des achats reproductibles et une production en série.

La question directrice est donc plus étroite que celle de savoir si les chiplets deviendront importants. Ils le sont déjà comme moyen de décomposer des systèmes complexes. L’enjeu est de déterminer quel degré de modularité une liaison commune peut créer lorsque le package qui l’entoure reste un produit d’ingénierie étroitement coordonné. UCIe peut devenir un langage commun à la frontière des dies tout en laissant propriétaires l’essentiel du système physique et des relations commerciales. L’interface doit donc être évaluée comme une chaîne de passages de relais, et non comme une promesse générale d’interchangeabilité.

Le terme interchangeabilité recouvre plusieurs vérifications. Premièrement, l’aspect électrique: l’émetteur, le récepteur et le canal du package peuvent-ils établir une liaison avec le même profil physique? Deuxièmement, le protocole: les deux côtés comprennent-ils le même mappage PCIe, CXL ou Raw? Troisièmement, l’exploitation: le package peut-il détecter, tester, surveiller et mettre à jour les dies au moyen de fonctions de gestion compatibles? Quatrièmement, la fonction et le logiciel: le chiplet fournit-il un comportement exploitable par le firmware, les pilotes et les applications?

Cinquièmement, le commerce: le composant est-il disponible avec des preuves de test, des volumes, une assistance et une garantie suffisants?

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 passages de relais 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 propres au produit. Le cinquième appartient aux fournisseurs, aux fonderies, aux entreprises de packaging et aux acheteurs.

Confondre ces niveaux mène à deux erreurs opposées. La première consiste à rejeter le standard parce qu’il ne crée pas un marché achevé, en négligeant la valeur de la suppression d’un obstacle physique et protocolaire. La seconde consiste à déclarer le marché achevé dès que deux dies établissent une liaison conforme, en ignorant toutes les décisions qui transforment cette liaison en système pouvant être pris en charge.

Une évaluation professionnelle doit préciser quelle promesse a été démontrée. Une démonstration PHY prouve moins qu’un couplage de protocoles. Un couplage de protocoles prouve moins qu’un package administrable sur tout son cycle de vie. Un package administrable prouve à son tour 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é.

Ces cinq niveaux expliquent aussi pourquoi les progrès réels ne ressemblent pas encore à des achats prêts à l’emploi. 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 passages de relais plus stricts, devenus reproductibles et donc dignes de confiance.

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

Une puce monolithique place les fonctions d’un système sur une grande pièce de silicium. Cela peut simplifier les communications, mais oblige toutes les fonctions à suivre le même plan de fabrication. À mesure qu’augmentent les coûts et les risques liés à la conception, aux masques et au rendement des nœuds avancés, intégrer chaque bloc sur un grand die devient coûteux et difficile. Les chiplets offrent une autre voie: logique de calcul, mémoire, E/S, fonctions analogiques, sécurité et accélérateurs peuvent être séparés, fabriqués avec les procédés qui leur conviennent et réunis dans un système en boîtier.

La division ne supprime pas la complexité; elle en déplace une partie du die vers le package. Chaque frontière exige signalisation, synchronisation, traitement des erreurs, alimentation, planification thermique, couverture de test et comportement visible par le logiciel. Un grand die monolithique peut perdre en rendement à mesure que sa surface croît; un package multidie peut perdre sa valeur parce qu’un seul die intégré est défectueux, marginal ou mal monté. Le concepteur du système gagne la possibilité de combiner des nœuds de procédé et de réutiliser des blocs, mais assume de nouvelles dépendances au niveau du package.

Le mot « modulaire » exige donc de la précision. Une carte électronique est notamment modulaire parce que ses composants ont des formes normalisées, des conventions électriques, des fonctions identifiables et des conditions commerciales mûres. Les fournisseurs publient des fiches techniques, les distributeurs détiennent des stocks et les intégrateurs connaissent les supports, connecteurs et limites de panne. Un chiplet placé dans un package avancé évolue dans un environnement physique beaucoup plus contraint et bien moins tolérant aux erreurs.

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

UCIe s’attaque à l’une des frontières récurrentes les plus difficiles: la liaison die à die courte et dense. Sa normalisation peut réduire la répétition du travail de conception d’interfaces et donner un objectif commun aux fournisseurs d’outils, d’IP et aux entreprises de systèmes. Les autres problèmes d’intégration ne disparaissent pas. La valeur réside dans la réduction d’une catégorie précise de développement bilatéral, non dans la transformation du package en éléments faiblement dépendants.

Sans interface commune, une entreprise pouvait répartir un système entre plusieurs dies tout en restant verticalement intégrée. La liaison pouvait être optimisée selon les hypothèses électriques, le protocole, le procédé de packaging et le flux de test d’un seul fournisseur. Cela offre de la liberté en matière de latence, de puissance et de surface, mais rend difficile la fourniture d’un die par un autre acteur tant que celui-ci ne connaît pas et n’implémente pas le contrat privé.

Le piège est autant économique que technique. Une entreprise de systèmes peut qualifier sa conception de fondée sur des chiplets sans proposer le module utile à d’autres. La réutilisation s’effectue entre ses propres générations de produits; le marché extérieur ne voit qu’un package fermé. L’architecture est modulaire à l’intérieur de l’entreprise, mais indivisible à l’extérieur.

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, les adaptateurs et les mappages de protocoles. Les fournisseurs continuent de décider des fonctions, du packaging et des caractéristiques visibles. La couche commune doit être assez légère pour servir des produits différents, mais assez détaillée pour que des implémentations indépendantes correspondent à la même spécification.

L’équilibre est difficile. Trop peu de prescriptions transforment chaque association en intégration particulière. Un excès de prescriptions peut figer des choix de conception, favoriser les premiers implémenteurs ou réduire la différenciation. L’expansion rapide d’UCIe, de la liaison et du protocole vers la gestion, le DFx et le packaging 3D, montre que la frontière initiale ne suffisait pas à un package opérationnel complet. Le consortium a dû normaliser davantage de passages de relais à mesure que le marché découvrait où des hypothèses privées empêchaient la réutilisation.

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

UCIe a débuté le 2 mars 2022 avec la version 1.0. Universal Chiplet Interconnect Express, Inc. a été constitué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 de la conception de processeurs, du cloud, de la fabrication en fonderie, de l’assemblage et des tests, de la mémoire 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 diversité est le principal capital institutionnel. Une liaison die à die ne devient pas utile grâce à un seul concepteur 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 utiliser les packages obtenus pour des charges de travail réelles.

Cette même liste réunit des incitations contradictoires. Un hyperscaler peut vouloir des blocs réutilisables tout en gardant privée l’architecture du système. Une fonderie peut prendre en charge la liaison commune tout en protégeant ses kits de conception, ses capacités et son savoir-faire de procédé. Un fournisseur établi de processeurs profite d’un choix plus large de fournisseurs, mais peut disposer de meilleures liaisons internes pour certains produits. Le consortium crée un espace où ces intérêts peuvent convenir d’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 prouve 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 acquis indépendamment ou 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érents choix de packaging.

Au conseil d’administration actuel, Debendra Das Sharma d’Intel est président du conseil, Cheolmin Park de Samsung président, Dong Wei d’Arm secrétaire et Lihong Cao d’ASE Group trésorier. D’autres administrateurs représentent Google Cloud, Qualcomm, Alibaba Cloud, Meta, TSMC, AMD et NVIDIA. Ces fonctions s’exercent par l’intermédiaire des organisations membres. Elles ne signifient ni propriété personnelle de la spécification ni qualité d’unique auteur.

La structure à but non lucratif donne un cadre juridique aux adhésions, aux règles de propriété intellectuelle et au travail technique. Promoteurs, contributeurs et adoptants disposent de formes de participation distinctes. Les copies publiques d’évaluation rendent l’architecture visible, mais les conditions distinguent l’étude de droits plus larges d’implémentation et d’adhésion. La licence est limitée à l’évaluation interne et ne présente pas la spécification comme 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 les 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 son portefeuille de brevets, ses relations de packaging ni son budget de validation.

UCIe est financé par les adhésions, mais les documents utilisés ne contiennent pas de données auditées sur les recettes, les réserves, les effectifs ou les dépenses par génération de spécification. Cela limite les affirmations sur la taille financière de l’organisation, non celles concernant les intérêts économiques qui entourent le standard.

Le travail coûteux se déroule chez les membres et les fournisseurs. Les entreprises de semi-conducteurs développent contrôleurs et dies, les fournisseurs de PHY des IP réutilisables, les sociétés d’EDA la modélisation et la vérification, et les fonderies et entreprises d’assemblage les procédés de packaging. Les entreprises de systèmes paient l’intégration, la qualification et les logiciels. La liaison commune 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 droits et risques. Promoteurs et contributeurs travaillent sur la technique dans le cadre d’accords de consortium. L’évaluation publique apporte de la visibilité; les droits d’implémentation et la protection de la propriété intellectuelle dépendent des accords concernés. Il en résulte une référence technique ouverte entourée d’une économie d’adhésion structurée.

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 un échec classique de produit, mais la possibilité que les entreprises supportant les 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 large interopérabilité.

La spécification réutilise des protocoles établis et laisse les choix de packaging aux fabricants

La première version n’a pas tenté de réinventer chaque transaction de niveau supérieur. Elle a défini une liaison physique die à die et un adaptateur pour des protocoles établis, notamment PCI Express et Compute Express Link, ainsi que pour le trafic Raw. Une nouvelle frontière dans le package a ainsi été reliée à des modèles logiciels et de périphériques déjà connus des concepteurs de systèmes.

PCIe fournit une sémantique familière pour les périphériques hôtes et les E/S. CXL ajoute une sémantique cohérente de mémoire et de cache dans les systèmes compatibles. UCIe ne remplace aucune de ces organisations ou spécifications; il permet à leurs paquets et à leur signification de circuler entre les dies d’un même package. Une fonction peut se trouver hors du die principal tout en utilisant l’énumération et les logiciels existants.

L’avantage est la continuité, non la compatibilité automatique. Le package exige toujours firmware, énumération, politique de mémoire, traitement des erreurs et logiciel pour le protocole choisi. Deux liaisons électriquement compatibles avec UCIe peuvent transporter des messages PCIe, CXL ou Raw. Un système d’exploitation connaissant une classe de périphériques ne comprend pas nécessairement un autre chiplet.

La réutilisation d’une sémantique mûre place aussi UCIe dans un réseau de dépendances. Les évolutions de PCIe ou de CXL peuvent influencer les futurs mappages. Le concepteur du package doit qualifier la liaison et le protocole supérieur. La conformité du transport ne corrige ni une erreur de cohérence ni l’absence d’un pilote. Le standard rend un contrat logiciel existant portable au-delà d’une nouvelle frontière physique; il ne le rend pas trivial.

L’architecture UCIe est organisée en couches. La couche physique traite le canal électrique court. Un adaptateur die à die gère la liaison et fait l’interface avec le trafic des protocoles supérieurs. Au-dessus se trouvent des mappages qui donnent aux bits transportés une signification logicielle. Cette séparation est centrale pour la portabilité: la même architecture de liaison peut transporter différents types de trafic sans lier un protocole à une technique de packaging.

L’adaptateur est plus qu’une enveloppe passive. Les recherches décrivent la gestion de liaison, les erreurs, les reprises et l’adaptation des protocoles. Une frontière entre dies ne doit pas se comporter comme un fil peu fiable et invisible pour le logiciel. Le package a besoin de mécanismes définis pour l’établissement de la liaison, la déclaration des capacités et le confinement des erreurs avant qu’une couche supérieure puisse faire confiance au chemin.

La séparation en couches crée aussi des points de divergence. Un PHY peut ne prendre en charge qu’un débit ou une classe. Un adaptateur peut disposer d’autres fonctions facultatives de fiabilité et de gestion. Un moteur peut prendre en charge PCIe, mais pas CXL. Un fournisseur de systèmes peut n’exposer que la partie nécessaire. « UCIe » désigne donc une famille de spécifications, non un ensemble uniforme de fonctions.

Pour les acheteurs professionnels, la question 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 mappage de protocole, quelle fonction de gestion et quelles conditions de test il implémente. Un standard devient une infrastructure opérationnelle lorsque ces détails peuvent être déclarés, testés et comparés. Jusque-là, l’affirmation générale en dit moins qu’elle ne le laisse croire.

L’alignement des versions crée sa propre charge d’intégration. Un fournisseur de systèmes peut qualifier un contrôleur pour une génération et une classe de packaging UCIe, tandis qu’un nouveau chiplet arrive avec des fonctions facultatives ultérieures. La découverte et la négociation des capacités déterminent l’ensemble commun, mais ne peuvent créer une fonction absente d’un côté. Les équipes produit ont donc besoin d’une intersection prise en charge: débits, protocoles, fonctions de gestion et comportement de repli déclarés et stables au fil des révisions du firmware et du silicium.

Découvrir une divergence après avoir fixé les dies dans un package coûte bien plus cher que sur un connecteur de carte.

La portabilité logicielle suit le même schéma. Les mappages PCIe et CXL peuvent préserver des modèles de périphériques familiers, tandis que le mode Raw ou des données de gestion propres à un fournisseur réintroduisent du travail spécifique. Un package peut s’énumérer correctement tout en exigeant de nouveaux pilotes, firmwares, descriptions topologiques ou règles d’erreur. Le test pratique consiste à savoir si un contrat logiciel survit au changement de fournisseur et à la prochaine révision du produit, non si le logiciel a pu voir le die une fois.

UCIe fournit le transport et le cadre des capacités; la désignation fonctionnelle 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, moins dense et moins coûteux. UCIe-A vise le packaging avancé, avec un pas de microbosses plus serré et une plus forte densité de bande passante. Une même famille de spécifications peut ainsi servir des produits qui ne justifient pas les mêmes coûts d’interposeur, de pont ou de liaison.

C’est une décision commerciale importante. Un standard limité au packaging le plus coûteux aurait un fort potentiel, mais un marché réduit. Un standard limité aux substrats organiques ordinaires pourrait ne pas atteindre la densité nécessaire aux systèmes informatiques avancés. Les deux classes reconnaissent que l’interopérabilité doit fonctionner sous des contraintes physiques et économiques différentes.

Les frontières ne disparaissent pas. Packages standard et avancés ont des budgets de canal, cartes de microbosses et tolérances différents. Une conception UCIe-A ne peut être transposée sans modification à UCIe-S. Interposeur, pont, substrat organique, liaison hybride ou autres constructions restent des choix du fournisseur du package. Les règles des fonderies et des OSAT restent déterminantes.

Il en résulte une liberté de choix limitée. UCIe crée un vocabulaire commun pour deux environnements et permet une implémentation propre au procédé. Il ne garantit pas qu’un chiplet destiné à l’un soit rentable, 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 voie de 32 à 48 et 64 GT/s pour UCIe-S et UCIe-A. Des débits supérieurs peuvent accroître la bande passante totale sans augmenter proportionnellement le nombre de connexions sur le bord des dies. C’est intéressant pour les packages d’IA et de calcul haute performance, où logique de calcul, mémoire et accélérateurs échangent de grands volumes de données dans un périmètre limité.

Le débit d’une spécification n’est pas un résultat mesuré sur un produit. La bande passante utile dépend du nombre de voies, du codage, des surcharges, de la qualité du canal, du contrôleur et du profil de trafic. L’énergie par bit dépend de l’implémentation et des conditions; le rendement dépend de la possibilité de fabriquer et de tester le canal complet de façon répétée. La présence de 64 GT/s dans le document prouve que le mode est défini, pas qu’il fonctionne économiquement dans chaque package.

Le mode plus rapide durcit la vérification. L’intégrité du signal, les marges de synchronisation, le routage et la thermique deviennent plus difficiles à forte densité. Une démonstration peut réussir alors que les produits de série rencontreront d’autres conditions de vieillissement, de tension et de température. Formations et démonstrations indiquent des progrès, mais ne constituent pas une preuve universelle de fiabilité sur le terrain.

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

La gestion est devenue aussi importante que la bande passante

Les canaux à haut débit transportent la charge utile, mais un package multidie a aussi besoin d’un chemin de contrôle et de gestion plus lent. UCIe comprend un mécanisme latéral distinct du chemin de données principal. La version 3.0 a porté sa distance définie jusqu’à 100 millimètres dans les conditions pertinentes, ce qui permet un placement plus souple des composants gérés.

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

Cette portée accrue ne promet pas que le canal principal à 64 GT/s puisse suivre la même géométrie. Le chemin latéral et le chemin de données ont des objectifs et des exigences électriques distincts. La gestion peut parcourir une distance interne plus longue tandis que les liaisons rapides restent courtes et denses.

Sur le plan systémique, le chemin latéral montre que l’intégration des chiplets ne s’arrête pas au transfert de données. Un package a besoin d’une couche opérationnelle. Le standard peut créer un chemin commun, mais les fournisseurs continuent de définir de nombreux états, politiques et remèdes derrière les messages. Un système nerveux commun ne signifie pas que chaque organe fournit le même diagnostic.

UCIe 1.1 est paru le 8 août 2023 et a ajouté la surveillance de l’état pour l’automobile ainsi que des options destinées à des packages moins coûteux. Cette version était rétrocompatible au sein de la famille et a élargi la cible au-delà des packages hautes performances les plus onéreux.

Les systèmes automobiles accordent à la surveillance, à la fiabilité et à la longévité un poids différent de celui des accélérateurs à cycle court. L’intégration de données d’état au standard reconnaît que les défauts latents et le diagnostic sur le terrain peuvent compter autant que la bande passante maximale. Les options moins coûteuses répondaient à la pression économique opposée: l’interopérabilité reste limitée si elle exige un packaging haut de gamme.

La présence d’une fonction dans la spécification ne prouve pas son adoption sectorielle. Les plateformes automobiles, cycles de qualification et responsabilités des fournisseurs échappent au contrôle d’UCIe. L’importance de la version 1.1 tient à son orientation. Le consortium a reconnu tôt qu’une liaison commune à haut débit avait besoin de souplesse dans le packaging et de signaux de cycle de vie pour servir plus qu’un segment étroit.

Le même schéma s’est poursuivi avec les versions 2.0 et 3.0. Chaque génération a normalisé une partie supplémentaire de la charge d’intégration jusque-là gérée en privé. La spécification s’est étoffée parce que les problèmes de marché les plus difficiles se trouvaient à la fois dans et autour de la liaison initiale. Avec la deuxième révision majeure, la tâche est passée de l’établissement de la liaison à l’exploitation du package complet pendant son cycle de vie.

UCIe 2.0 a été publié le 6 août 2024 et a ajouté une architecture système de gestion ainsi que la prise en charge du packaging 3D. Il traitait la détection, les tests, la télémétrie, les opérations de firmware, le débogage et le contrôle du cycle de vie sur plusieurs dies. Cela comprenait un Management Transport Protocol et une architecture pour la conception en vue des tests, du débogage et de la télémétrie, souvent regroupés sous le terme DFx.

La signification de l’interopérabilité a ainsi changé. Un package peut correctement transmettre les données tout en restant ingérable. Les équipes de fabrication doivent tester les dies avant et après assemblage. Les équipes firmware doivent reconnaître les versions et coordonner les mises à jour. Les opérateurs ont besoin de télémétrie et d’isolation des erreurs. Les concepteurs de systèmes doivent savoir si un composant défaillant peut être contenu sans faire tomber tout le package.

L’architecture commune fournit à 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 d’état détaillées, un autre seulement des états minimaux. Un fournisseur de systèmes peut permettre des mises à jour coordonnées ou limiter le package à des images approuvées. Le standard transporte les messages de gestion entre fournisseurs, mais ne supprime pas les frontières entre leurs politiques.

Le test pratique porte sur la responsabilité. Si la télémétrie signale une liaison marginale, qui établit le diagnostic: le fournisseur du die, le partenaire d’assemblage ou l’entreprise de systèmes? Si une mise à jour modifie le comportement, qui requalifie le package complet? UCIe 2.0 a créé un espace technique commun pour ces questions, pas une réponse contractuelle.

La conception en vue des tests, le débogage, la télémétrie et les fonctions connexes du cycle de vie peuvent sembler relever de l’usine. Dans un système multidie, elles font partie de l’architecture du produit. Un package peut contenir des dies issus de procédés différents, produits par plusieurs entreprises et dotés de méthodes de test internes distinctes. Après assemblage, le système doit déterminer si une perturbation vient d’un die, de la liaison, du canal du package, d’une alimentation partagée ou du logiciel de coordination.

L’architecture DFx d’UCIe vise à donner une base commune à ces fonctions. Un chemin de gestion transporte les données d’état et de diagnostic. Tests et débogage peuvent être conçus autour d’un modèle commun du package plutôt que d’exiger une connexion propriétaire pour chaque association. Cela réduit les passages de relais particuliers et facilite la conservation des preuves entre fabrication et exploitation.

Le standard ne peut créer une observabilité qu’un chiplet n’implémente pas, ni garantir qu’un signal rapporté désigne la cause. Un die peut signaler une erreur provoquée par du bruit d’alimentation ailleurs. Une liaison peut se réentraîner pour contourner un état marginal sans révéler sa proximité avec la panne. Une entreprise d’assemblage peut observer un problème de rendement impossible à reproduire dans le laboratoire du fournisseur du système. 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 offrant une meilleure prise en charge du cycle de vie. L’architecture commune ouvre un chemin de gestion; sa qualité reste un choix de produit.

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

UCIe 2.0 a également pris en charge le packaging 3D, notamment les dies empilés verticalement et les connexions très courtes et denses. L’empilement peut rapprocher logique de calcul et mémoire, accroître la densité de bande passante et réduire la surface. Il couple aussi plus étroitement chaleur, contraintes mécaniques et rendement que les configurations 2D ou 2,5D.

Un standard d’interface aide à définir ce qui traverse la frontière verticale. Il ne définit ni le procédé de liaison, ni l’empilement thermique, ni le réseau de distribution électrique, ni l’ordre dans lequel les dies fonctionnels sont validés avant l’assemblage final. Ces décisions restent entre les mains des fonderies, des fournisseurs d’assemblage et de test, des concepteurs de puces et des entreprises de systèmes.

Cela devient particulièrement visible avec la réparation. La modularité au niveau de la carte suggère le remplacement; un package multidie à liaison dense peut ne permettre aucun remplacement pratique d’un die interne sur le terrain. Le système de gestion peut identifier le composant défectueux tandis que le remède commercial reste le remplacement du package entier. Un meilleur diagnostic réduit le temps d’enquête, 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 reconnaissables de communication et de gestion lorsque la géométrie change. La tâche de fabrication environnante devient plus exigeante, non plus facile.

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

Raw élargit l’éventail des systèmes utilisables et expose la séparation entre interopérabilité électrique et fonctionnelle. Deux fournisseurs peuvent respecter les mêmes exigences de canal tout en définissant au-dessus du transport Raw un cadrage, un contrôle de flux ou une signification applicative différents. La liaison connecte; les fonctions exigent toujours un accord distinct.

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

Raw peut donc produire deux effets opposés: davantage de types de chiplets sur la même liaison, mais aussi des îlots fonctionnels privés au-dessus. La question décisive est de savoir si les implémenteurs créent des profils Raw communs et publient assez d’informations pour une intégration indépendante.

Le secteur des semi-conducteurs regorge de sigles d’interconnexion qui semblent facilement désigner des concurrents directs. 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 à l’intérieur du package et les mappages pour ces protocoles.

Cette organisation en couches explique la progression rapide d’UCIe. Les systèmes d’exploitation et fabricants de périphériques n’ont pas dû adopter une signification entièrement nouvelle pour chaque transaction; le standard a transporté une sémantique disposant déjà de logiciels, de vérification et d’organisations sectorielles.

UCIe hérite ainsi des évolutions et de la complexité de la couche supérieure. Un package compatible CXL exige toujours une conception de système cohérente. Un chiplet mappé sur PCIe exige énumération, pilotes et traitement des erreurs. Une erreur du protocole supérieur ne devient pas une erreur UCIe simplement parce que le paquet franchit une frontière entre dies.

Cette relation peut être comprise comme une pile de responsabilités. UCIe répond à la manière dont bits et paquets de protocole traversent la frontière du package dans des conditions définies. PCIe ou CXL répondent à ce que signifient nombre de ces paquets. Le firmware et le logiciel d’exploitation déterminent comment l’ensemble du système devient visible et utilisable. Aucune couche ne peut à elle seule revendiquer le résultat des trois.

Un canal à haut débit doit établir que ses deux côtés peuvent communiquer dans les conditions électriques réelles. L’analyse de la spécification décrit la négociation des capacités, l’entraînement de la liaison, le recalibrage en fonctionnement et la limitation du débit. UCIe 3.0 a ajouté un recalibrage côté émetteur et des améliorations liées à la puissance afin de compenser les variations de procédé, de tension, de température et d’exploitation.

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

Un entraînement réussi reste toutefois un résultat limité. Il prouve la liaison dans les conditions de test, non sa fiabilité pour chaque charge, chaque cycle thermique et toute sa durée de vie. Le recalibrage peut corriger une dérive sans agir sur un autre mécanisme de panne. La limitation peut maintenir le fonctionnement au prix des performances.

Il en résulte une obligation de transparence pour les acheteurs. Une fiche produit doit distinguer le débit maximal de la spécification, le débit validé dans le package, les conditions de recalibrage et le comportement lorsque la marge devient insuffisante. Une liaison adaptative peut gérer le changement, mais ne garantit pas une fiabilité non mesurée.

Les preuves de conformité doivent devenir assez précises pour guider les achats

Une étiquette ne peut décrire toutes les implémentations UCIe. Une déclaration de conformité complète doit au minimum préciser la génération, la classe de packaging, le débit, l’organisation des voies, le mappage de protocole, les fonctions de gestion facultatives et les conditions de test. Deux produits peuvent tous deux implémenter UCIe sans disposer d’un terrain commun exploitable au niveau de performance recherché.

Les programmes d’interconnexion mûrs lient 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 existait des travaux d’interopérabilité, des sommets, des webinaires et des démonstrations de contrôleurs et de PHY, mais les documents ne contenaient pas de liste publique complète de produits certifiés.

Un programme utile doit tester davantage que la mise en route la plus simple. Le comportement en cas d’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 du canal comptent. Sans preuve, le résultat d’une association ne doit pas être extrapolé à 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émonstrations des membres peuvent montrer la collaboration d’outils et d’interfaces indépendants. La qualification en série exige reproductibilité, volume, conditions d’exploitation et responsabilité clarifiée en cas de défaillance ultérieure.

Cette distinction protège les acheteurs comme le consortium. Une étiquette UCIe trop large crée des déceptions concernant des problèmes que le standard n’a jamais été conçu pour prévenir. Un profil précis rend la performance réelle visible. L’obstacle restant est la preuve: les acheteurs doivent connaître exactement la configuration testée et ses limites.

Depuis la première version, l’activité est passée de l’explication à l’implémentation. Des membres ont annoncé contrôleurs, IP PHY, plateformes de vérification et travaux de packaging. Des événements ont présenté des démonstrations UCIe et des sessions sur l’intégrité du signal, le packaging avancé et l’interopérabilité. Les documents de 2025 ont interprété ces éléments comme le signe d’une adoption croissante.

Une démonstration répond à une question ciblée: ce contrôleur communique-t-il avec ce PHY? La plateforme de test détecte-t-elle une erreur définie? Le canal atteint-il le débit cible en laboratoire? Ce sont des questions utiles, qui réduisent l’incertitude d’implémentation et révèlent les divergences d’interprétation de la spécification.

Un package de série répond à davantage de questions: plusieurs fournisseurs livrent-ils à temps des dies fonctionnels? L’assemblage atteint-il les objectifs de rendement et de performance? Le firmware peut-il mettre à jour tous les composants en sécurité? Le logiciel reste-t-il portable entre les révisions? Qui remplace le système en cas de défaillance intermittente d’un die marginal? Une démonstration fournit une partie des preuves, pas la réponse complète.

Les documents publics ne contiennent pas d’inventaire complet des packages multifournisseurs livrés. L’affirmation prudente est que l’écosystème développe sa capacité d’implémentation. Les preuves disponibles ne suffisent pas à établir l’existence d’un marché universel.

Un intégrateur ne peut évaluer un chiplet uniquement selon la capacité de sa liaison à démarrer. Le die doit être considéré comme fonctionnel pour sa mission, sa fenêtre de procédé et son cycle de vie, avec des preuves allant du wafer au système en passant par l’assemblage. Si un composant est défectueux après intégration, les autres dies et le travail de packaging peuvent être perdus avec lui.

Les preuves de dies fonctionnels connus sont des exigences commerciales et industrielles. Les fournisseurs doivent convenir de ce qui a été testé, des marges applicables, de la présentation des résultats et de la partie qui assume la perte en cas de défaillance globale. La gestion et le DFx d’UCIe peuvent transporter les données de test et de télémétrie, mais ils ne peuvent ni certifier le fonctionnement interne de chaque die ni attribuer la responsabilité.

C’est un avantage des packages verticalement intégrés. Une entreprise peut contrôler la conception des dies, les limites de test, l’assemblage et la garantie. Un package multifournisseur doit convertir les passages de relais privés en preuves et contrats explicites.

La couche de marché manquante est peu spectaculaire, mais elle détermine si la modularité atteint les petits fournisseurs. La liaison électrique commune réduit un obstacle. Les garanties relatives aux dies fonctionnels déterminent si un acheteur peut risquer le reste du package sur un composant inconnu.

Sécurité, garantie et logiciel détermineront la formation d’un marché

Un package multifournisseur crée une frontière de confiance exceptionnellement étroite. Les chiplets échangent d’importants volumes 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 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 sur la gestion peuvent prendre en charge 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 thème continu. Ces mécanismes ne définissent toutefois pas une architecture complète de sécurité du package. Identité des appareils, démarrage sécurisé, provenance du firmware, attestation, isolation, gestion des clés et assurance fournisseur restent des responsabilités 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, non 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 future génération pourra définir davantage de fonctions de sécurité; leur calendrier et leur forme ne sont pas établis. Aujourd’hui, « conforme à UCIe » n’est pas une certification de sécurité du package. Les acheteurs ont besoin d’un modèle de confiance propre à chaque fournisseur et à l’ensemble du système.

UCIe est présenté comme un standard industriel ouvert, et ses spécifications peuvent être demandées publiquement sous conditions d’évaluation. Cela permet l’étude, la conception commune d’outils et les discussions sur la compatibilité sans propriétaire unique de l’interface.

Le reste de la chaîne d’approvisionnement peut demeurer très concentré. Fabrication avancée des wafers, liaison hybride, interposeurs, assemblage, équipements de test et EDA proviennent d’un petit nombre d’entreprises et de régions. Les contrôles à l’exportation et les politiques industrielles influencent l’accès aux nœuds, aux outils et à l’IP. Une liaison commune ne crée ni nouvelle fonderie ni nouvelle ligne de packaging.

Un standard ouvert n’impose pas une implémentation ouverte. Contrôleur, PHY, chiplet, firmware ou kit de conception peuvent rester propriétaires. L’accord d’évaluation distingue la lecture de la licence d’implémentation. Une entreprise peut prendre en charge la liaison commune tout en conservant le contrôle au-dessus et au-dessous.

Cela peut constituer la force réaliste d’UCIe. Il n’a pas besoin d’être open source pour réduire le travail bilatéral. Le risque est rhétorique: l’ouverture d’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 avec précision, les enjeux deviennent la confiance, l’assistance commerciale et la répartition du risque d’intégration.

Les promoteurs donnent sa crédibilité à UCIe. Ils apportent la technologie, construisent les interfaces, qualifient les packages et créent la demande. Ils possèdent aussi les meilleures solutions de remplacement à un marché ouvert. Les grandes entreprises de processeurs, de cloud et de fonderie peuvent employer des chiplets, liaisons internes et processus de packaging propriétaires lorsque cela leur apporte un avantage.

Cela ne rend pas leur participation insincère. Une entreprise peut utiliser UCIe à certaines frontières externes tout en conservant une interface privée en interne. Un transport commun des protocoles peut coexister avec une topologie, une architecture mémoire ou une politique de gestion différenciée. L’adoption peut être stratifiée et sélective.

La tâche de gouvernance consiste à maintenir la frontière commune utile aux entreprises qui ne contrôlent pas toute la pile. La diversité du conseil y contribue, mais il manque une preuve publique complète du poids des contributions, des votes et du règlement des conflits dans les groupes de travail. Des logos de même 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 plus difficile consiste à savoir si un petit fournisseur peut construire un chiplet, démontrer un profil limité, obtenir un accès au packaging et vendre à plusieurs systèmes sans transférer à l’acheteur des risques juridiques et d’intégration ingérables.

L’interchangeabilité commerciale exige davantage qu’une spécification de liaison. Le composant a besoin de métadonnées fonctionnelles: rôle, protocoles et débits, détection, besoins de firmware, signalement de l’état. Les concepteurs du package ont besoin de limites électriques, thermiques, mécaniques et de puissance. Le logiciel exige une énumération et une gestion stables. Les achats exigent prix, volume, cycle de vie, garantie et responsabilité.

UCIe peut en fournir une partie par la découverte des capacités, la déclaration des profils et la gestion. Il ne définit ni API fonctionnelle complète ni catalogue universel de produits, n’attribue pas les garanties et ne garantit aucune capacité de fonderie. Les documents et événements évoquent l’objectif d’un marché, mais les preuves s’arrêtent avant une couche transactionnelle complète.

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

Dans un marché mûr, la responsabilité est lisible. En cas de panne, il est clair si la cause vient du chiplet, de la liaison, de l’assemblage, du firmware ou de l’intégration, et le contrat attribue les coûts. Sans ces passages de relais, la modularité technique peut accroître le risque d’intégration de l’acheteur.

Les passages de relais en 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 gestion et à la 3D en 2024, puis à 64 GT/s, à l’extension de Raw et à davantage de gestion en 2025. En 2026, les travaux publics ont davantage porté sur la formation, l’implémentation et la validation que sur un nouveau numéro de version.

Cette suite montre comment un jeune standard apprend où l’intégration échoue. La liaison physique avait besoin de mappages de protocoles et de classes de packaging. Le package avait besoin de surveillance de l’état, de gestion, de DFx et de 3D. Les débits supérieurs exigeaient recalibrage, contrôle de la puissance et chemin latéral plus souple. Chaque ajout a intégré une hypothèse privée au contrat technique commun.

La prochaine preuve appartiendra à une autre catégorie. Une conformité limitée doit montrer quels profils fonctionnent. Des fournisseurs indépendants doivent livrer des dies qui passent l’assemblage et la validation du système. Le logiciel doit les détecter et les gérer sans nouveau développement spécifique. Les contrats doivent attribuer la responsabilité des défaillances et du cycle de vie. Les petits fournisseurs doivent pouvoir participer sans transférer toutes les incertitudes à l’acheteur.

UCIe a déjà transformé le débat sur les chiplets en plaçant une liaison commune crédible à une frontière auparavant propriétaire. La naissance éventuelle d’un marché se verra lorsque la première défaillance entre fournisseurs pourra être diagnostiquée, attribuée et corrigée sans retour à un fournisseur verticalement intégré. Une interface prometteuse deviendra alors une infrastructure.