Résumé

  • UCIe donne des règles communes à la couche physique, à l’adaptateur, aux protocoles et à la gestion des liaisons inter-puces, tout en laissant hors de son périmètre les fonctions des chiplets, la conception des boîtiers et la responsabilité des fournisseurs
  • De la version 1.0 à la 3.0, s’ajoutent les boîtiers à faible coût, la surveillance automobile, la prise en charge de la 3D, les fonctions de gestion et un fonctionnement à 64 GT/s
  • Sa valeur sur le marché se mesurera à des profils de conformité reproductibles, à des produits multi-fournisseurs fabriqués en série et durablement pris en charge, ainsi qu’à une répartition claire des responsabilités en cas de panne

La version 64 GT/s a fait de la course à la vitesse un problème de conception système

Le 5 août 2025, le consortium de normalisation, à peine plus de trois ans après son lancement public, a publié sa troisième spécification majeure. Universal Chiplet Interconnect Express, dit UCIe, ajoute 48 et 64 GT/s aux deux classes de canaux, boîtiers standard et boîtiers avancés. Il étend la portée des voies sideband à basse vitesse, enrichit la transmission raw continue et renforce les contrôles de gestion. La vitesse a fait la une, mais le plus important est la volonté de traiter un boîtier composé de plusieurs puces conçues indépendamment comme un système unique et gérable.

Cette distinction compte. La liaison à haute vitesse n’est qu’un élément du produit chiplet. L’acheteur doit connaître les fonctions de chaque puce, sa consommation, son refroidissement, le logiciel qui la détecte, les mises à jour de micrologiciel, le comportement en cas de panne d’un composant et le fournisseur qui assure la garantie. UCIe fournit des règles communes pour déplacer l’information entre les puces et gérer une partie de l’environnement qui les entoure. Il ne transforme pas un assemblage de circuits sans rapport en processeur achevé.

Le consortium affiche un « écosystème de chiplets ouvert ». Utile comme objectif, mais facile à confondre avec la description d’un marché déjà existant. Les documents publics consultés pour cet article ne contenaient ni étude indépendante recensant les boîtiers UCIe multi-fournisseurs en cours d’expédition, ni liste universelle de produits certifiés, ni catalogue permettant aux concepteurs de choisir des puces interchangeables. On y trouve des spécifications, des activités de membres, de la formation à la mise en œuvre et des démos.

Tout cela est nécessaire, mais ce n’est pas une preuve d’approvisionnement reproductible et de production en série.

La question centrale n’est donc pas de savoir si les chiplets vont devenir importants. Comme moyen de découper des systèmes complexes, ils le sont déjà. Ce qui est en jeu, c’est la mesure dans laquelle une liaison partagée peut produire de la modularité alors que le boîtier qui l’entoure reste un objet propriétaire, conçu de façon très intégrée. UCIe peut devenir un langage commun à la frontière des puces sans pour autant faire sortir l’essentiel du système physique et des relations commerciales de la sphère propriétaire.

Il faut donc évaluer cette interface non comme une promesse unique d’« interchangeabilité », mais comme une chaîne de livrables successifs.

Le mot interchangeabilité regroupe sous un même terme plusieurs épreuves très différentes. La première est la compatibilité électrique: l’émetteur-récepteur et le canal du boîtier peuvent-ils établir une liaison selon le même profil physique? La deuxième est protocolaire: les deux extrémités comprennent-elles le même mappage PCIe, CXL ou raw? La troisième est opérationnelle: la puce peut-elle être découverte, testée, surveillée et mise à jour au moyen de fonctions de gestion compatibles? La quatrième est fonctionnelle et logicielle: le chiplet offre-t-il un comportement exploitable par le micrologiciel, les pilotes et les applications?

La cinquième est commerciale: le composant peut-il être approvisionné avec des preuves d’essai, des volumes, un support et une garantie suffisants pour entrer dans un produit?

UCIe traite directement les deux premières et élargit peu à peu son champ à la troisième. Il rend la négociation électrique, le transport des protocoles et les remises de gestion moins dépendants d’une conception privée entre deux entreprises. 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 assembleurs et aux acheteurs.

Confondre les couches fait naître deux erreurs opposées. La première consiste à rejeter la norme parce qu’elle ne crée pas à elle seule un marché achevé; elle ignore la valeur qui consiste à lever des barrières physiques et protocolaires récurrentes. La seconde consiste à juger le marché achevé parce que deux puces ont établi une liaison conforme; elle ignore toutes les décisions restantes pour transformer la liaison en système maintenable.

Une évaluation professionnelle devrait préciser quelles promesses ont été démontrées. Une démo d’interface physique prouve moins qu’une connexion protocolaire; une connexion protocolaire prouve moins qu’un boîtier gérable sur tout son cycle de vie; un boîtier gérable prouve encore moins qu’un composant remplaçable sans nouveau logiciel ni nouveau contrat. Cette hiérarchie n’est pas une critique d’UCIe: c’est la façon la plus nette de montrer ce que le consortium maîtrise et ce qu’il laisse au marché.

La lecture en cinq couches explique aussi pourquoi des progrès réels ne ressemblent pas encore à un approvisionnement plug-and-play. Même si les mises à jour de la spécification renforcent les trois premières, la quatrième et la cinquième peuvent mûrir lentement. Le marché des chiplets n’arrivera pas avec une seule annonce. Il se construit au fur et à mesure que des livrables plus étroits deviennent reproductibles et atteignent un niveau de confiance suffisant.

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

Une puce monolithique porte toutes les fonctions du système sur un seul grand morceau de silicium. Elle facilite la communication entre les fonctions, mais soumet tout à un seul plan de fabrication. Lorsque les pressions de conception en nœud avancé, de masque et de rendement s’accentuent, placer tous les blocs sur une seule grande puce devient coûteux et difficile. Avec les chiplets, on peut séparer calcul, mémoire, E/S, analogique, sécurité et accélérateurs, les fabriquer chacun dans un procédé adapté et les réunir dans un système en boîtier (system-in-package).

Le découpage ne fait pas disparaître la complexité: il en déplace une partie de la puce vers le boîtier. Chaque frontière exige des signaux, une horloge, une gestion des erreurs, une alimentation, un design thermique, un périmètre de test et un comportement visible depuis le logiciel. Un grand monolithique peut perdre du rendement à mesure que la surface augmente, mais un boîtier multi-puces perd lui aussi toute sa valeur si l’une des puces intégrées est défectueuse, en limite ou mal mise en œuvre.

En échange de la possibilité de combiner des nœuds de gravure et de réutiliser des blocs, le concepteur de système assume de nouvelles dépendances au niveau du boîtier.

Le mot « module » appelle donc à la prudence. Si un circuit imprimé est modulaire, c’est aussi parce que ses composants ont des formes standard, des pratiques électriques établies, des fonctions détectables et des conditions commerciales matures. Les fournisseurs publient des fiches techniques, les distributeurs tiennent des stocks, les intégrateurs connaissent les sockets, les connecteurs et les frontières de défaillance. Dans un boîtier avancé, le chiplet se trouve dans un environnement physique beaucoup plus contraignant, avec moins de marge d’erreur.

Il partage l’alimentation, la thermique, la gestion et les canaux rapides avec les puces voisines, et après assemblage, il ne peut parfois être ni inspecté ni remplacé comme un composant de carte.

UCIe traite l’une des frontières les plus difficiles et les plus récurrentes: la liaison inter-puces courte et à haute densité. Standardiser cette liaison réduit les conceptions d’interface redondantes et donne aux outils, aux fournisseurs de propriété intellectuelle et aux entreprises de systèmes un objectif commun. Les autres problèmes d’intégration ne disparaissent pas. La valeur de la norme est de réduire l’ingénierie bipartite spécifique, et non de transformer le boîtier en un assemblage lâche de composants indépendants.

Sans interface commune, une entreprise peut découper son système en plusieurs puces tout en restant verticalement intégrée. En concevant la liaison inter-puces autour de présupposés électriques, d’un protocole, d’un procédé de boîtier et d’un flux de test propres à une société, il est plus facile d’optimiser latence, puissance et surface pour un produit donné. En revanche, aucun autre fournisseur ne peut proposer de puce sans avoir appris et implémenté l’accord privé.

Le piège de la liaison propriétaire est autant technique qu’économique. Une entreprise de systèmes peut parler de conception en chiplets sans qu’aucun module utile ne soit disponible à l’extérieur. Même si la réutilisation traverse ses propres générations de produits, le boîtier reste fermé aux yeux du marché extérieur. Modulaire à l’intérieur des frontières de l’entreprise, il est indivisible à l’extérieur.

Les fondateurs d’UCIe ont voulu créer une frontière partagée sans spécifier tout le système. Le consortium définit le comportement de la couche physique, l’adaptateur et les mappages de protocoles. Le vendeur choisit les fonctions de son chiplet, la façon de construire le boîtier et ce qu’il expose. La couche commune doit être assez fine pour soutenir des produits différents, et assez concrète pour que des implémentations indépendantes rejoignent la même spécification.

L’équilibre est difficile. Trop peu de règles et chaque combinaison reste une intégration sur mesure. Trop de règles et l’on fige les choix de conception, avantage les premiers implémenteurs et réduit la marge de différenciation. L’extension rapide d’UCIe, de la liaison et des protocoles de base vers la gérabilité, le DFx et les boîtiers 3D, montre que la frontière d’origine ne suffisait pas à produire un boîtier exploitable. Chaque fois que le marché découvrait un prérequis privé qui bloquait la réutilisation, le consortium a standardisé un peu plus le périmètre du livrable.

Des entreprises concurrentes ont créé un organisme à but non lucratif pour une frontière volontairement étroite

UCIe a été lancé publiquement 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 en société à but non lucratif du Delaware et a ouvert son régime d’adhésion officiel. Les membres promoteurs réunissaient des entreprises de conception de processeurs, de cloud, de fonderie, d’assemblage et de test, de mémoire et d’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 actif institutionnel. Une liaison inter-puces ne devient utile qu’avec plus que des concepteurs de processeurs. Les fonderies ont besoin de canaux fabricables et de règles de packaging; les sociétés d’assemblage et de test, de flux qu’elles peuvent qualifier. Les éditeurs d’EDA et les fournisseurs d’IP d’interface ont besoin d’une spécification qu’ils peuvent décliner en contrôleurs, PHY et produits de vérification. Les clouds et les entreprises de systèmes doivent pouvoir utiliser les boîtiers finis sur des charges réelles.

La même liste contient aussi des motivations concurrentes. Les hyperscalers veulent des blocs réutilisables tout en gardant privée leur architecture système. Les fonderies soutiennent une liaison électrique commune tout en gardant propriétaires leurs kits de conception de boîtier, leurs capacités et leur savoir-faire de procédé. Les grands fabricants de processeurs profitent de l’élargissement des fournisseurs tout en gardant, pour certains usages, des liaisons internes supérieures à la norme standard. Le consortium crée un lieu où les intérêts s’accordent sur une frontière; il ne les harmonise pas.

L’adhésion n’est donc pas une preuve de déploiement. Le logo d’un promoteur indique une participation à la gouvernance et aux travaux techniques. Un contributeur fournit des outils ou de la propriété intellectuelle; un adoptant peut être en cours d’évaluation. Aucun de ces statuts ne prouve à lui seul qu’un boîtier de production donné contient des chiplets UCIe de fournisseurs indépendants, ni qu’ils sont commercialement interchangeables. Cette frontière institutionnelle n’a de sens que si la pile technologique accepte plusieurs choix de boîtier.

Au sein du conseil d’administration actuel d’UCIe, Debendra Das Sharma (Intel) préside le conseil, Cheolmin Park (Samsung) est président de l’association, Dong Wei (Arm) est secrétaire et Lihong Cao (ASE Group) est trésorier. Siègent également des représentants de Google Cloud, Qualcomm, Alibaba Cloud, Meta, TSMC, AMD et NVIDIA. Ce sont des postes de gouvernance exercés à travers l’organisation des membres; ils ne signifient ni propriété personnelle de la spécification, ni contribution individuelle exclusive à son contenu technique.

La structure à but non lucratif offre un cadre juridique pour traiter l’adhésion, la propriété intellectuelle et les travaux techniques. Les formes de participation diffèrent entre promoteurs, contributeurs et adoptants. L’édition publique d’évaluation permet à des tiers d’examiner l’architecture, mais ses conditions distinguent l’accès à des fins d’apprentissage des droits plus larges qui accompagnent l’implémentation et l’adhésion. Le contrat n’accorde qu’une licence d’évaluation interne limitée; il ne fait pas de la spécification un design de domaine public, sans brevets.

Cette frontière compte pour les petits fournisseurs. Les documents publics réduisent le coût d’apprentissage des exigences, mais ils n’éliminent pas automatiquement l’incertitude juridique, ne fournissent pas d’outils de vérification et ne financent pas le développement qu’exigent les contraintes des boîtiers rapides. Une jeune pousse peut lire la même spécification qu’un promoteur sans disposer du même portefeuille de brevets, des mêmes relations en packaging ni du même budget de vérification.

UCIe est financé par les cotisations, mais les documents publics consultés pour cet article ne contiennent ni revenus audités, ni réserves, ni effectifs, ni dépenses par génération de spécification. Cette lacune borne ce qu’on peut affirmer sur la taille financière de l’organisation, sans réduire le poids économique qui gravite autour de la norme.

Le travail coûteux se fait au sein des membres et des fournisseurs. Les entreprises de semi-conducteurs conçoivent contrôleurs et puces, les fournisseurs de PHY créent de la propriété intellectuelle réutilisable, les éditeurs d’EDA ajoutent modélisation et vérification, les fonderies et les assembleurs développent les procédés de boîtier. Les entreprises de systèmes paient l’intégration, la qualification et le logiciel. La liaison partagée peut réduire les travaux redondants, mais l’économie apparaît dans les coûts produits, pas dans les revenus du consortium.

Le régime d’adhésion répartit aussi droits et risques. Promoteurs et contributeurs participent au développement technique sur une base contractuelle. L’édition publique d’évaluation permet à des tiers de lire la spécification, mais les droits d’implémentation et la protection de la propriété intellectuelle dépendent des contrats applicables. Le résultat combine des documents techniques publics et une économie d’adhésion structurée autour de leur implémentation.

C’est ici que se joue la question de la pérennité. Pour peser, il n’est pas nécessaire d’avoir le chiffre d’affaires d’un fabricant de puces, mais il faut un soutien continu pour maintenir la spécification, arbitrer les interprétations, organiser la conformité et coordonner les générations suivantes. Le risque n’est pas l’échec ordinaire d’un marché produit: c’est que des entreprises supportant les coûts d’implémentation jugent la voie propriétaire plus avantageuse, ou que les coûts de qualification grimpent plus vite que la valeur d’une interopérabilité large.

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

La première spécification n’a pas cherché à réinventer de toutes pièces les transactions de haut niveau transportées dans le boîtier. Elle a défini la liaison physique inter-puces et l’adaptateur, capables de porter PCI Express, Compute Express Link et du trafic raw. Elle branchait ainsi la nouvelle frontière du boîtier sur les modèles de logiciel et de périphériques que les développeurs de systèmes comprennent déjà.

PCIe apporte la sémantique familière hôte-périphérique et E/S; CXL ajoute, pour les systèmes compatibles, la sémantique de la mémoire cohérente et du cache. UCIe ne remplace ni ces organismes ni ces spécifications: il transporte leurs paquets et leur sémantique entre les puces d’un même boîtier. Même si une fonction quitte la puce principale, elle peut apparaître dans l’énumération et l’environnement logiciel existants, sans créer un modèle d’hôte entièrement nouveau.

L’avantage est la continuité, pas la compatibilité automatique. Le boîtier exige un micrologiciel, une énumération, des politiques mémoire, une gestion des erreurs et des logiciels qui comprennent le protocole choisi. Deux liaisons UCIe peuvent être électriquement compatibles alors que l’une porte PCIe, l’autre CXL et la troisième des messages raw. Un système d’exploitation adapté à une classe de périphériques ne connaîtra pas nécessairement les fonctions d’un autre chiplet.

En réutilisant une sémantique mature, UCIe entre aussi dans une chaîne de dépendances. Les évolutions de PCIe ou de CXL peuvent affecter les mappages futurs. Le concepteur de boîtier doit qualifier à la fois la liaison et les protocoles supérieurs. La conformité de la couche de transport ne corrige ni une erreur de conception de la mémoire cohérente ni un pilote manquant. La norme transporte les contrats logiciels existants de l’autre côté de la nouvelle frontière physique, mais elle ne les simplifie pas.

UCIe est organisé en couches. La couche physique traite du canal électrique court entre les puces. Le Die-to-Die Adapter gère la liaison et fait le pont entre la couche physique et le trafic des protocoles supérieurs. Au-dessus se trouvent les mappages de protocoles qui donnent aux bits transportés un sens visible par le logiciel. Cette séparation est la clé de la portabilité: une même liaison générale transporte plusieurs trafics et ne fige pas un protocole sur une technologie de boîtier.

L’adaptateur n’est pas une simple enveloppe. Les documents examinés le décrivent comme assurant la gestion de la liaison, les erreurs, les retransmissions et l’adaptation des protocoles. La frontière de la puce ne peut pas être traitée comme une ligne peu fiable cachée au logiciel. Avant que les couches supérieures ne fassent confiance au chemin, le boîtier doit disposer de mécanismes d’établissement de liaison, de rapport de capacités et de confinement des pannes.

La stratification multiplie aussi les points où les implémentations divergent. Un PHY peut ne supporter qu’une vitesse ou une classe de boîtier. L’adaptateur peut offrir différentes fonctions optionnelles de fiabilité et de gestion; le moteur de protocole peut n’avoir que PCIe, sans CXL. Un vendeur de systèmes peut n’exposer que ce dont son produit a besoin. « UCIe » désigne une famille de spécifications, pas un ensemble de fonctions uniforme.

Ce que l’acheteur et l’intégrateur doivent demander, ce n’est pas « est-ce compatible UCIe? », mais quelle génération, quelle classe de boîtier, quelle vitesse, quelle largeur, quels mappages de protocoles, quelles fonctions de gestion et quelles conditions de test ont été implémentées. Ce n’est que lorsque ces éléments peuvent être déclarés, testés et comparés que la norme devient une infrastructure opérationnelle. Jusque-là, une simple mention de conformité en dit moins qu’il n’y paraît.

L’alignement des versions est en soi une charge d’intégration. Une entreprise de systèmes qualifie un contrôleur pour une génération d’UCIe et un type de boîtier, puis un nouveau chiplet doté d’options plus récentes arrive. La découverte de capacités et la négociation peuvent trouver l’intersection commune, mais elles ne créent pas une fonction qu’un côté ne possède pas. Les équipes produit ont besoin d’une « intersection prise en charge » explicite — vitesse, protocoles, fonctions de gestion, comportements de repli — maintenue à travers les révisions de micrologiciel et de silicium.

Si l’incohérence n’apparaît qu’après avoir figé la puce dans un boîtier, elle coûte bien plus cher qu’une détection sur un connecteur de carte.

La portabilité logicielle obéit au même schéma. Les mappages PCIe et CXL peuvent préserver les modèles de périphériques existants, tandis que le mode raw ou les données de gestion propres au fournisseur réintroduisent du travail sur mesure. Un boîtier qui s’énumère correctement peut exiger de nouveaux pilotes, un micrologiciel, une description de topologie et des politiques de panne. Le test utile ne consiste pas à savoir si le logiciel a reconnu la puce une fois, mais si le même contrat logiciel survit au remplacement du fournisseur et à la prochaine génération du produit.

UCIe fournit le cadre de transport et de capacités; les noms de fonctions et les politiques de cycle de vie doivent être complétés par une autre norme ou par des accords explicites.

Le consortium définit deux grandes classes de canaux. UCIe-S vise les boîtiers standard à faible coût et à densité physique relativement faible; UCIe-A vise les boîtiers avancés à pas de microbilles fin et à forte densité de bande passante. Ainsi, une même famille de spécifications soutient des produits qui ne justifient pas les mêmes interposeurs, ponts ou techniques de report.

C’est un choix commercialement important. Cibler uniquement les boîtiers les plus chers donnerait de hautes performances mais un marché étroit. S’aligner seulement sur les substrats organiques ordinaires ferait manquer la densité qu’exige le calcul avancé. Les deux classes reconnaissent la nécessité de faire fonctionner l’interopérabilité dans des conditions physiques et de coût différentes.

Les contraintes ne disparaissent pas. Les budgets de canal, l’implantation des microbilles et les tolérances de fabrication diffèrent entre boîtiers standard et avancés. Un design qualifié en UCIe-A ne se transposera pas nécessairement tel quel en UCIe-S. Interposeurs, ponts, substrats organiques ou hybrid bonding restent au choix de l’assembleur; les règles des fonderies et des OSAT sont décisives.

Ce que l’on gagne, ce sont des options encadrées. UCIe donne un vocabulaire commun aux deux environnements tout en autorisant des implémentations propres à chaque procédé. Il ne garantit pas qu’un chiplet conçu pour un environnement soit économiquement, mécaniquement et électriquement adapté à l’autre. La classe de boîtier est l’identité du produit, pas une information de déploiement accessoire.

UCIe 3.0 porte la vitesse maximale spécifiée par voie de 32 GT/s à 48 et 64 GT/s pour UCIe-S comme pour UCIe-A. On peut augmenter la bande passante totale sans accroître dans les mêmes proportions le nombre de connexions en bord de puce. C’est attrayant pour les produits d’IA et de HPC où le calcul, la mémoire et des accélérateurs dédiés échangent d’énormes volumes de données sur le périmètre limité du boîtier.

Une vitesse de spécification n’est pas une mesure de produit. La bande passante disponible dépend du nombre de voies, des surcoûts d’encodage et de protocole, de la qualité du canal du boîtier, de la conception du contrôleur et du trafic. L’énergie par bit dépend de l’implémentation physique et des conditions; le rendement dépend de la capacité à fabriquer et tester de façon répétée des canaux complets. La mention de 64 GT/s dans le document définit un mode; elle ne prouve pas que tous les boîtiers peuvent l’exploiter économiquement.

La montée en vitesse complique aussi la vérification. Plus la densité augmente, plus l’intégrité du signal, les marges de timing, le routage du boîtier et le comportement thermique deviennent exigeants. Ce qui fonctionne en démo ne vit pas les mêmes conditions de vieillissement, de tension et de température en production. La formation et les démos des membres montrent des progrès d’ingénierie, mais ne fournissent pas un historique universel de fiabilité sur le terrain.

C’est ici que la valeur et les limites de la norme se croisent. Un objectif partagé de 64 GT/s concentre les investissements des outils et des fournisseurs et rend les problèmes de vérification comparables entre entreprises. Elle doit néanmoins passer par la réalité physique de chaque boîtier.

La gestion est devenue aussi importante que la bande passante

Le canal de données rapide porte la charge, mais un boîtier multi-puces a aussi besoin d’un chemin de contrôle et de gestion à basse vitesse. UCIe dispose d’un mécanisme sideband indépendant du chemin de données principal. Dans la 3.0, la portée définie passe à 100 millimètres au maximum dans les conditions de canal concernées, ce qui assouplit le placement des composants de gestion au sein du system-in-package.

Un composant peut devoir être découvert, interrogé et mis dans un état sûr avant que la liaison rapide ne soit prête. La gestion ne doit pas dépendre du seul chemin qu’elle doit diagnostiquer. Lorsque plusieurs chiplets partagent des ressources et que l’un d’eux se comporte anormalement, les signaux à faible latence et le contrôle d’urgence deviennent particulièrement importants.

Il ne faut pas lire la portée étendue comme une garantie que le canal principal à 64 GT/s peut prendre la même forme. La sideband et le chemin de données n’ont ni le même objectif ni les mêmes exigences électriques. On peut tirer le chemin de gestion plus loin tout en gardant la liaison rapide courte et dense.

Du point de vue du système, c’est la preuve que l’intégration de chiplets ne s’arrête pas au transfert de données. Le boîtier a une dimension opérationnelle. La norme peut fournir un chemin commun, mais chaque fournisseur définit une grande partie des états, des politiques et des réparations qui se cachent derrière les messages. On peut avoir un système nerveux commun sans que tous les organes rapportent le même diagnostic.

Parue le 8 août 2023, UCIe 1.1 a ajouté la surveillance de santé (health monitoring) pour l’automobile et des options de configuration de boîtier à faible coût. Elle a conservé la rétrocompatibilité au sein de la famille de spécifications et élargi la cible au-delà des boîtiers haute performance les plus chers.

Dans les systèmes automobiles, contrairement aux produits accélérateurs à vie courte, la surveillance, la fiabilité et l’utilisation à long terme pèsent lourd. Inscrire l’information de santé dans la spécification, c’est reconnaître que la liaison inter-puces entre aussi dans des systèmes où les pannes latentes et le diagnostic sur site comptent autant que la bande passante de pointe. Le boîtier à faible coût répondait à la pression économique inverse: si l’interopérabilité n’était possible que dans les boîtiers chers, l’adoption resterait limitée.

Qu’une fonction figure 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 à UCIe. Le sens de la 1.1 est dans la direction qu’elle indique: le consortium commençait déjà à comprendre qu’une liaison rapide commune devait, pour dépasser un créneau étroit, s’accompagner de flexibilité des classes de boîtier et de signaux de cycle de vie.

La tendance s’est poursuivie avec les versions 2.0 et 3.0. Chaque génération a standardisé un peu plus des charges d’intégration laissées aux accords privés. Si la spécification s’est étendue, c’est parce que les problèmes les plus difficiles ne se trouvaient pas seulement à l’intérieur du lien d’origine, mais autour de lui. Depuis la deuxième grande révision, l’enjeu est passé de l’établissement de la liaison à l’exploitation du boîtier entier jusqu’à la fin de sa vie.

Annoncée le 6 août 2024, UCIe 2.0 a ajouté une architecture système de gérabilité et la prise en charge des boîtiers 3D. Elle couvre la découverte, le test, la télémétrie, les opérations sur le micrologiciel, le débogage et le contrôle du cycle de vie à travers plusieurs puces, avec le Management Transport Protocol et une conception de test, de débogage et de télémétrie regroupée sous l’appellation DFx.

Cela a profondément changé la définition de l’interopérabilité. Un boîtier peut être inexploitable même si les données circulent correctement. La fabrication teste les puces avant et après l’assemblage; l’équipe micrologiciel identifie les versions et coordonne les mises à jour; les opérateurs de terrain ont besoin de télémétrie et d’isolation des pannes. Le concepteur doit savoir si la panne d’un composant peut être confinée sans arrêt complet.

L’architecture commune donne un transport et une structure partagés, mais ne définit ni tous les objets de gestion, ni les politiques de mise à jour, ni les procédures de maintenance. Un fournisseur peut exposer des informations de santé détaillées, un autre seulement un état minimal. L’entreprise de systèmes peut autoriser des mises à jour coordonnées ou verrouiller le système sur des images approuvées. La norme permet de transporter des messages de gestion entre fournisseurs, mais elle n’efface pas les frontières de politiques.

Dans la pratique, l’épreuve, c’est la responsabilité. Lorsque la télémétrie signale une liaison en état limite, où se trouve la responsabilité du diagnostic: fournisseur de la puce, assembleur ou entreprise de systèmes? Si une mise à jour change le comportement, qui requalifie le boîtier entier? UCIe 2.0 a créé un terrain technique commun, mais n’a pas apporté de réponse contractuelle.

La testabilité, le débogage, la télémétrie et les autres fonctions de cycle de vie sont souvent considérés comme des problèmes d’usine. Dans un système multi-puces, ce sont des questions d’architecture produit. Des puces fabriquées avec des procédés différents, fournies par des entreprises différentes et testées selon des méthodes internes distinctes entrent dans un même boîtier. Après l’assemblage, il faut pouvoir déterminer si la panne se trouve dans une puce, dans la liaison, dans un canal du boîtier, dans l’alimentation partagée ou dans le logiciel de coordination.

Le DFx d’UCIe cherche à donner à tout cela un socle commun. La voie de gestion transporte l’état et les informations de diagnostic; le test et le débogage peuvent être conçus autour d’un modèle de boîtier partagé plutôt qu’autour de connexions dédiées à chaque combinaison. Cela réduit les livrables sur mesure et facilite la continuité des preuves, de la fabrication à l’exploitation.

La norme ne peut pas créer une observabilité qu’un chiplet n’a pas implémentée, ni garantir que le signal rapporté désigne la cause racine. Une puce peut signaler une erreur à cause d’un bruit d’alimentation situé ailleurs. La liaison peut éviter un état limite par un réentraînement sans montrer la marge restant avant la panne. Un problème de rendement observé par l’assembleur peut ne pas se reproduire dans le laboratoire de l’entreprise de systèmes. Le transport partagé déplace les preuves; il ne les rend pas complètes.

Le DFx modifie aussi les frontières commerciales. L’acheteur doit désormais spécifier le périmètre de test, l’accès à la télémétrie et le contrôle du micrologiciel. Une puce propriétaire bien accompagnée par son fournisseur sur le cycle de vie peut être plus utile qu’une puce conforme UCIe dont on ne peut exploiter les diagnostics. L’architecture commune ouvre la voie de la gestion, mais la qualité de la gestion est un choix de produit.

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

La même génération UCIe 2.0 a pris en charge les boîtiers 3D, y compris les puces empilées verticalement et les connexions à très courte distance et haute densité. L’empilement rapproche le calcul et la mémoire, augmente la densité de bande passante et réduit la surface. En revanche, thermique, contraintes mécaniques et rendement de fabrication y sont bien plus étroitement liés qu’en 2D ou 2.5D.

Une norme d’interface aide à définir ce qui traverse la frontière verticale, mais elle ne définit ni le procédé de report, ni la structure thermique, ni le réseau d’alimentation, ni l’ordre dans lequel les puces saines sont validées avant l’assemblage final. Les choix restent aux fonderies, aux sociétés d’assemblage et de test, aux concepteurs de puces et aux entreprises de systèmes.

C’est particulièrement important pour la réparation. La modularité au niveau carte donne l’impression qu’un composant défaillant peut être remplacé, mais une puce au cœur d’un empilement densément reporté ne peut parfois pas être remplacée sur le terrain. Même si le système de gestion identifie la puce en panne, le recours commercial peut être le remplacement du boîtier entier. Réduire le temps de diagnostic ne change rien à la réparabilité physique.

La norme soutient l’intégration 3D sans la rendre facile. Sa contribution est de garder identifiables les frontières de communication et de gestion lorsque la forme du boîtier change; les défis de fabrication autour ne deviennent pas plus légers, mais plus sévères.

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, la mise en réseau et les accélérateurs dédiés exigent un trafic continu ou spécifique à l’application. Le mode raw permet de transporter sans imposer la sémantique de PCIe ou de CXL. La 3.0 a étendu les mappages de transmission continue, notamment pour les voies de données A/N et N/A.

Le mode raw élargit le nombre de systèmes pouvant utiliser la liaison physique, mais il met aussi en évidence l’écart entre interopérabilité électrique et interopérabilité fonctionnelle. Deux sociétés peuvent satisfaire les mêmes exigences de canal et définir, au-dessus de la transmission raw, des trames, des contrôles de flux et des sémantiques applicatives différents. La liaison se connecte, mais les fonctions exigent un autre accord.

Ce n’est pas forcément un échec. Même si le protocole applicatif est propriétaire, le socle physique commun réduit les duplications. Le danger est que « compatible UCIe » serve à laisser croire à une portabilité que le mode raw n’offre pas. L’acheteur doit savoir si le mappage raw est un profil partagé, un contrat bilatéral ou un protocole propre au vendeur.

Le mode raw peut produire deux effets opposés. Il permet de faire tenir plus de types de chiplets sur la même liaison et d’élargir le cercle des fournisseurs, mais il peut aussi laisser subsister, au-dessus, des îlots fonctionnels privés. La direction dépendra de la capacité des implémenteurs à créer un profil raw commun et à publier assez d’informations pour une intégration indépendante.

L’industrie des semi-conducteurs est riche en acronymes, et l’on est tenté de voir des spécifications d’interconnexion comme des concurrentes directes. UCIe, PCIe et CXL traitent des parties différentes. Le PCI-SIG définit l’interconnexion et le modèle de périphériques de PCI Express; le CXL Consortium définit la sémantique de la mémoire cohérente; UCIe définit le canal inter-puces à courte distance dans le boîtier et les mappages qui y circulent.

Cette répartition est l’une des raisons pour lesquelles UCIe a avancé vite. Au lieu de convaincre les systèmes d’exploitation et les vendeurs de périphériques d’adopter une sémantique entièrement nouvelle pour chaque transaction, il a pu transporter une sémantique qui dispose déjà de logiciels, de vérification et d’organisations industrielles.

En même temps, une implémentation UCIe hérite des évolutions et de la complexité des protocoles supérieurs. Un boîtier compatible CXL exige une conception de système cohérent; un mappage PCIe exige énumération, pilotes et gestion des erreurs. Ce n’est pas parce qu’un paquet franchit la frontière des puces qu’un défaut du protocole supérieur devient un défaut d’UCIe.

Le plus clair est d’y voir un empilement de responsabilités. UCIe répond à la question de savoir comment les bits et les paquets protocolaires franchissent la frontière dans des conditions données; PCIe et CXL répondent à ce que signifient nombre de ces paquets. Le micrologiciel et les logiciels d’exploitation décident de la façon dont le système intégré apparaît et dont on s’en sert. Une seule couche ne peut pas revendiquer le résultat de trois.

Un canal inter-puces rapide doit établir que les deux extrémités peuvent communiquer dans les conditions électriques réelles du boîtier. L’analyse de la spécification couvre la négociation de capacités, l’entraînement de la liaison, le recalibrage en fonctionnement et l’écrêtement (throttling). UCIe 3.0 y ajoute le recalibrage en fonctionnement du côté émetteur et des améliorations liées à l’alimentation, pour s’adapter aux variations de procédé, de tension, de température et de conditions d’exploitation.

Un boîtier n’est pas statique. La température varie avec la charge, l’alimentation fluctue, les composants vieillissent. Au lieu de supposer que l’état de fabrication dure toute la vie, il faut des mécanismes qui restaurent les marges ou réduisent l’activité.

Un entraînement réussi est un résultat à portée limitée. Il montre que la liaison s’établit dans les conditions de test, mais il ne prouve pas qu’elle est fiable sous toutes les charges, tous les cycles thermiques et toute la durée de vie. Le recalibrage peut corriger un type de variation et en laisser un autre; l’écrêtement peut maintenir le fonctionnement au prix de la performance.

Pour l’acheteur, des exigences de rapport s’imposent. Il faut distinguer la vitesse maximale de spécification de la vitesse validée dans le boîtier réel, ainsi que les conditions de recalibrage et le comportement quand les marges manquent. Une liaison adaptative gère les variations, mais elle ne transforme pas une fiabilité non mesurée en garantie.

Les preuves de conformité doivent être assez concrètes pour servir une décision d’achat

Une seule mention ne peut pas représenter toutes les implémentations UCIe. Une déclaration de conformité complète exige au minimum la génération de spécification, la classe de boîtier, la vitesse, la configuration des voies, les protocoles pris en charge, les fonctions de gestion optionnelles et les conditions de test. Deux produits peuvent tous deux implémenter UCIe sans offrir de combinaison commune utile.

Dans un programme d’interconnexion mature, la conformité est rattachée à des capacités définies et à des procédures de test, pas à une mention générique. À la date de clôture de l’enquête, l’écosystème public d’UCIe était encore en train de bâtir cette base de preuves. Il y avait des interopérabilités, des sommets, des webinaires et des démos de contrôleurs et de PHY, mais les documents ne permettaient pas de confirmer une liste publique complète de produits certifiés.

Un programme de conformité utile ne doit pas tester seulement l’établissement le plus simple de la liaison. Il doit couvrir le comportement en erreur, la négociation de capacités, les fonctions de gestion et les profils de protocoles pris en charge. La classe de boîtier et les conditions de canal comptent aussi: on ne doit pas étendre un ensemble de résultats à d’autres vitesses ou d’autres boîtiers sans preuves.

L’absence de liste universelle ne signifie pas que les implémentations sont fictives. Cela signifie que les preuves publiques sont jeunes. Une démo de membre peut montrer des outils ou des interfaces indépendants travaillant de concert. La qualification en production exige répétabilité, volumes, conditions de fonctionnement et responsabilité en cas de panne ultérieure.

La distinction protège à la fois l’acheteur et le consortium. Surinterpréter une mention UCIe vague produit des déceptions que la spécification n’a pas été conçue pour éviter. Un profil précis rend plus visibles les réalisations de la norme. La barrière restante, c’est la preuve: l’acheteur doit se voir montrer concrètement les configurations et les limites testées.

Depuis la première version, l’activité est passée de l’explication des concepts à l’implémentation. Les membres ont annoncé des contrôleurs, de l’IP de PHY, des plateformes de vérification et des conceptions de boîtier; les événements ont comporté démos et discussions sur l’intégrité du signal, les boîtiers avancés et l’interopérabilité. Les documents de 2025 présentaient cela comme la preuve d’une adoption croissante.

Une démo répond à des questions ciblées: ce contrôleur et ce PHY peuvent-ils communiquer? Le banc de test détecte-t-il l’erreur prévue? La vitesse cible est-elle atteinte en conditions de laboratoire? Ce sont des questions utiles: elles réduisent l’incertitude d’implémentation et révèlent les divergences d’interprétation de la spécification.

Les questions auxquelles répond un boîtier de production sont plus vastes. Plusieurs fournisseurs peuvent-ils livrer des puces saines dans les délais? Après l’assemblage, les objectifs de rendement et de consommation sont-ils tenus? Le micrologiciel de chaque composant peut-il être mis à jour en toute sécurité? Le logiciel se transfère-t-il d’une révision produit à l’autre? En cas de panne intermittente d’une puce en limite, qui remplace le système? Une démo est une partie de la preuve, pas la solution elle-même.

Les archives publiques ne contiennent pas de liste complète des boîtiers multi-fournisseurs en cours d’expédition. La conclusion prudente va jusqu’à dire que l’écosystème construit ses capacités d’implémentation. Les preuves actuelles ne permettent pas de parler de marché universel.

L’intégrateur ne peut pas évaluer un chiplet simplement parce que la liaison s’établit. Le composant doit être sain pour la fonction prévue, les coins de procédé et le cycle de vie, avec des preuves de test continues du wafer à l’assemblage puis au système final. Si un composant est défectueux après l’intégration, les autres puces et le travail de boîtier sont perdus aussi.

La preuve de known-good die est une exigence non seulement de fabrication, mais aussi commerciale. Il faut s’accorder entre fournisseurs sur ce qui a été testé, les marges appliquées, la présentation des résultats et la prise en charge en cas de défaillance globale. La gestion commune et le DFx aident à transporter les informations de test et de télémétrie, mais ils ne certifient pas les fonctions internes de chaque puce et n’attribuent pas les responsabilités entre entreprises.

C’est aussi une raison pour laquelle un boîtier verticalement intégré garde des avantages: une seule société contrôle la conception des puces, les limites de test, l’assemblage et la garantie. Un boîtier multi-fournisseurs doit transformer des livrables privés en preuves et contrats explicites.

La couche de marché manquante n’a rien de spectaculaire, mais elle décide si la modularité atteint les petits fournisseurs. La liaison électrique commune abaisse une barrière. La garantie de puce saine décide si l’acheteur peut engager le reste du boîtier sur un composant inconnu.

La formation du marché se joue sur la sécurité, la garantie et le logiciel

Un boîtier multi-fournisseurs crée une frontière de confiance très étroite. Les chiplets échangent de grandes quantités de données, partagent des voies de gestion et influent sur des ressources que le système final traite comme un seul appareil. Une puce compromise ou malveillante peut servir de porte d’entrée non seulement vers ses propres fonctions, mais aussi vers les flux de contrôle et de données.

Les spécifications de gestion récentes peuvent soutenir une découverte contrôlée, des opérations sur le micrologiciel et des signaux d’urgence. Les documents des membres citent le renforcement de la sécurité comme un chantier permanent. Mais ils ne définissent pas une sécurité complète du boîtier. Identité des appareils, démarrage sécurisé, provenance du micrologiciel, attestation, isolation, gestion des clés et garanties des fournisseurs relèvent de la responsabilité de l’ensemble du système.

Même avec un transport sécurisé, un chiplet approuvé mais compromis peut adopter un comportement malveillant. Une identité forte indique quelles puces sont présentes, mais elle ne prouve pas que le micrologiciel est sain; un composant attesté peut abuser des accès qui lui sont donnés. Ce qui détermine la sécurité, c’est ce qu’on autorise une fois la confiance établie.

Une future version pourrait définir des fonctions supplémentaires, mais ni le calendrier ni la forme ne peuvent être établis à partir des preuves. Aujourd’hui, « conforme UCIe » n’est pas une certification de sécurité au niveau du boîtier. L’acheteur a besoin d’un modèle de confiance distinct pour chaque fournisseur et pour l’ensemble du système.

UCIe est présenté comme une norme industrielle ouverte, et la spécification peut être demandée publiquement sous des conditions d’évaluation. C’est important: les concepteurs peuvent étudier la structure, les outils convergent vers des concepts communs, et l’on peut discuter de compatibilité sans qu’une entreprise ne possède l’interface.

Le reste de la chaîne d’approvisionnement peut rester concentré. La fabrication avancée de wafers, l’hybrid bonding, les interposeurs, l’assemblage, les équipements de test et l’EDA viennent d’un nombre limité d’entreprises et de régions. Les contrôles à l’exportation et les politiques industrielles conditionnent l’accès aux nœuds, aux outils et à la propriété intellectuelle. Une liaison commune ne crée pas de nouvelles fonderies ni de nouvelles lignes de packaging.

Une norme ouverte n’exige pas des implémentations ouvertes. Contrôleurs UCIe, PHY, conceptions de chiplets, micrologiciels et kits de conception de boîtier peuvent rester propriétaires. Le contrat d’évaluation sépare lui aussi la consultation de la spécification de la licence d’implémentation. Une entreprise peut soutenir la liaison commune tout en dominant fortement ce qui se trouve au-dessus et en dessous.

C’est peut-être un avantage pragmatique. Même si toutes les implémentations ne sont pas open source, le travail bipartite diminue. Le danger est qu’on parle de l’ouverture d’une couche comme si elle couvrait aussi la concurrence ou la portabilité des couches demeurées fermées. Il faut considérer le boîtier couche par couche. Une fois le périmètre de conformité clarifié, les questions difficiles se déplacent vers la confiance, le soutien commercial et la prise en charge du risque d’intégration.

Ce sont les ressources des promoteurs qui rendent UCIe crédible. Ils apportent la technologie, construisent l’interface, qualifient les boîtiers et peuvent créer la demande. En même temps, ils disposent des options les plus fortes, celles qui ne dépendent pas d’un marché ouvert. Les grands fabricants de processeurs, les clouds et les fonderies peuvent, si cela les arrange, concevoir des chiplets propriétaires, des liaisons internes et des flux de packaging.

Cela ne signifie pas que leur participation est hypocrite. On peut n’utiliser UCIe qu’aux frontières externes et garder des liaisons propriétaires dans les produits les plus intégrés. On peut transporter des protocoles communs tout en se différenciant par la topologie, la mémoire et les politiques de gestion. L’adoption peut être stratifiée et sélective plutôt que totale.

Le défi de gouvernance est de garder la frontière partagée utile aussi pour les entreprises qui ne dominent pas toute la pile. Avoir des clouds, des fabricants de processeurs, des fonderies et des assembleurs au conseil est un bon signe, mais les documents fournis ne contiennent pas d’archives publiques complètes des contributions, des votes et du règlement des différends dans les groupes techniques. Deux logos placés au même endroit n’ont pas le même pouvoir de négociation.

La norme peut réussir même si les grands conservent des avantages propriétaires. Le test décisif est de savoir si un petit fournisseur peut fabriquer un chiplet, prouver un profil limité, accéder à un boîtier et le vendre dans plusieurs systèmes sans faire peser sur l’acheteur les risques juridiques et d’intégration.

Une interchangeabilité commerciale exige plus qu’une spécification de liaison. Il faut des métadonnées fonctionnelles indiquant les fonctions, les protocoles et vitesses pris en charge, la manière de découvrir le composant, le micrologiciel requis et la façon dont la santé est rapportée. Le concepteur de boîtier a besoin des conditions électriques, de puissance, thermiques et mécaniques; le logiciel, d’une énumération et d’une gestion stables; l’approvisionnement, de prix, de volumes, de cycle de vie, de garantie et de conditions de responsabilité.

UCIe peut fournir une partie de tout cela par la découverte de capacités, la déclaration de profils et la gestion, mais il ne définit ni une API fonctionnelle complète ni un catalogue de produits universel. Il ne répartit pas la garantie et ne garantit pas les capacités des fonderies. Les documents et les événements parlent d’objectifs de marché, mais les preuves publiques s’arrêtent avant une couche transactionnelle complète.

C’est pourquoi UCIe est important sans être suffisant. La norme crée les conditions du marché, pas le marché lui-même. Il faut que fournisseurs, fonderies, outils et acheteurs rendent l’interface investissable, testable et soutenable.

Dans un marché mature, la responsabilité se lit clairement: on sait si la cause de la panne est le chiplet, la liaison, l’assemblage, le micrologiciel ou l’intégration, et le contrat fixe qui supporte les coûts. Sans ces livrables, la modularité technique peut accroître le risque d’intégration de l’acheteur au lieu de le réduire.

Ce sont les livrables de production qui décideront de la valeur d’UCIe

Le consortium a avancé rapidement, des fondations de 2022 aux ajouts de 2023 (automobile, faible coût), de 2024 (gérabilité, 3D) et de 2025 (64 GT/s, extensions raw et de gestion). En 2026, l’activité publique met davantage l’accent sur la formation, l’implémentation et la vérification que sur de nouveaux numéros de version.

C’est le parcours d’une norme jeune qui apprend où l’intégration casse. La liaison physique a exigé des mappages de protocoles; la liaison, des classes de boîtier; le boîtier, une surveillance de santé, de la gestion, du DFx et la prise en charge de la 3D. La montée en vitesse a exigé recalibrage, contrôle de l’alimentation et sideband flexible. Chaque ajout a déplacé un prérequis privé vers un contrat technique partagé.

La prochaine démonstration viendra d’un autre type de preuves. Il faudra qu’un dispositif de conformité borné montre des profils qui fonctionnent, que des fournisseurs indépendants livrent des puces qui passent l’assemblage et la vérification, que le logiciel découvre et gère sans réécriture pour chaque combinaison, que les contrats répartissent les pannes et les responsabilités de cycle de vie, et que les petits fournisseurs puissent participer sans faire peser sur l’acheteur toute l’incertitude.

UCIe a déjà transformé le débat sur les chiplets. Il a placé une liaison commune et crédible sur une frontière que dominaient les liaisons propriétaires. On saura s’il devient un marché lorsqu’une première panne trans-fournisseurs sera diagnostiquée, que la responsabilité sera attribuée et que la réparation se fera sans revenir à un seul intégrateur vertical. À ce moment-là, la norme passera d’une interface prometteuse à une infrastructure.