En bref

  • UCIe fixe des règles communes pour la couche physique, l’adaptateur, les protocoles et la gestion de la liaison entre puces, tandis que la fonction des puces, l’architecture du boîtier et la responsabilité des fournisseurs restent hors de son champ.
  • De la version 1.0 à la version 3.0, la norme s’est étendue aux options de boîtiers moins coûteuses, à la surveillance automobile, aux architectures 3D, à la gestion et au fonctionnement à 64 GT/s.
  • Sa valeur commerciale se manifestera par des profils de conformité pouvant être retestés, des boîtiers de production multifournisseurs réellement pris en charge et une responsabilité claire lorsqu’une défaillance implique plusieurs fournisseurs.

Le passage à 64 GT/s a transformé la course à la vitesse en question de système

Le 5 août 2025, un consortium de normalisation apparu publiquement à peine plus de trois ans auparavant a publié la troisième version majeure de sa spécification. Universal Chiplet Interconnect Express, connue sous le sigle UCIe, a ajouté les débits de 48 et 64 gigatransferts par seconde aux deux classes de canaux destinées aux boîtiers standard et avancés. Cette version a également allongé la portée de la voie auxiliaire à bas débit, étendu la transmission brute continue et ajouté des contrôles de gestion.

La vitesse a fait la une, mais l’enjeu principal consistait à faire fonctionner comme un seul système administrable un boîtier réunissant des puces de silicium conçues indépendamment.

Cette distinction importe, car une liaison plus rapide n’est qu’un élément d’un produit fondé sur des chiplets. L’acheteur doit encore connaître la fonction de chaque puce, sa consommation, son refroidissement, les logiciels qui la détectent, la méthode de mise à jour de son micrologiciel, les conséquences de sa défaillance et le fournisseur responsable de la garantie. UCIe fournit des règles communes pour transporter l’information entre les puces et pour une partie des opérations de gestion entourant ce transport. Elle ne transforme toutefois pas, à elle seule, un assortiment disparate de silicium en processeur complet.

Le discours public du consortium évoque un « écosystème ouvert de chiplets ». Cette formule exprime utilement une ambition, mais elle pourrait être prise à tort pour la description d’un marché déjà établi. Les éléments publics examinés pour ce dossier ne comportaient ni dénombrement indépendant complet des boîtiers multifournisseurs réellement expédiés, ni liste mondiale de produits certifiés, ni guide permettant à un concepteur de sélectionner des puces interchangeables. Ils comprenaient des spécifications, l’activité des membres, des formations pratiques et des démonstrations.

Ces étapes sont nécessaires, mais elles ne constituent pas la même preuve que des achats et une production reproductibles.

La question déterminante 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. Il s’agit plutôt de déterminer quel degré de modularité une liaison commune peut créer lorsque le boîtier qui l’entoure demeure un produit d’ingénierie fortement interdépendant. UCIe peut devenir le langage commun aux frontières des puces tout en laissant propriétaires l’essentiel du système physique et de la relation commerciale. Il vaut donc mieux évaluer l’interface comme une chaîne de livrables que comme une promesse vague d’interchangeabilité.

Le mot « interchangeabilité » condense cinq tests différents. Le premier est électrique: l’émetteur, le récepteur et le canal du boîtier peuvent-ils établir une liaison dans le même profil physique? Le deuxième concerne le protocole: les deux extrémités comprennent-elles le même mappage PCIe, CXL ou du mode brut? Le troisième est opérationnel: le boîtier peut-il détecter, tester, surveiller et mettre à jour les puces au moyen de fonctions de gestion compatibles? Le quatrième est fonctionnel et logiciel: le chiplet présente-t-il un comportement que les micrologiciels, pilotes et applications savent exploiter?

Le cinquième est commercial: l’acheteur peut-il obtenir la pièce avec des preuves de test, des volumes, une assistance et une garantie suffisants pour l’intégrer à un produit?

UCIe traite directement les deux premières couches et s’étend de plus en plus à la troisième. Elle réduit la dépendance de la négociation électrique, du transport des protocoles et de la mise à disposition des fonctions de gestion envers une conception bilatérale spécifique. La quatrième couche relève en partie de PCIe, de CXL et des logiciels propres au produit. La cinquième appartient aux fournisseurs, aux fonderies, aux entreprises de boîtiers et aux acheteurs.

Confondre ces couches produit deux erreurs opposées. La première consiste à rejeter la norme parce qu’elle ne crée pas un marché complet, en négligeant ainsi la valeur de la suppression d’un obstacle physique et protocolaire qui se répète dans chaque projet. La seconde consiste à déclarer le marché achevé dès que deux puces établissent une liaison compatible, sans tenir compte de toutes les décisions nécessaires pour en faire un système pouvant être pris en charge.

Une évaluation professionnelle doit préciser quelle promesse a été démontrée. Une démonstration de l’interface physique est moins probante qu’une association protocolaire; celle-ci l’est moins qu’un boîtier administrable pendant tout son cycle de vie; ce dernier l’est à son tour moins qu’un composant remplaçable sans nouveaux logiciels ni contrats. Ces niveaux ne constituent pas une critique d’UCIe, mais la manière la plus claire d’expliquer ce que le consortium contrôle et ce qu’il laisse au marché.

Cette lecture en cinq couches explique aussi pourquoi les progrès peuvent être réels sans ressembler encore à un achat prêt à l’emploi. Une nouvelle version peut renforcer les trois premières promesses tandis que les quatrième et cinquième couches mûrissent lentement. Le marché des chiplets ne naîtra pas d’une seule annonce: il se construira à partir de livrables plus étroits devenant assez reproductibles pour inspirer confiance.

Les chiplets déplacent la complexité du silicium vers le boîtier

Une puce monolithique place les fonctions du système sur une seule grande pièce de silicium. Cela peut simplifier les communications entre fonctions, mais les contraint à un même plan de fabrication. Alors que la conception, les masques et le rendement deviennent plus exigeants aux nœuds avancés, réunir tous les blocs sur une grande puce devient coûteux et difficile. Les chiplets offrent une autre voie: le calcul, la mémoire, les entrées-sorties, les fonctions analogiques, la sécurité et les accélérateurs peuvent être séparés, chacun fabriqué avec la technologie appropriée, puis réunis dans un système en boîtier.

La décomposition ne supprime pas la complexité; elle en déplace une partie de la puce vers le boîtier. Chaque frontière exige des signaux, une synchronisation, une gestion des erreurs, une distribution de l’énergie, une planification thermique, une couverture de test et un comportement visible par les logiciels. Le rendement d’une grande puce monolithique peut diminuer avec sa surface, tandis qu’un boîtier multipuce peut perdre toute sa valeur parce qu’un seul composant est défectueux, marginal ou mal assemblé.

Le concepteur gagne la possibilité de combiner les nœuds et de réutiliser les blocs, mais accepte un nouvel ensemble de dépendances au niveau du boîtier.

Le mot « modularité » exige donc de la précision. Un circuit imprimé est en partie modulaire parce que ses composants possèdent des formes physiques, des normes électriques, des fonctions détectables et des conditions commerciales mûres. Les fournisseurs publient des fiches techniques, les distributeurs détiennent des stocks et les intégrateurs comprennent les supports, les connecteurs et les limites de défaillance. Un chiplet placé dans un boîtier avancé fonctionne dans un environnement plus contraint, avec une marge d’erreur réduite.

Il peut partager avec son voisin l’énergie, la chaleur, la gestion et des canaux rapides, sans pouvoir être inspecté ou remplacé après l’assemblage comme un composant monté sur une carte.

UCIe s’attaque à l’une des frontières récurrentes les plus difficiles: la liaison courte et dense entre les puces. Sa normalisation peut réduire la reconception répétée des interfaces et donner une cible commune aux fournisseurs d’outils, de propriété intellectuelle et de systèmes. Elle n’efface toutefois pas les autres problèmes d’intégration. La valeur de la norme consiste à réduire une catégorie précise d’ingénierie bilatérale, non à transformer le boîtier en un assemblage lâche de pièces indépendantes.

Avant l’existence d’une interface commune, une entreprise pouvait diviser un système en plusieurs puces tout en restant intégrée verticalement. Elle pouvait concevoir la liaison selon les hypothèses électriques, le protocole, le procédé de boîtier et le flux de test propres à un seul fournisseur. Cela permettait d’optimiser la latence, l’énergie et la surface pour un produit donné, mais rendait difficile l’offre d’une puce par un autre fournisseur sans apprentissage et mise en œuvre d’un contrat spécifique.

Le piège est autant économique que technique. Une entreprise peut présenter son produit comme fondé sur des chiplets sans proposer l’unité utile à d’autres acteurs. La réutilisation intervient entre ses propres générations de produits, tandis que le marché extérieur ne voit qu’un boîtier fermé. L’architecture est modulaire à l’intérieur des frontières de l’entreprise et indivisible à l’extérieur.

Les fondateurs d’UCIe ont cherché à créer une frontière commune sans imposer le système entier. Le consortium définit le comportement de la couche physique, de l’adaptateur et des mappages de protocoles. Le fournisseur conserve le choix de la fonction du chiplet, de la méthode de boîtier et des caractéristiques exposées. La couche commune doit être assez mince pour servir des produits différents et assez détaillée pour que des implémentations indépendantes respectent une même spécification.

L’équilibre est difficile. Si la norme définit trop peu de choses, chaque association demeure une intégration sur mesure. Si elle en définit trop, elle peut figer les choix, favoriser les premiers exécutants et réduire la différenciation. L’expansion rapide d’UCIe, depuis une base consacrée à la liaison et aux protocoles jusqu’à la gestion, à DFx et à la 3D, montre que la frontière initiale ne suffisait pas à un boîtier pleinement opérationnel. Le consortium a dû normaliser davantage de livrables à mesure que le marché découvrait où les hypothèses propriétaires empêchaient la réutilisation.

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

UCIe a été lancée publiquement le 2 mars 2022 avec la version 1.0. Universal Chiplet Interconnect Express, Inc. a été enregistrée dans le Delaware comme organisation à but non lucratif le 2 août de la même année et a créé une structure formelle d’adhésion. La liste des promoteurs réunissait des entreprises des processeurs, du cloud, des fonderies, de l’assemblage et du test, 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.

L’étendue de cette liste constitue le principal actif institutionnel du consortium. Une liaison entre puces n’est pas utile par le seul travail d’un concepteur de processeurs. Les fonderies ont besoin de canaux et de règles fabricables; les entreprises d’assemblage et de test, de flux qualifiables; les fournisseurs d’EDA et de propriété intellectuelle, de spécifications transformables en contrôleurs, PHY et produits de vérification; les entreprises du cloud et des systèmes, de boîtiers répondant à des charges réelles.

Cette même liste réunit des motivations concurrentes. Un opérateur hyperscale peut vouloir des blocs réutilisables tout en gardant son architecture privée. Une fonderie peut soutenir une liaison commune tout en conservant fermés son kit de conception, sa capacité de production et son savoir-faire. Une entreprise de processeurs peut profiter d’une base de fournisseurs plus large tout en possédant de meilleures liaisons internes pour certains usages. Le consortium crée une enceinte où ces intérêts s’accordent sur les frontières, mais ne les rend pas identiques.

L’adhésion ne constitue donc pas une preuve de déploiement. Le logo d’un promoteur signale une participation à la gouvernance et aux travaux techniques. Un contributeur peut fournir des outils ou de la propriété intellectuelle, tandis qu’un adoptant peut en être encore au stade de l’évaluation. Aucune catégorie ne prouve à elle seule qu’un boîtier de production utilise des chiplets provenant de sources indépendantes ou que les pièces sont commercialement interchangeables. Ces frontières institutionnelles n’acquièrent de valeur que si la pile technique reste adaptée à différents choix de boîtier.

Le conseil actuel d’UCIe désigne Debendra Das Sharma d’Intel comme président, Cheolmin Park de Samsung comme président exécutif du consortium, Dong Wei d’Arm comme secrétaire et Lihong Cao d’ASE Group comme trésorier. Les autres administrateurs représentent Google Cloud, Qualcomm, Alibaba Cloud, Meta, TSMC, AMD et NVIDIA. Ces fonctions sont exercées par des représentants des membres; elles ne confèrent ni propriété personnelle de la spécification ni mérite technique exclusif.

La structure à but non lucratif fournit un cadre juridique à l’adhésion, aux dispositions de propriété intellectuelle et aux travaux techniques. Les catégories de promoteur, de contributeur et d’adoptant offrent différentes formes de participation. Les versions publiques d’évaluation rendent l’architecture visible, mais les conditions distinguent l’étude des droits plus étendus liés à l’implémentation et à l’adhésion. La licence autorise une évaluation interne limitée et ne place pas la conception dans un domaine public libre de brevets.

Ces limites importent pour les petits fournisseurs. Le document public réduit le coût de compréhension des exigences, mais n’élimine pas automatiquement l’incertitude juridique, ne fournit pas les outils de vérification et ne finance pas l’ingénierie à haut débit. Une jeune entreprise peut lire la même spécification qu’un promoteur sans disposer du même portefeuille de brevets, des mêmes relations avec les entreprises de boîtiers ni du même budget de validation.

Les adhésions soutiennent UCIe, mais les éléments examinés ne comprennent ni revenus, ni réserves, ni effectifs audités, ni dépenses par génération. Cela limite les affirmations sur la taille financière de l’organisation, non celles concernant les enjeux économiques entourant la norme.

Le travail coûteux est effectué au sein des entreprises membres et des fournisseurs. Les entreprises de semi-conducteurs conçoivent les puces et les contrôleurs; les fournisseurs de PHY développent une propriété intellectuelle réutilisable; les entreprises d’EDA ajoutent la modélisation et la vérification; les fonderies et les sociétés d’assemblage développent les procédés; les entreprises de systèmes financent l’intégration, la qualification et les logiciels. Une liaison commune réduit les doublons, mais les économies apparaissent dans l’économie des produits, pas dans les revenus du consortium.

L’adhésion répartit également les droits et les risques. Les promoteurs et les contributeurs participent au développement dans le cadre des accords applicables. L’évaluation publique donne accès aux documents, tandis que les droits d’implémentation et la protection de la propriété intellectuelle dépendent des contrats concernés. Il en résulte une référence technique ouverte entourée d’une économie d’adhésion organisée pour sa mise en œuvre.

Ce point est essentiel à la pérennité. Le consortium n’a pas besoin des revenus d’un fabricant de puces pour exercer une influence, mais il lui faut un soutien durable afin d’entretenir les spécifications, de résoudre les divergences d’interprétation, de construire la conformité et de coordonner la génération suivante. Le risque n’est pas l’échec d’un produit classique, mais que les entreprises supportant les coûts d’implémentation obtiennent un meilleur rendement par une voie propriétaire, ou que le coût de qualification augmente plus vite que la valeur d’une compatibilité élargie.

La spécification s’appuie sur des protocoles mûrs et laisse le choix du boîtier aux fabricants

La première spécification n’a pas tenté d’inventer chaque transaction de haut niveau à l’intérieur du boîtier. Elle a défini une liaison physique et un adaptateur capables de transporter des familles établies, notamment PCI Express et Compute Express Link, ainsi que du trafic brut. Elle a ainsi relié une nouvelle frontière physique à des modèles logiciels et matériels connus des développeurs.

PCIe fournit des sémantiques familières pour les relations entre hôte, périphérique et entrées-sorties. CXL ajoute la mémoire cohérente et les sémantiques de cache dans les systèmes pris en charge. UCIe ne remplace aucun de ces protocoles: elle permet à leurs paquets et à leur signification de traverser les frontières entre puces. Une fonction déplacée hors de la puce principale peut ainsi apparaître dans un environnement d’énumération et de logiciels existant sans imposer la création d’un modèle d’hôte entièrement nouveau.

L’avantage est la continuité, non une compatibilité automatique. Le boîtier a toujours besoin d’un micrologiciel, d’une énumération, d’une politique de mémoire, d’une gestion des erreurs et de logiciels comprenant le protocole. Plusieurs liaisons peuvent être électriquement compatibles tandis que l’une transporte PCIe, une autre CXL et une troisième des messages bruts. Le système d’exploitation peut connaître une catégorie de périphériques sans reconnaître la fonction d’un autre chiplet.

Le recours à des sémantiques mûres place aussi UCIe dans une chaîne de dépendances. Les évolutions de PCIe ou de CXL peuvent influencer les futurs mappages. La liaison et le protocole supérieur doivent être qualifiés ensemble. La compatibilité du transport ne corrige ni une erreur de conception de mémoire cohérente ni l’absence d’un pilote. La norme fait traverser une nouvelle frontière physique à un contrat logiciel existant, mais ne le rend pas simple.

L’architecture d’UCIe est organisée en couches. La couche physique traite le court canal électrique entre les puces. Die-to-Die Adapter gère la liaison et sert d’intermédiaire entre le PHY et le trafic des protocoles supérieurs. Au-dessus se trouvent les mappages qui donnent aux bits une signification visible par les logiciels. Cette séparation fonde la portabilité: une même architecture de liaison peut transporter plusieurs types de trafic sans attacher un protocole à une technologie de boîtier particulière.

L’adaptateur n’est pas une enveloppe passive. Les documents indiquent qu’il traite la gestion, les erreurs, les nouvelles tentatives et l’adaptation des protocoles. Une frontière entre puces ne peut pas se comporter comme un fil peu fiable dissimulé aux logiciels. Le boîtier a besoin de méthodes définies pour établir la liaison, déclarer les capacités et contenir les défaillances avant que la couche supérieure puisse faire confiance au chemin.

Les couches créent aussi des points de divergence. Un PHY peut ne prendre en charge qu’un débit ou une classe. L’adaptateur peut mettre en œuvre un ensemble différent de fonctions de fiabilité et de gestion. Le moteur peut prendre en charge PCIe sans CXL. Le fournisseur du système peut n’exposer que la partie nécessaire. UCIe désigne donc une famille de spécifications, pas un ensemble uniforme de fonctions.

Pour les acheteurs, la question utile n’est pas de savoir si un appareil prend en charge UCIe, mais quelle génération, quelle classe, quel débit, quelle largeur, quel mappage de protocole, quelles fonctions de gestion et quelles conditions de test ont été mis en œuvre. La norme devient une architecture opérationnelle lorsque ces détails peuvent être déclarés, testés et comparés. Avant cela, une affirmation générale de prise en charge en dit moins qu’elle ne le suggère.

La compatibilité entre versions impose sa propre charge d’intégration. Une entreprise de systèmes peut adopter un contrôleur conforme à une génération donnée d’UCIe et à une classe précise de boîtier, puis recevoir un nouveau chiplet comportant des fonctions facultatives d’une version ultérieure. La découverte et la négociation des capacités déterminent le socle commun, mais ne créent pas une fonction absente à l’une des extrémités.

Les équipes produit ont donc besoin d’un ensemble commun pris en charge: débits, protocoles, fonctions de gestion et comportements de repli déclarés, restant stables au fil des révisions du micrologiciel et du silicium. Découvrir une incompatibilité après avoir fixé les puces dans un même boîtier coûte bien plus cher que la détecter sur un connecteur de carte.

La portabilité logicielle suit le même modèle. Les mappages PCIe et CXL peuvent préserver des modèles de périphériques familiers, tandis que le mode brut ou les données de gestion propres à un fournisseur réintroduisent du travail sur mesure. Le boîtier peut énumérer correctement ses composants tout en nécessitant de nouveaux pilotes, micrologiciels, descriptifs de topologie ou politiques de défaillance. Le test pratique consiste à vérifier qu’un même contrat logiciel reste valable lors du remplacement d’un fournisseur et à la révision suivante du produit, non que les logiciels puissent voir la puce une seule fois.

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

Le consortium définit deux classes. UCIe-S vise les boîtiers standard moins denses et moins coûteux, tandis qu’UCIe-A cible les boîtiers avancés à pas de microbosses plus réduit et à plus forte densité de bande passante. Une même famille peut ainsi servir des produits ne justifiant pas tous le même coût d’interposeur, de pont ou d’assemblage.

Ce choix est commercialement important. Une norme limitée aux boîtiers les plus coûteux offrirait de fortes possibilités de performance, mais viserait un marché étroit. Une norme conçue uniquement pour les substrats organiques ordinaires pourrait ne pas atteindre la densité requise par le calcul avancé. Les deux classes reconnaissent que la compatibilité doit fonctionner sous des contraintes physiques et économiques différentes.

Ces contraintes ne disparaissent pas. Les boîtiers standard et avancés présentent des budgets de canal, des cartes de microbosses et des tolérances de fabrication différents. Une conception qualifiée pour UCIe-A ne peut pas être supposée transférable telle quelle vers UCIe-S. Le choix d’un interposeur, d’un pont, d’un substrat, d’un collage hybride ou d’une autre technique reste entre les mains de l’entreprise chargée du boîtier. Les règles des fonderies et des fournisseurs OSAT demeurent décisives.

Il en résulte un choix clairement délimité. UCIe fournit un vocabulaire commun à deux environnements tout en autorisant une implémentation propre au procédé. Elle ne garantit toutefois pas qu’un chiplet destiné à l’un soit économique, mécaniquement compatible ou électriquement qualifié dans l’autre. La classe de boîtier fait partie de l’identité du produit.

UCIe 3.0 a relevé le maximum par voie de 32 à 48 et 64 GT/s dans les deux classes. Les débits supérieurs peuvent accroître la bande passante totale sans augmentation proportionnelle du nombre de connexions au bord de la puce. Cette évolution est attractive pour l’intelligence artificielle et le calcul haute performance, où le calcul, la mémoire et les accélérateurs échangent de grands volumes dans un périmètre limité.

Le débit prévu par la spécification n’est pas le résultat d’une mesure sur un produit. La bande passante utile dépend du nombre de voies, du codage, de la surcharge, de la qualité du canal, de la conception du contrôleur et du type 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 régulièrement le canal complet. Le chiffre de 64 GT/s prouve qu’un mode est défini, pas que chaque boîtier pourra l’exploiter économiquement.

Le mode rapide rend aussi la vérification plus difficile. L’intégrité du signal, la marge temporelle, le routage et la thermique se compliquent avec la densité. Une démonstration en laboratoire peut réussir tandis que la chaîne de production rencontre d’autres conditions de vieillissement, de tension et de température. Les supports pédagogiques et les démonstrations montrent des progrès, mais ne fournissent pas un historique mondial de fiabilité sur le terrain.

C’est ici que la valeur et les limites de la norme se rejoignent. L’objectif de 64 GT/s fédère les investissements des fournisseurs et des outils, et permet de comparer les problèmes de vérification, mais il doit encore affronter la réalité physique de chaque boîtier.

La gestion est devenue aussi importante que la bande passante

Les canaux rapides transportent la charge de travail, mais un boîtier multipuce a besoin d’un chemin plus lent pour le contrôle et la gestion. UCIe comprend une voie auxiliaire distincte du chemin principal. La version 3.0 a porté la distance spécifiée à 100 millimètres dans les conditions concernées, offrant davantage de souplesse pour placer les composants administrés.

Il peut être nécessaire de détecter ou d’interroger un composant, ou de le placer dans un état sûr, avant que la liaison rapide ne soit prête. La gestion ne devrait pas dépendre entièrement du chemin qu’elle tente de diagnostiquer. Les signaux à faible latence et les contrôles d’urgence deviennent particulièrement importants lorsque plusieurs chiplets partagent des ressources et que l’un d’eux se comporte de manière inattendue.

Cette portée accrue ne signifie pas que le canal principal à 64 GT/s puisse suivre la même géométrie. Les objectifs et les exigences de la voie auxiliaire et des données diffèrent. Le chemin de gestion peut couvrir une plus longue distance interne, tandis que les liaisons rapides restent courtes et denses.

Au niveau du système, la voie auxiliaire montre que l’intégration ne s’arrête pas au transport des données. Le boîtier a besoin d’un plan opérationnel. La norme fournit une voie commune, mais chaque fournisseur définit encore de nombreux états, politiques et procédures derrière les messages. Un système nerveux commun ne garantit pas que chaque organe produise le même diagnostic.

UCIe 1.1 a été lancée le 8 août 2023 et a ajouté une surveillance d’état pour l’automobile ainsi que des options de boîtiers moins coûteuses. Elle a maintenu la rétrocompatibilité au sein de la famille et étendu la cible au-delà des boîtiers haute performance les plus onéreux.

Les systèmes automobiles accordent un poids différent à la surveillance, à la fiabilité et à la longévité par rapport à un accélérateur au cycle court. L’ajout d’informations d’état reconnaissait que les défaillances latentes et le diagnostic sur le terrain pouvaient autant que la bande passante maximale. Les options moins coûteuses répondaient à une pression inverse: la portée de la compatibilité reste limitée si elle exige un boîtier haut de gamme.

La présence d’une fonction dans la spécification ne prouve pas son 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 version 1.1 tient à son orientation: le consortium apprenait qu’une liaison commune devait offrir une certaine souplesse de boîtier et des signaux de cycle de vie pour servir plus qu’un secteur étroit.

Ce modèle s’est poursuivi avec les versions 2.0 et 3.0. Chaque génération a normalisé une part supplémentaire de la charge d’intégration auparavant laissée à des accords privés. La spécification a grandi parce que les problèmes les plus difficiles se trouvaient autour de la liaison initiale autant qu’à l’intérieur. Avec la deuxième version majeure, l’enjeu est passé du simple établissement de la liaison à l’exploitation du boîtier pendant tout son cycle de vie.

UCIe 2.0 a été publiée le 6 août 2024 et a ajouté une architecture de gestion du système ainsi que la prise en charge des boîtiers 3D. Les travaux portaient sur la découverte, le test, la télémétrie, les opérations de micrologiciel, le débogage et le contrôle du cycle de vie de plusieurs puces. Ils comprenaient Management Transport Protocol et une architecture de conception pour le test, le débogage et la mesure, souvent désignée par le sigle DFx.

Cette évolution a profondément modifié le sens de la compatibilité. Un boîtier peut transporter correctement les données tout en restant inexploitable. Les équipes de fabrication doivent tester les puces avant et après l’assemblage; les équipes chargées du micrologiciel doivent identifier les versions et coordonner les mises à jour; les opérateurs doivent mesurer et isoler les défaillances; le concepteur doit savoir si un composant défectueux peut être contenu sans mettre hors service tout le boîtier.

L’architecture commune fournit à ces activités un modèle de transport et une structure uniformes, sans définir chaque objet de gestion, politique de mise à jour ou procédure de maintenance. Un fournisseur peut fournir des données de santé détaillées, tandis qu’un autre n’expose qu’un état minimal. Une entreprise de systèmes peut autoriser des mises à jour coordonnées ou verrouiller le boîtier sur des images approuvées. La norme rend possibles les messages de gestion entre fournisseurs, mais ne supprime pas les limites de leurs politiques.

Le test pratique concerne la responsabilité. Lorsque les données signalent une liaison marginale, qui assure le diagnostic: le fournisseur de la puce, l’entreprise d’assemblage ou l’entreprise de systèmes? Si une mise à jour modifie le comportement, qui requalifie le boîtier? UCIe 2.0 a créé un espace technique commun pour ces questions, mais pas une réponse contractuelle.

Il est facile de considérer la conception pour le test, le débogage, la mesure et les fonctions de cycle de vie comme des questions réservées à l’usine. Elles deviennent pourtant une partie de l’architecture du produit dans un système multipuce. Le boîtier peut contenir des puces fabriquées selon des procédés différents, par des entreprises différentes et testées selon différentes méthodes internes. Après l’assemblage, il faut déterminer si une défaillance provient d’une puce, d’une liaison, du canal du boîtier, de l’alimentation partagée ou des logiciels coordonnés.

L’architecture DFx tente de fournir une base commune à ces fonctions. Le chemin de gestion transporte l’état et les informations de diagnostic; le test et le débogage peuvent être construits autour d’un modèle de boîtier commun plutôt que d’une connexion spécifique à chaque association. Cela réduit les livrables sur mesure et facilite la conservation des preuves pendant la fabrication et l’exploitation.

La norme ne peut pas créer une observabilité que la puce n’implémente pas, ni garantir qu’un signal révèle la cause première. Une puce peut signaler une erreur causé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 une défaillance. L’assembleur peut constater un problème de rendement impossible à reproduire dans le laboratoire de l’entreprise de systèmes. Le transport commun aide les preuves à circuler, mais ne les rend pas complètes.

DFx modifie également les frontières commerciales. La couverture de test, l’accès aux mesures et les droits de contrôle du micrologiciel peuvent devenir des conditions fixées par l’acheteur. Un chiplet compatible avec UCIe mais fermé au diagnostic peut être moins utile qu’un composant propriétaire dont le fournisseur offre une meilleure assistance. L’architecture commune ouvre une voie de gestion; la qualité de cette gestion reste une décision propre au produit.

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

La même génération a ajouté la prise en charge des boîtiers 3D, notamment les puces empilées verticalement et les liaisons très courtes et très denses. L’empilement peut rapprocher le calcul de la mémoire, accroître la densité de bande passante et réduire la surface. Il lie toutefois plus étroitement la chaleur, les contraintes mécaniques et le rendement que les configurations 2D ou 2,5D.

Une norme d’interface aide à définir ce qui traverse la frontière verticale, mais ne définit ni le procédé d’assemblage, ni l’architecture thermique, ni le réseau d’alimentation, ni la séquence permettant d’établir la qualité des puces avant l’assemblage final. Ces décisions restent du ressort des fonderies, des entreprises d’assemblage et de test, des concepteurs de puces et des entreprises de systèmes.

L’importance de cette distinction apparaît clairement lors des réparations. La modularité d’une carte laisse penser qu’un composant peut être remplacé, mais un boîtier aux interconnexions denses peut interdire le remplacement sur le terrain d’une puce interne. La gestion peut identifier la pièce défectueuse tandis que la solution commerciale consiste toujours à remplacer tout le boîtier. Un meilleur diagnostic raccourcit l’enquête, mais ne modifie pas la réparabilité physique.

La norme prend en charge l’intégration 3D sans la rendre facile. Sa contribution consiste à garder claires les frontières de communication et de gestion lorsque la forme change. Le problème de fabrication qui les entoure devient plus difficile, pas plus simple.

PCIe et CXL offrent des chemins logiciels stables, mais tous les chiplets ne sont pas des périphériques d’entrées-sorties traditionnels ni de la mémoire cohérente. Le traitement du signal, les réseaux et les accélérateurs spécialisés peuvent nécessiter un trafic continu ou propre à l’application. Le mode brut transporte ce trafic sans imposer les sémantiques de PCIe ou de CXL. La version 3.0 a étendu les mappages continus, notamment les chemins de conversion analogique-numérique et numérique-analogique.

Le mode brut accroît le nombre de systèmes pouvant utiliser la couche physique et met en évidence la différence entre compatibilité électrique et compatibilité fonctionnelle. Deux fournisseurs peuvent satisfaire aux mêmes exigences de canal tout en définissant un cadrage, un flux et une signification applicative différents au-dessus du transport brut. La liaison s’établit, mais les fonctions exigent encore un accord séparé.

Ce n’est pas nécessairement un échec. Une architecture physique commune peut réduire les doublons même avec un protocole spécialisé. Le risque apparaît lorsque la formule « prend en charge UCIe » sert à suggérer une portabilité que le mode brut n’offre pas. L’acheteur doit savoir si le mappage correspond à un profil commun, à un contrat bilatéral ou à un protocole propriétaire.

Le mode brut peut donc produire deux effets opposés: élargir l’écosystème en y intégrant davantage de catégories de chiplets et maintenir des îlots fonctionnels propriétaires au-dessus de la liaison. L’orientation dépendra de la création de profils communs et de la publication d’informations suffisantes pour permettre une intégration indépendante.

L’industrie des semi-conducteurs regorge de sigles d’interconnexion qu’il est facile d’imaginer en concurrence directe. PCI-SIG définit la liaison PCI Express et le modèle de périphérique. CXL Consortium définit la mémoire cohérente et les sémantiques de protocole associées. UCIe définit un court canal interne au boîtier ainsi que les mappages transportant ces protocoles.

Cette organisation en couches explique en partie la rapidité des progrès d’UCIe. Le consortium n’a pas eu à convaincre les systèmes d’exploitation et les fournisseurs d’adopter une nouvelle signification pour chaque transaction; il a pu transporter des sémantiques déjà soutenues par des logiciels, des tests et des organisations existants.

L’implémentation hérite cependant des évolutions et de la complexité du protocole supérieur. Un boîtier CXL exige une conception cohérente; un chiplet PCIe exige une énumération, un pilote et une gestion des erreurs. Un défaut du protocole supérieur ne devient pas un défaut d’UCIe simplement parce que les données traversent une frontière entre puces.

La lecture la plus claire est celle d’une chaîne de responsabilités. UCIe répond à la question de savoir comment les bits et les paquets traversent la frontière dans des conditions données. PCIe ou CXL indique ce que signifient beaucoup de ces paquets. Les micrologiciels et les logiciels d’exploitation déterminent comment le système apparaît et s’utilise. Aucune couche ne peut revendiquer le résultat des trois.

Le canal rapide doit prouver que les deux extrémités peuvent communiquer dans les conditions électriques réelles du boîtier. Les documents décrivent la négociation des capacités, l’entraînement de la liaison, le réétalonnage en fonctionnement et la limitation dynamique. UCIe 3.0 a ajouté le réétalonnage de l’émetteur et des améliorations énergétiques facilitant l’adaptation au procédé, à la tension, à la température et aux conditions d’exploitation.

L’adaptation est nécessaire parce que le boîtier n’est pas statique. La température varie avec la charge, l’alimentation fluctue et les composants vieillissent. La liaison doit pouvoir récupérer de la marge ou réduire son activité au lieu de supposer que l’état observé à la fabrication se maintiendra pendant toute sa durée de vie.

La réussite de l’entraînement est un résultat de portée limitée. Elle prouve l’établissement de la liaison dans les conditions testées, non sa fiabilité pour chaque charge, cycle thermique et durée de vie. L’étalonnage peut corriger une forme de dérive tout en laissant subsister un autre mécanisme de défaillance. La limitation dynamique peut préserver le fonctionnement au prix des performances.

Les rapports sur les produits doivent donc être précis. Ils devraient distinguer le débit maximal de la spécification du débit vérifié dans le boîtier et expliquer les conditions d’étalonnage ainsi que le comportement en cas de marge insuffisante. Une liaison adaptative gère les variations; elle ne transforme pas une fiabilité non mesurée en garantie.

Les preuves de conformité doivent être assez précises pour éclairer un achat

Un seul logo ne décrit pas toutes les implémentations d’UCIe. Une déclaration complète doit préciser la génération, la classe de boîtier, le débit, la disposition des voies, le protocole, les fonctions facultatives et les conditions de test. Deux produits peuvent mettre en œuvre UCIe sans former aucune combinaison utile au niveau de performance requis.

Les programmes d’interconnexion mûrs relient la conformité à des capacités et à des procédures précises. Lors de la recherche, l’écosystème public d’UCIe construisait encore cette base. Des travaux d’interopérabilité, des sommets, des séminaires et des démonstrations de contrôleurs et de PHY existaient, mais les documents ne définissaient pas de liste publique complète de produits certifiés.

Un programme utile ne doit pas seulement tester la mise en route la plus simple. Il doit préciser le comportement en cas d’erreur, la négociation des capacités, la gestion et les profils pris en charge. La classe du boîtier et les conditions du canal comptent. Le résultat d’une association ne doit pas être généralisé à un autre débit ou boîtier sans preuve.

L’absence de liste mondiale ne signifie pas que les implémentations sont fictives; elle indique que les preuves publiques restent précoces. Les démonstrations peuvent montrer la coopération d’outils et d’interfaces indépendants. La qualification de production exige toutefois répétition, volume, conditions documentées et responsabilité lorsqu’une défaillance survient ensuite.

La précision protège l’acheteur comme le consortium. Amplifier la portée du logo provoque des déceptions concernant des problèmes que la norme n’a jamais été conçue pour prévenir. Un profil précis rend au contraire visible l’accomplissement réel. L’obstacle restant est la preuve: l’acheteur doit connaître exactement la configuration testée et ses limites.

Depuis la première version, l’activité du consortium est passée de l’explication du concept à sa mise en œuvre. Les membres ont annoncé des contrôleurs, de la propriété intellectuelle PHY, des plateformes de vérification et des travaux sur les boîtiers. Les événements ont présenté des démonstrations et des discussions sur l’intégrité du signal, les boîtiers et l’interopérabilité. Les documents de 2025 ont décrit cette activité comme une progression de l’adoption.

Une démonstration répond à une question ciblée: ce contrôleur communique-t-il avec ce PHY? Le banc d’essai détecte-t-il une erreur donnée? Le canal atteint-il le débit demandé dans les conditions du laboratoire? Ces questions importantes réduisent l’incertitude et révèlent les divergences d’interprétation de la spécification.

La production répond à un ensemble plus large: plusieurs fournisseurs livrent-ils à temps des puces de qualité? Le boîtier atteint-il ses objectifs d’énergie et de rendement? Le micrologiciel peut-il être mis à jour en sécurité? Les logiciels passent-ils d’une révision à l’autre? Qui remplace le système si une puce marginale provoque une défaillance intermittente? Une démonstration ajoute des preuves, mais ne résout pas l’ensemble de ces questions.

Les éléments publics ne fournissaient pas de liste complète des boîtiers multifournisseurs expédiés. La conclusion prudente est que l’écosystème construit une capacité d’implémentation, non qu’il soit déjà devenu un marché général.

L’intégrateur ne peut pas évaluer un chiplet en se contentant d’établir la liaison. La puce doit être adaptée à sa fonction, à sa position dans les variations du procédé et à son cycle de vie, avec des preuves qui l’accompagnent de la tranche jusqu’à l’assemblage et au système final. Si un composant s’avère défectueux après l’intégration, la perte peut englober les autres puces et le travail de boîtier.

Une puce dont la qualité est établie constitue une exigence commerciale et industrielle. Les fournisseurs doivent s’accorder sur ce qui a été testé, les marges, la présentation des résultats et la partie supportant la perte du boîtier. La gestion UCIe et DFx peut transporter les données de test et de mesure, mais elle ne certifie pas la fonction interne et ne répartit pas la responsabilité entre les entreprises.

C’est l’une des raisons pour lesquelles les boîtiers intégrés verticalement conservent un avantage. Une seule entreprise peut contrôler la conception, les frontières de test, l’assemblage et la garantie. Un boîtier multifournisseur doit transformer les livrables privés en preuves et en contrats explicites.

Cette couche manquante n’est pas spectaculaire, mais elle détermine jusqu’où la modularité peut s’ouvrir aux petits fournisseurs. La liaison réduit un obstacle; l’assurance qualité détermine si l’acheteur acceptera de risquer le reste du boîtier sur un composant peu familier.

La sécurité, la garantie et les logiciels détermineront si un marché se forme

Un boîtier multifournisseur crée des frontières de confiance extrêmement proches. Les puces échangent des données denses, partagent des chemins de gestion et influencent des ressources que le système traite comme un seul appareil. Une puce compromise peut menacer davantage que sa propre fonction et devenir un point d’entrée vers les flux de contrôle et de données.

L’architecture de gestion ajoutée ultérieurement prend en charge une découverte contrôlée, des opérations sur le micrologiciel et des signaux d’urgence. Les documents d’adhésion citent également le renforcement de la sécurité parmi les travaux en cours. Ces mécanismes ne définissent toutefois pas une architecture de sécurité complète pour le boîtier. L’identité du périphérique, le démarrage sécurisé, la provenance du micrologiciel, l’attestation, l’isolation, les clés et la garantie du fournisseur restent des responsabilités du système.

Un transport sécurisé peut protéger les messages tandis qu’un chiplet autorisé mais compromis agit de manière malveillante. Une identité forte indique quelle puce est présente sans prouver l’intégrité de son micrologiciel. Un composant authentifié peut abuser de l’accès qui lui a été accordé. La sécurité dépend de ce qu’il peut faire après l’établissement de la confiance.

Une génération future pourra préciser davantage de fonctions, mais les preuves disponibles n’en indiquent ni le calendrier ni la forme. La mention « compatible avec UCIe » ne signifie pas que la sécurité du boîtier a été certifiée. L’acheteur a besoin d’un modèle de confiance indépendant pour chaque fournisseur et pour le système entier.

UCIe est présentée comme une norme industrielle ouverte, et ses spécifications peuvent être demandées selon les conditions d’évaluation. Cela permet d’étudier l’architecture, de faire converger les outils et de discuter de la conformité sans propriétaire unique de l’interface.

Le reste de la chaîne peut demeurer concentré. La fabrication avancée, le collage hybride, les interposeurs, l’assemblage, le test et l’EDA proviennent d’un nombre limité d’entreprises et de régions. Les contrôles à l’exportation et la politique industrielle influencent l’accès aux nœuds, aux outils et à la propriété intellectuelle. Une liaison commune ne crée ni nouvelle fonderie ni nouvelle chaîne de boîtiers.

Une norme ouverte n’impose pas non plus une implémentation ouverte. Le contrôleur, le PHY, le chiplet, le micrologiciel et le 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 tout en conservant une maîtrise importante au-dessus et au-dessous de celle-ci.

C’est peut-être la force réaliste de la norme. Elle n’a pas besoin d’un code source ouvert pour réduire le travail bilatéral. Le risque consiste à utiliser l’ouverture d’une couche pour suggérer de la concurrence ou de la portabilité dans des couches encore fermées. Le boîtier doit être cartographié couche par couche. Une fois le périmètre de conformité défini, les questions les plus difficiles portent sur la confiance, l’assistance commerciale et la partie qui supporte les risques d’intégration.

Les ressources des promoteurs donnent sa crédibilité à UCIe. Ils apportent leur expertise, construisent les interfaces, qualifient les boîtiers et créent la demande. Ils disposent aussi des alternatives les plus solides à un marché ouvert. Les entreprises de processeurs, de cloud et de fonderie peuvent concevoir des chiplets, des liaisons et des flux propriétaires lorsque cela leur procure un avantage.

Cela ne rend pas leur participation insincère. Une entreprise peut utiliser UCIe sur certaines frontières externes tout en conservant une interface interne propriétaire. Elle peut transporter un protocole commun et se différencier par la topologie, la mémoire ou la gestion. L’adoption peut être sélective et organisée par couches.

Le défi de gouvernance consiste à maintenir des frontières utiles pour ceux qui ne contrôlent pas toute la pile. La diversité du conseil y contribue, mais il n’existe pas de registre public complet du poids des contributions, des votes ou du règlement des désaccords dans les groupes techniques. Des logos de même taille ne signifient pas un pouvoir de négociation égal.

La norme peut réussir tout en laissant aux plus grands acteurs des avantages propriétaires. Le test le plus exigeant consiste à permettre à un petit fournisseur de construire un chiplet, d’en démontrer un profil précis, d’obtenir un boîtier et de vendre à plusieurs systèmes sans transférer à l’acheteur des risques juridiques et d’intégration impossibles à gérer.

L’interchangeabilité commerciale exige davantage qu’une liaison. La pièce doit être accompagnée de données fonctionnelles: ce qu’elle fait, les protocoles et débits pris en charge, sa méthode de détection, le micrologiciel nécessaire et sa manière de signaler son état. Le concepteur du boîtier a besoin de limites électriques, énergétiques, thermiques et mécaniques. Les logiciels ont besoin d’une énumération et d’une gestion stables. Les achats ont besoin d’un prix, de volumes, d’un cycle de vie, d’une garantie et d’une répartition des responsabilités.

UCIe peut en fournir une partie par la découverte des capacités, les profils et la gestion. Elle ne définit toutefois ni interface fonctionnelle complète, ni catalogue mondial; elle ne répartit pas la garantie et ne garantit pas la capacité des fonderies. Les documents évoquent un marché possible, mais les preuves publiques s’arrêtent avant une couche transactionnelle complète.

UCIe est donc à la fois importante et insuffisante. Les normes créent les conditions d’un marché; elles ne créent pas le marché lui-même. Les fournisseurs, les fonderies, les outils et les acheteurs doivent rendre l’interface exploitable, testable et soutenable.

Dans un marché mûr, la responsabilité est lisible. Lors d’une défaillance, il est possible de déterminer si la cause réside dans la puce, la liaison, l’assemblage, le micrologiciel ou l’intégration, et le contrat précise qui en supporte le coût. Sans ces livrables, la modularité technique peut accroître le risque de l’acheteur.

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

Le consortium est passé d’une base établie en 2022 aux options pour l’automobile et les coûts en 2023, puis à la gestion et à la 3D en 2024, et enfin à 64 GT/s, au mode brut et à de nouveaux contrôles de gestion en 2025. En 2026, les travaux publics portaient davantage sur la formation, l’implémentation et la vérification que sur un nouveau chiffre de débit.

Cette chronologie montre une jeune norme apprenant où l’intégration se rompt. La liaison avait besoin de protocoles et de classes; le boîtier, d’informations de santé, de gestion, de DFx et de 3D; les débits supérieurs, d’étalonnage, de contrôle énergétique et d’une voie auxiliaire plus souple. Chaque ajout a fait entrer une hypothèse auparavant privée dans le contrat technique commun.

La prochaine preuve sera d’une autre nature. L’écosystème de conformité devra présenter des profils opérationnels; les fournisseurs indépendants devront livrer des puces résistant à l’assemblage et à la vérification; les logiciels devront détecter et gérer les pièces sans réécriture pour chaque association; les contrats devront répartir la responsabilité des défaillances et du cycle de vie; les petits acteurs devront pouvoir participer sans faire supporter toute l’incertitude à l’acheteur.

UCIe a déjà modifié le débat en plaçant une liaison commune crédible à une frontière jusque-là propriétaire. Le marché apparaîtra lorsque la première défaillance impliquant plusieurs fournisseurs pourra être diagnostiquée, attribuée et corrigée sans retour à un fournisseur unique intégré verticalement. La spécification passera alors d’une interface prometteuse à une infrastructure.