Résumé

  • UCIe fournit des règles communes pour la couche physique, l’adaptateur, les protocoles et la gestion des liaisons entre puces, tandis que la fonction des chiplets, l’ingénierie du boîtier et la responsabilité des fournisseurs restent hors de son périmètre
  • Les versions 1.0 à 3.0 ont étendu la norme, initialement centrée sur PCIe, CXL et le transport brut, aux options de boîtiers moins coûteuses, à la surveillance automobile, à la 3D, à la gestion et au fonctionnement à 64 GT/s
  • Sa valeur commerciale deviendra visible grâce à des profils de conformité reproductibles, à des boîtiers multifournisseurs produits et assortis d’un support, ainsi qu’à une responsabilité clairement définie lorsqu’un système associant plusieurs fournisseurs tombe en panne

Une version à 64 GT/s a fait de la vitesse une question de système

Le 5 août 2025, un consortium rendu public depuis un peu plus de trois ans a publié UCIe 3.0, sa troisième spécification majeure. Le document a ajouté des débits de 48 et 64 gigatransferts par seconde aux classes de canaux pour boîtiers standard et avancés, étendu la voie auxiliaire à faible débit, élargi la transmission brute continue et ajouté des commandes de gestion. La vitesse a fourni le titre. Le changement le plus profond était organisationnel: UCIe cherchait à faire fonctionner comme un seul boîtier plusieurs puces conçues indépendamment.

Une liaison plus rapide ne règle qu’une partie de cette tâche. Un acheteur doit encore savoir ce que fait chaque puce, combien d’énergie elle consomme, comment elle est refroidie, quels logiciels peuvent la détecter, comment son micrologiciel est mis à jour, ce qui se passe lorsqu’un composant tombe en panne et quel fournisseur assume la garantie. UCIe normalise la circulation des informations à travers la frontière entre puces et le transport d’une partie du trafic de gestion. Le processeur achevé reste sous la responsabilité des entreprises qui le conçoivent, l’assemblent et le prennent en charge.

Le consortium décrit son ambition comme un « écosystème ouvert de chiplets ». À la date d’arrêt des recherches, les éléments publics montraient des spécifications, l’activité des membres, des formations à la mise en œuvre et des démonstrations. Ils ne fournissaient ni recensement indépendant complet des boîtiers UCIe multifournisseurs commercialisés, ni liste universelle de produits certifiés, ni catalogue permettant à un concepteur de système de choisir des puces interchangeables.

La distinction est déterminante: ces activités montrent qu’un travail de mise en œuvre est en cours, tandis que des achats et une production reproductibles exigent une autre catégorie de preuves.

Les chiplets comptent déjà comme moyen de partitionner des systèmes complexes. La question la plus difficile est de savoir quel degré de modularité une liaison commune peut créer lorsque le boîtier environnant reste étroitement conçu comme un ensemble. UCIe pourrait devenir le langage commun parlé à la frontière entre puces, alors que la plupart des décisions commerciales et physiques resteraient propriétaires. Ses progrès s’évaluent mieux comme une succession de passages de relais, chacun ayant une signification différente.

L’interchangeabilité recouvre en réalité cinq promesses. La compatibilité électrique demande si les émetteurs, les récepteurs et le canal du boîtier peuvent établir une liaison selon le même profil physique. La compatibilité protocolaire demande si les deux extrémités comprennent le même mappage PCIe, CXL ou brut. La compatibilité opérationnelle couvre la détection, les tests, la surveillance et les opérations sur le micrologiciel. La compatibilité fonctionnelle s’étend aux micrologiciels, aux pilotes et aux applications.

L’interchangeabilité commerciale ne commence que lorsqu’un acheteur peut obtenir la pièce avec suffisamment de preuves de test, de volume, de support et de garanties pour l’intégrer à un produit.

UCIe traite directement les deux premières promesses et de plus en plus la troisième. La norme peut rendre la négociation électrique, le transport des protocoles et les passages de relais de gestion moins dépendants d’une conception bilatérale privée. La quatrième couche relève en partie de PCIe, de CXL et de logiciels propres aux produits. La cinquième appartient aux fournisseurs, aux fonderies, aux entreprises d’assemblage et aux acheteurs.

Confondre ces couches conduit soit à minimiser UCIe, soit à en exagérer la portée. La norme possède une valeur avant même l’existence d’un marché abouti, car elle supprime un obstacle physique et protocolaire récurrent. Toutefois, une liaison électrique conforme ne dit à elle seule presque rien du support logiciel, de la gestion du cycle de vie ou de la responsabilité commerciale.

Chaque affirmation devrait préciser le passage de relais qu’elle démontre. Une démonstration d’interface physique établit moins qu’une association protocolaire; une association protocolaire établit moins qu’un boîtier gérable pendant tout son cycle de vie; et un boîtier géré ne permet toujours pas une substitution sans nouveaux logiciels ni nouveaux contrats. Cette hiérarchie montre où le consortium exerce une autorité directe et où les fournisseurs et les acheteurs prennent le relais.

Les progrès peuvent donc être réels bien avant que les chiplets ressemblent à des composants montés sur carte. Une nouvelle spécification peut renforcer les trois premières promesses tandis que l’interchangeabilité fonctionnelle et commerciale mûrit plus lentement. Le marché se construira grâce à des passages de relais plus étroits devenus assez reproductibles pour inspirer confiance.

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

Une puce monolithique place les fonctions d’un système sur une seule grande pièce de silicium. Cette disposition peut simplifier les communications entre fonctions, mais elle les contraint à un seul plan de fabrication. À mesure qu’augmentent les contraintes de conception, de masques et de rendement sur les nœuds avancés, regrouper tous les blocs sur une grande puce devient coûteux et difficile.

Les chiplets offrent une autre voie: les fonctions de calcul, de mémoire, d’entrée-sortie, analogiques, de sécurité et d’accélération peuvent être séparées, fabriquées avec les procédés adaptés à chaque rôle, puis réunies dans un même système en boîtier.

Le partitionnement déplace la complexité de la puce vers le boîtier. Chaque frontière exige une signalisation, une horloge, une gestion des erreurs, une alimentation électrique, une planification thermique, une couverture de test et un comportement visible par les logiciels. Une grande puce monolithique peut perdre en rendement à mesure que sa surface augmente; un boîtier multipuce peut perdre de sa valeur parce qu’une seule puce intégrée est défectueuse, marginale ou mal assemblée.

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

Les composants montés sur carte montrent ce qu’implique une modularité mature: des formats physiques normalisés, des conventions électriques, des fonctions détectables, des fiches techniques, une distribution et des limites de panne comprises. Un chiplet placé dans un boîtier avancé fonctionne dans un environnement physique beaucoup plus contraint. Des puces voisines peuvent partager l’alimentation, la dissipation thermique, la gestion et des canaux à haut débit qui, après assemblage, ne peuvent être inspectés ou remplacés comme un composant monté sur carte.

UCIe vise l’une des frontières récurrentes les plus difficiles: la liaison courte et dense entre puces. Une cible commune peut réduire la répétition des travaux de conception d’interfaces et donner aux fabricants d’outils, aux fournisseurs de propriété intellectuelle d’interface et aux entreprises de systèmes une base de travail partagée. La norme tire sa valeur de la réduction d’une catégorie précise d’ingénierie bilatérale; le reste de l’intégration du boîtier demeure un problème propre au produit.

Avant l’existence d’une interface commune, une entreprise pouvait diviser un système en plusieurs puces tout en restant intégrée verticalement. La liaison entre ces puces pouvait être conçue autour des hypothèses électriques, du protocole, du procédé d’assemblage et du flux de test d’un seul fournisseur. Cette approche offre la liberté d’optimiser la latence, l’énergie et la surface pour un produit particulier. Elle rend aussi difficile la contribution d’un autre fournisseur sans qu’il apprenne et mette en œuvre un contrat privé.

Le piège des liaisons propriétaires est économique autant que technique. Une entreprise de systèmes peut qualifier sa conception de fondée sur des chiplets sans que le module utile soit nécessairement accessible à quiconque d’autre. La réutilisation peut avoir lieu entre ses propres générations de produits tandis que le marché extérieur ne voit qu’un boîtier fermé. L’architecture devient modulaire à l’intérieur d’une frontière d’entreprise et indivisible au-delà.

Les fondateurs d’UCIe ont essayé de créer une frontière commune sans dicter l’ensemble du système. Le consortium définit le comportement de la couche physique, un adaptateur et des mappages de protocoles. Les fournisseurs peuvent toujours choisir la fonction d’un chiplet, la manière dont le boîtier est construit et les caractéristiques exposées. La couche commune proposée est volontairement assez fine pour prendre en charge différents produits, mais assez détaillée pour que des liaisons développées indépendamment puissent respecter une même spécification.

La frontière est difficile à tracer. Trop peu de détails transforment chaque association en intégration sur mesure; trop de détails peuvent figer des choix de conception, favoriser les premières mises en œuvre ou réduire les possibilités de différenciation. L’extension d’UCIe, des bases de la liaison et des protocoles vers la gestion, la conception en vue des tests et l’assemblage 3D, montre la rapidité avec laquelle des hypothèses privées sont réapparues autour de l’interface d’origine. Chaque révision a intégré une nouvelle partie du passage de relais au contrat commun.

Des concurrents ont bâti une organisation à but non lucratif autour d’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 dans le Delaware comme organisation à but non lucratif le 2 août de la même année et a ouvert une structure formelle d’adhésion. La liste des membres promoteurs réunissait des entreprises de la conception de processeurs, des infrastructures cloud, de la fabrication en fonderie, de l’assemblage et des tests, de la mémoire et des accélérateurs. Les documents actuels des promoteurs citent AMD, ASE, Alibaba Cloud, Arm, Google Cloud, Intel, Meta, Microsoft, NVIDIA, Qualcomm, Samsung et TSMC.

La composition des promoteurs compte, car aucun concepteur de processeurs ne peut rendre utile à lui seul une liaison intersectorielle entre puces. Les fonderies ont besoin de canaux et de règles d’assemblage qu’elles peuvent fabriquer. Les entreprises d’assemblage et de test ont besoin de processus qu’elles peuvent qualifier. Les fournisseurs d’automatisation de la conception électronique et de propriété intellectuelle d’interface ont besoin de spécifications qu’ils peuvent transformer en contrôleurs, interfaces physiques et produits de vérification.

Les entreprises de cloud et de systèmes ont besoin de boîtiers adaptés à des charges de travail réelles.

Ces entreprises arrivent aussi avec des incitations concurrentes. Un hyperscaler peut souhaiter des blocs réutilisables tout en préservant une architecture de système privée. Une fonderie peut prendre en charge une liaison électrique commune tout en conservant ses kits propriétaires de conception de boîtiers, ses capacités et sa connaissance des procédés. Une entreprise de processeurs établie peut accueillir favorablement une base de fournisseurs plus large tout en conservant des liaisons internes plus rapides pour certains usages. Le consortium offre à ces intérêts un lieu où s’accorder sur une frontière; il n’efface pas leurs différences.

Le statut de membre relève du registre des preuves, pas de celui des déploiements. Le logo d’un promoteur montre sa participation à la gouvernance et aux travaux techniques; un contributeur peut fournir des outils ou de la propriété intellectuelle; un adoptant peut encore être en train d’évaluer la norme. Ces qualificatifs n’établissent ni qu’un boîtier de production désigné contient des chiplets UCIe provenant de sources indépendantes, ni que les pièces sont commercialement interchangeables. La frontière institutionnelle n’a de valeur que si l’ensemble technique reste utilisable avec différents choix de boîtiers.

L’actuel conseil d’administration d’UCIe cite Debendra Das Sharma d’Intel comme président du conseil, Cheolmin Park de Samsung comme président, 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 de gouvernance sont exercées par l’intermédiaire des organisations membres. Elles ne confèrent ni propriété personnelle de la spécification ni mérite exclusif pour son contenu technique.

L’organisation à but non lucratif fournit un cadre juridique à l’adhésion, aux dispositions relatives à la propriété intellectuelle et aux travaux techniques. Les niveaux promoteur, contributeur et adoptant créent différentes formes de participation. Les copies publiques d’évaluation rendent l’architecture visible, tandis que l’accord distingue une licence limitée d’évaluation interne des droits plus larges de mise en œuvre et d’adhésion. La spécification est publiquement accessible pour étude, mais les conditions fournies ne décrivent pas une conception libre de brevets et appartenant au domaine public.

Pour les petits fournisseurs, la publication réduit le coût d’apprentissage de l’interface. Elle laisse d’autres obstacles intacts: l’incertitude juridique, les outils de vérification, l’accès à l’assemblage et le budget d’ingénierie nécessaire aux canaux à haut débit. Une jeune entreprise peut lire la même spécification qu’un promoteur sans disposer de son portefeuille de brevets, de ses relations dans l’assemblage ni de sa capacité de validation.

Les adhésions financent le consortium, mais les informations fournies ne contiennent aucun état audité de ses revenus, réserves, effectifs ou dépenses par génération de spécification. Son échelle financière propre reste donc inconnue. Les enjeux économiques sont visibles ailleurs, dans les engagements d’ingénierie et de fabrication pris par les membres et les responsables des mises en œuvre.

Les travaux coûteux ont lieu au sein des organisations membres et des fournisseurs. Les entreprises de semi-conducteurs conçoivent les contrôleurs et les puces. Les fournisseurs d’interfaces physiques créent une propriété intellectuelle réutilisable. Les entreprises d’automatisation de la conception électronique ajoutent la modélisation et la vérification. Les fonderies et les entreprises d’assemblage développent les procédés de boîtier. Les entreprises de systèmes financent l’intégration, la qualification et les logiciels.

Une liaison commune peut réduire la duplication des travaux d’ingénierie entre ces activités, mais les économies apparaissent dans l’économie des produits plutôt que dans les revenus du consortium.

L’adhésion répartit également les droits et les risques. Les promoteurs et les contributeurs peuvent participer au développement technique dans le cadre des accords du consortium. L’accès public à l’évaluation donne aux tiers une vue de la spécification, tandis que les droits de mise en œuvre et les protections de propriété intellectuelle dépendent des accords applicables. Il en résulte une référence technique ouverte entourée d’une économie structurée de l’adhésion à la mise en œuvre.

L’influence dépend moins des revenus du consortium que du soutien continu des membres aux spécifications, à leur interprétation, à la conformité et aux révisions futures. Le risque important tient à un changement d’incitations: les entreprises qui supportent le coût de la mise en œuvre peuvent décider que des liaisons propriétaires offrent un meilleur rendement, ou le coût de qualification peut croître plus vite que la valeur d’une interopérabilité élargie.

La spécification reprend des protocoles éprouvés et laisse ouverts les choix d’assemblage

La première spécification n’a pas tenté d’inventer toutes les transactions de niveau supérieur transportées à travers le boîtier. Elle a défini une liaison physique entre puces et un adaptateur capable de transporter des familles de protocoles établies, notamment PCI Express et Compute Express Link, ainsi que du trafic brut. Ce choix a relié une nouvelle frontière interne au boîtier à des modèles logiciels et de périphériques que les développeurs de systèmes connaissaient déjà.

PCIe fournit une sémantique familière pour les relations hôte-périphérique et les entrées-sorties. CXL ajoute, pour les systèmes compatibles, une sémantique liée à la cohérence de la mémoire et des caches. UCIe transporte ces paquets et leur signification à travers une frontière entre puces au sein d’un même boîtier. Un chiplet peut ainsi apparaître dans un environnement d’énumération et de logiciels existant, sans exiger un nouveau modèle d’hôte simplement parce que sa fonction a quitté la puce principale.

Le bénéfice réside dans la continuité, mais la compatibilité dépend toujours du système complet. Un boîtier a besoin d’un micrologiciel, d’une énumération, d’une politique de mémoire, d’une gestion des erreurs et de logiciels qui comprennent le protocole choisi. Deux liaisons UCIe électriquement compatibles peuvent transporter des messages PCIe, CXL ou bruts, et un système d’exploitation prenant en charge une catégorie de périphérique peut ne rien connaître de la fonction d’un autre chiplet.

Les dépendances héritées accompagnent cette sémantique éprouvée. Les évolutions de PCIe ou de CXL peuvent influencer les futurs mappages, et le concepteur d’un boîtier doit qualifier à la fois la liaison et le protocole qui la surplombe. La conformité du transport ne peut corriger ni une erreur de conception de mémoire cohérente ni l’absence d’un pilote. UCIe rend un contrat logiciel existant portable à travers une nouvelle frontière physique; la norme ne simplifie pas toutes les composantes de ce contrat.

L’architecture d’UCIe est organisée en couches. La couche physique gère le court canal électrique entre les puces. Un Die-to-Die Adapter administre la liaison et assure l’intermédiation entre la couche physique et le trafic des protocoles supérieurs. Au-dessus se trouvent les mappages de protocoles qui donnent aux bits transférés une signification visible par les logiciels. Cette séparation est essentielle à la portabilité de la norme: la même architecture générale de liaison peut transporter plusieurs formes de trafic sans rendre un protocole indissociable d’une technologie d’assemblage.

L’adaptateur est plus qu’une enveloppe passive. Les recherches fournies le décrivent comme chargé de la gestion de la liaison, des erreurs, des reprises et de l’adaptation des protocoles. Ces fonctions comptent, car une frontière entre puces ne peut se comporter comme un fil peu fiable caché aux logiciels. Le boîtier a besoin d’une méthode définie pour établir la liaison, signaler ses capacités et contenir les défaillances avant qu’une couche supérieure puisse faire confiance au chemin.

L’organisation en couches crée aussi plusieurs points de divergence possibles entre les mises en œuvre. Une interface physique peut prendre en charge un débit ou une classe de boîtier donnés. Un adaptateur peut mettre en œuvre un ensemble différent de fonctions facultatives de fiabilité ou de gestion. Un moteur de protocole peut prendre en charge PCIe mais pas CXL. Un fournisseur de systèmes peut n’exposer que le sous-ensemble nécessaire à son produit. Le terme « UCIe » désigne donc une famille de spécifications, et non un ensemble uniforme de fonctionnalités.

Une déclaration de produit utile précise la génération UCIe, la classe de boîtier, le débit, la largeur, le mappage de protocole, les fonctions de gestion et les conditions de test. La norme devient une infrastructure opérationnelle lorsque ces détails peuvent être déclarés, testés et comparés. Une affirmation générale de prise en charge en dit beaucoup moins.

L’alignement des versions crée sa propre charge d’intégration. Une entreprise de systèmes peut qualifier un contrôleur avec une génération UCIe et une classe de boîtier données, tandis qu’un nouveau chiplet arrive avec des fonctionnalités facultatives plus récentes. La détection des capacités et la négociation peuvent identifier l’ensemble commun, mais elles ne peuvent créer une fonctionnalité absente à l’une des extrémités.

Les équipes produit ont donc besoin d’une intersection prise en charge: débits, protocoles, fonctions de gestion et comportements de repli déclarés, qui restent stables au fil des révisions du micrologiciel et du silicium. Découvrir l’incompatibilité après que les puces ont été affectées à un même boîtier coûte beaucoup plus cher que de la trouver de part et d’autre d’un connecteur de carte.

La portabilité logicielle suit le même schéma. Les mappages PCIe et CXL peuvent préserver des modèles de périphériques familiers, tandis que le mode brut ou des données de gestion propres à un fournisseur peuvent réintroduire des travaux sur mesure. Un boîtier peut être correctement énuméré tout en exigeant de nouveaux pilotes, micrologiciels, descriptions de topologie ou politiques de panne. Le test pratique consiste à déterminer si un même contrat logiciel survit au remplacement d’un fournisseur et à la révision suivante du produit, plutôt que si le logiciel peut voir la puce une seule fois.

UCIe fournit le transport et le cadre de capacités; la désignation fonctionnelle et la politique de cycle de vie doivent provenir d’autres normes ou d’accords explicites.

Le consortium définit deux grandes classes de canaux. UCIe-S vise les boîtiers standard, y compris des approches moins coûteuses dont la densité physique est moins poussée. UCIe-A vise les boîtiers avancés, avec un pas de connexion plus serré et une densité de bande passante supérieure. Cette distinction permet à une même famille de spécifications de servir des produits qui ne peuvent justifier les mêmes technologies d’interposeur, de pont ou de collage.

Les deux classes constituent un choix commercial autant que technique. Une norme limitée aux boîtiers haut de gamme offrirait un fort potentiel de performance mais un marché étroit; une norme conçue uniquement pour des substrats organiques ordinaires pourrait manquer la densité nécessaire au calcul avancé. UCIe reconnaît que l’interopérabilité doit fonctionner sous différentes contraintes physiques et de coût.

Les contraintes physiques restent distinctes. Les boîtiers standard et avancés ont des budgets de canal, des cartes de connexions et des tolérances de fabrication différents; une conception qualifiée pour UCIe-A ne peut donc pas simplement être transférée vers UCIe-S. Les fabricants de boîtiers choisissent toujours entre interposeurs, ponts, substrats organiques, collage hybride et autres constructions prises en charge, sous réserve des règles des fonderies et des prestataires externes d’assemblage et de test.

Le choix est encadré mais utile. UCIe donne aux concepteurs un vocabulaire commun pour deux environnements de boîtier tout en autorisant une mise en œuvre propre à chaque procédé. Un chiplet destiné à un environnement peut rester non rentable, mécaniquement incompatible ou électriquement non qualifié dans l’autre. La classe de boîtier fait partie de l’identité du produit plutôt que d’être un détail accessoire de déploiement.

UCIe 3.0 a porté le débit maximal spécifié par ligne de 32 GT/s à 48 et 64 GT/s pour UCIe-S comme pour UCIe-A. Des débits de transfert plus élevés peuvent accroître la bande passante totale sans augmentation proportionnelle du nombre de connexions sur le bord des puces. Cette possibilité est intéressante pour les boîtiers destinés à l’intelligence artificielle et au calcul haute performance, où le calcul, la mémoire et les accélérateurs spécialisés échangent d’importants volumes de données sur un périmètre de boîtier limité.

La valeur de 64 GT/s définit un mode, pas un résultat mesuré sur un produit. La bande passante utilisable dépend du nombre de lignes, de l’encodage et des surcharges protocolaires, de la qualité du canal du boîtier, de la conception du contrôleur et du trafic. L’énergie par bit dépend de la mise en œuvre et des conditions d’exploitation; le rendement dépend de la possibilité de fabriquer et de tester le canal complet de manière répétée. La valeur inscrite dans le document en dit peu sur l’économie d’un boîtier précis.

Le mode plus rapide peut aussi intensifier la vérification. L’intégrité du signal, les marges temporelles, le routage du boîtier et le comportement thermique deviennent plus difficiles à maîtriser à mesure que la densité augmente. Une mise en œuvre peut réussir lors d’une démonstration tout en rencontrant en production d’autres conditions de vieillissement, de tension ou de température. Les formations du consortium et les démonstrations de ses membres montrent que l’ingénierie progresse, mais elles ne fournissent pas un historique universel de fiabilité sur le terrain.

C’est ici que se rencontrent la valeur de la norme et sa limite. Une cible commune de 64 GT/s peut concentrer les investissements des fabricants d’outils et des fournisseurs. Elle peut rendre les problèmes de vérification comparables entre entreprises. La cible doit néanmoins survivre à la réalité physique de chaque boîtier.

La gestion est devenue aussi importante que la bande passante

Les canaux à haut débit transportent la charge de travail, mais un boîtier multipuce a également besoin d’une voie plus lente pour le contrôle et la gestion. UCIe comprend un mécanisme auxiliaire distinct du chemin de données principal. La version 3.0 a étendu la portée auxiliaire définie jusqu’à 100 millimètres dans les conditions de canal correspondantes, ce qui permet de placer plus librement les composants gérés à l’intérieur d’un système en boîtier.

La voie auxiliaire compte, car un composant peut devoir être détecté, interrogé ou placé dans un état sûr avant que la liaison à haut débit ne soit prête. Les fonctions de gestion ne devraient pas dépendre entièrement du chemin qu’elles cherchent à diagnostiquer. Une signalisation à faible latence et des commandes d’urgence peuvent devenir particulièrement importantes lorsque plusieurs chiplets partagent les ressources du boîtier et que l’un d’eux se comporte de façon inattendue.

La portée étendue ne doit pas être interprétée comme la promesse que le canal principal à 64 GT/s peut suivre la même géométrie. Les voies auxiliaire et de données ont des finalités et des exigences électriques différentes. Un boîtier peut utiliser la voie de gestion sur une plus grande distance interne tout en conservant des liaisons à haut débit courtes et denses.

La voie auxiliaire montre que l’intégration de chiplets exige un plan opérationnel en plus d’un plan de données. UCIe peut normaliser la route empruntée par le trafic de gestion, mais chaque fournisseur décide encore quels états exposer, quelles politiques appliquer et comment fonctionne la récupération.

Publiée le 8 août 2023, UCIe 1.1 a ajouté une surveillance de l’état liée aux usages automobiles et des options destinées aux configurations de boîtiers moins coûteuses. La mise à jour était rétrocompatible au sein de la famille de spécifications et élargissait la cible au-delà des boîtiers haute performance les plus coûteux.

Les systèmes automobiles accordent un poids différent à la surveillance, à la fiabilité et aux longues durées de service par rapport à un accélérateur à courte durée de vie. L’intégration d’informations sur l’état à la spécification reconnaissait qu’une liaison entre puces peut se trouver dans des systèmes où les défaillances latentes et le diagnostic sur le terrain comptent autant que la bande passante maximale. Les options de boîtiers moins coûteuses répondaient à la pression économique inverse: l’interopérabilité a une portée limitée si elle exige exclusivement des boîtiers haut de gamme.

Les plateformes automobiles, les cycles de qualification et la responsabilité des fournisseurs restent hors du contrôle d’UCIe; les fonctionnalités de la version 1.1 doivent donc être lues comme une orientation plutôt que comme une preuve d’adoption. Le consortium apprenait déjà qu’une liaison commune à haut débit avait besoin de flexibilité dans les boîtiers et de signaux de cycle de vie pour servir plus qu’un segment étroit.

Cette tendance s’est poursuivie avec les versions 2.0 et 3.0. Chaque génération a normalisé une autre partie de la charge d’intégration auparavant laissée aux accords privés. La norme s’est développée parce que les problèmes les plus difficiles du marché se trouvaient autour de la liaison d’origine autant qu’à l’intérieur. À la deuxième révision majeure, la tâche était passée de l’établissement de la liaison à l’exploitation du boîtier complet dans la durée.

UCIe 2.0, publiée le 6 août 2024, a ajouté une architecture de gestion du système et la prise en charge des boîtiers 3D. Le travail sur la gestion portait sur la détection, les tests, la télémétrie, les opérations sur le micrologiciel, le débogage et le contrôle du cycle de vie entre plusieurs puces. Il comprenait un Management Transport Protocol et une architecture de conception en vue des tests, du débogage et de la télémétrie, souvent regroupés sous l’abréviation DFx.

Ce changement a sensiblement modifié la définition de l’interopérabilité. Un boîtier peut transférer correctement les données tout en restant impossible à gérer en exploitation. Les équipes de fabrication doivent tester les puces avant et après l’assemblage. Les équipes chargées des micrologiciels doivent identifier les versions et coordonner les mises à jour. Les exploitants ont besoin de télémétrie et d’isolation des pannes. Un concepteur de systèmes doit savoir si un composant défaillant peut être contenu sans arrêter l’ensemble du boîtier.

L’architecture donne à ces activités un transport et un modèle structurel communs. Les éléments de gestion, la politique de mise à jour et les procédures de service continuent de varier. Un fournisseur peut exposer une télémétrie détaillée de l’état tandis qu’un autre ne révèle qu’un état minimal; une entreprise de systèmes peut coordonner les mises à jour des micrologiciels ou limiter le boîtier à un ensemble d’images approuvées. UCIe transporte les messages de gestion entre fournisseurs, mais la politique reste une décision propre au produit.

La responsabilité constitue le test pratique. Lorsque la télémétrie désigne une liaison marginale, les parties doivent savoir si le fournisseur de la puce, l’assembleur du boîtier ou l’entreprise de systèmes prend en charge le diagnostic. Lorsqu’une mise à jour modifie le comportement, quelqu’un doit certifier de nouveau le boîtier complet. UCIe 2.0 a créé un cadre commun pour ces questions; les contrats doivent encore y répondre.

La conception en vue des tests, le débogage, la télémétrie et les fonctions connexes du cycle de vie sont facilement considérés comme de simples préoccupations d’usine. Dans un système multipuce, ils font partie de l’architecture du produit. Un boîtier peut contenir des puces fabriquées selon différents procédés, fournies par différentes entreprises et testées avec différentes méthodes internes. Une fois l’ensemble assemblé, le système doit pouvoir déterminer si une panne provient d’une puce, de la liaison, du canal du boîtier, de l’alimentation partagée ou des logiciels qui les coordonnent.

L’architecture DFx d’UCIe cherche à donner à ces fonctions une infrastructure commune. Une voie de gestion peut transporter des informations d’état et de diagnostic. Les fonctions de test et de débogage peuvent être conçues autour d’un modèle partagé du boîtier plutôt que d’une connexion propriétaire distincte pour chaque association. Cela peut réduire le nombre de passages de relais sur mesure et faciliter la conservation des preuves tout au long des cycles de fabrication et d’exploitation.

Un transport commun ne peut créer une observabilité qu’un chiplet n’a jamais mise en œuvre, et un signal rapporté peut éloigner de la cause profonde. Une puce peut signaler une erreur provoquée par du bruit électrique ailleurs; une liaison peut se réentraîner pour contourner une condition marginale sans indiquer sa proximité avec la panne; un assembleur peut constater un problème de rendement qui disparaît dans le laboratoire de l’entreprise de systèmes. UCIe facilite la circulation des preuves, mais celles-ci peuvent rester incomplètes.

DFx modifie aussi la frontière commerciale. La couverture de test, l’accès à la télémétrie et les droits de contrôle du micrologiciel deviennent des sujets que les acheteurs peuvent devoir préciser. Une puce conforme à UCIe mais dotée de diagnostics inaccessibles pourrait être moins utile qu’une puce propriétaire dont le fournisseur assure un meilleur support du cycle de vie. L’architecture commune ouvre une voie à la gestion. La qualité de cette gestion reste une décision propre au produit.

Les boîtiers tridimensionnels élargissent l’espace de conception et la surface de défaillance

La même génération UCIe 2.0 a ajouté la prise en charge des boîtiers 3D, notamment pour des usages associés à des puces empilées verticalement et à des connexions très courtes et très denses. L’empilement peut rapprocher le calcul et la mémoire, accroître la densité de bande passante et réduire l’encombrement du boîtier. Il peut aussi coupler plus étroitement la chaleur, les contraintes mécaniques et le rendement de fabrication que dans une disposition 2D ou 2,5D.

La norme d’interface définit ce qui traverse la frontière verticale. Les fonderies, les prestataires d’assemblage et de test, les concepteurs de puces et les entreprises de systèmes choisissent toujours le procédé de collage, l’empilement thermique, le réseau d’alimentation et la séquence permettant d’établir que les puces sont conformes avant l’assemblage final.

Ce point est particulièrement important pour la réparation. La modularité au niveau de la carte suggère qu’un composant défaillant peut être remplacé. Un boîtier multipuce à collage dense peut n’offrir aucun moyen pratique de remplacer sur le terrain une seule puce interne. Le système de gestion peut identifier le composant défaillant, mais le recours commercial peut rester le remplacement du boîtier complet. Un meilleur diagnostic peut réduire le temps d’enquête sans modifier la réparabilité physique.

UCIe maintient une frontière reconnaissable pour les communications et la gestion lorsque la géométrie du boîtier change. Cette prise en charge est utile précisément parce que le problème de fabrication environnant devient plus exigeant en trois dimensions.

PCIe et CXL donnent à UCIe une voie logicielle établie, mais tous les chiplets ne se comportent pas comme des périphériques d’entrée-sortie conventionnels ou des composants de mémoire cohérente. Les fonctions de traitement du signal, de réseau et d’accélération spécialisée peuvent avoir besoin d’un trafic continu ou propre à une application. Le mode brut d’UCIe permet de transporter ce trafic sans imposer la sémantique de PCIe ou de CXL. La version 3.0 a étendu les mappages de transmission continue, notamment pour des usages associés aux chemins de données analogique-numérique et numérique-analogique.

Le mode brut augmente le nombre de systèmes pouvant utiliser la liaison physique. Il met aussi en évidence la distinction entre interopérabilité électrique et interopérabilité fonctionnelle. Deux fournisseurs peuvent respecter les mêmes exigences de canal tout en définissant différemment le cadrage des messages, le contrôle de flux ou la signification applicative au-dessus du transport brut. La liaison connecte les composants; les fonctions ont encore besoin d’un accord distinct.

Cette répartition des rôles peut être raisonnable. Une infrastructure physique commune peut réduire la duplication des interfaces même lorsque le protocole applicatif reste spécialisé. Le problème commence lorsque l’expression « prend en charge UCIe » sert à suggérer une portabilité que le mode brut n’a jamais fournie. Les acheteurs doivent savoir si un mappage relève d’un profil partagé, d’un contrat bilatéral ou d’un protocole propre à un fournisseur.

Le mode brut peut agir dans deux directions. Il élargit la gamme de chiplets pouvant utiliser la liaison physique, mais peut préserver des îlots fonctionnels privés au-dessus de cette liaison. Des profils bruts communs et des informations de mise en œuvre suffisantes détermineront lequel de ces effets dominera.

Le secteur des semi-conducteurs regorge de sigles d’interconnexion, et il est tentant de les considérer comme des concurrents directs. UCIe, PCIe et CXL interviennent à différents niveaux du problème. PCI-SIG définit l’interconnexion et le modèle de périphérique PCI Express. Le CXL Consortium définit la sémantique de mémoire cohérente et des protocoles associés. UCIe définit un court canal entre puces au niveau du boîtier et des mappages capables de transporter ces protocoles.

Cette réutilisation a aidé UCIe à progresser rapidement. Les systèmes d’exploitation et les fournisseurs de périphériques n’ont pas eu à apprendre une signification entièrement nouvelle pour chaque transaction, car la sémantique transportée disposait déjà de logiciels, de pratiques de validation et d’organisations sectorielles.

Les protocoles supérieurs apportent leurs propres évolutions et modes de défaillance. Un boîtier compatible CXL nécessite toujours une conception cohérente du système, et un chiplet mappé sur PCIe exige toujours une énumération, des pilotes et une gestion des erreurs. Une défaillance au-dessus de la liaison reste une défaillance au-dessus de la liaison, même si le paquet a traversé une frontière UCIe.

La responsabilité peut se lire par couches. UCIe définit la manière dont les bits et les paquets de protocole franchissent la frontière du boîtier dans les conditions indiquées. PCIe ou CXL donne une signification à nombre de ces paquets. Le micrologiciel et les logiciels d’exploitation déterminent comment le système combiné est exposé et utilisé. Le résultat du produit appartient à l’ensemble de cette pile.

Un canal à haut débit entre puces doit établir que ses deux extrémités peuvent communiquer dans les conditions électriques réelles du boîtier. L’analyse de la spécification fournie décrit la négociation des capacités, l’entraînement de la liaison, le réétalonnage en cours d’exécution et les commandes de limitation. UCIe 3.0 a ajouté le réétalonnage de l’émetteur en cours d’exécution et des améliorations liées à l’énergie afin d’aider la liaison à s’adapter aux variations de procédé, de tension, de température et de conditions d’exploitation.

L’adaptation est essentielle, car un boîtier n’est pas statique. La température évolue avec la charge de travail. Les conditions d’alimentation varient. Les composants vieillissent. La liaison a besoin de mécanismes permettant de restaurer une marge ou de réduire l’activité, au lieu de supposer que les conditions mesurées lors de la fabrication resteront inchangées pendant toute la durée de service.

L’entraînement confirme que deux extrémités ont établi une liaison dans les conditions testées. La fiabilité à long terme face aux charges de travail, aux cycles thermiques et au vieillissement constitue une affirmation distincte. Le réétalonnage peut corriger une forme de dérive tandis qu’un autre mécanisme de défaillance persiste, et la limitation peut préserver le fonctionnement au prix des performances.

Les acheteurs ont donc besoin d’affirmations qui distinguent le débit maximal spécifié du débit validé dans le boîtier, précisent les conditions dans lesquelles le réétalonnage fonctionne et expliquent ce qui arrive lorsque la marge est insuffisante. L’adaptation gère le changement; elle ne transforme pas une fiabilité non mesurée en garantie.

Les preuves de conformité doivent devenir assez précises pour permettre l’achat

Une étiquette unique est trop générale pour la famille UCIe. Une déclaration de conformité complète doit indiquer la génération de la spécification, la classe de boîtier, le débit, la disposition des lignes, le mappage de protocole pris en charge, les fonctions de gestion facultatives et les conditions de test. Deux produits peuvent tous deux mettre en œuvre UCIe sans partager aucune combinaison utilisable au niveau de performance requis.

Cette situation est familière dans les programmes d’interconnexion matures, où la conformité est liée à des capacités et procédures de test définies plutôt qu’à une association générale avec la norme. À la date d’arrêt des recherches, l’écosystème public d’UCIe développait encore cette base de preuves. Le consortium promouvait des travaux d’interopérabilité, des sommets techniques, des webinaires et des démonstrations de contrôleurs et d’interfaces physiques, mais les informations fournies n’identifiaient pas de liste publique complète de produits certifiés.

Un programme de conformité mature doit tester davantage que l’établissement le plus simple d’une liaison. Il devrait couvrir le comportement en cas d’erreur, la négociation des capacités, les fonctions de gestion et les profils de protocoles pris en charge, tout en enregistrant la classe de boîtier et les conditions du canal. Le résultat d’une association ne peut être étendu à un autre débit ou boîtier sans preuve.

L’absence de liste universelle doit être comprise comme le signe d’une base publique de preuves encore immature, et non comme la preuve que les mises en œuvre sont fictives. Les démonstrations des membres peuvent montrer que des outils ou interfaces indépendants fonctionnent ensemble. La qualification pour la production ajoute la reproductibilité, les volumes, les conditions d’exploitation et la responsabilité lorsqu’une association échoue par la suite.

La précision protège les acheteurs comme le consortium. Une étiquette UCIe générale peut laisser entendre des garanties que la spécification n’a jamais formulées; un profil délimité rend visible l’accomplissement réel de la norme. Les acheteurs ont besoin d’affirmations qui identifient la configuration exacte et ses limites.

Depuis la première publication, l’activité du consortium est passée de l’explication du concept à sa mise en œuvre. Des membres ont annoncé des contrôleurs, de la propriété intellectuelle de couche physique, des plateformes de vérification et des travaux de conception de boîtiers. Des événements sectoriels ont présenté des démonstrations UCIe et des séances sur l’intégrité du signal, les boîtiers avancés et l’interopérabilité. Les documents du consortium sur l’écosystème en 2025 ont présenté ces évolutions comme la preuve d’une adoption croissante.

Une démonstration répond à une question ciblée. Ce contrôleur peut-il communiquer avec cette interface physique? Une plateforme de test peut-elle détecter une erreur définie? Un canal de boîtier peut-il atteindre le débit cible en laboratoire? Ces questions sont utiles. Elles réduisent l’incertitude de mise en œuvre et révèlent les divergences d’interprétation de la spécification.

Un boîtier de production répond à un ensemble de questions plus large. Plusieurs fournisseurs peuvent-ils livrer dans les délais des puces reconnues conformes? Le boîtier assemblé atteint-il les objectifs de rendement et de consommation? Le micrologiciel peut-il mettre à jour chaque composant en toute sécurité? Les logiciels sont-ils portables entre les révisions du produit? Qui remplace le système lorsqu’une puce marginale provoque une panne intermittente? Une démonstration peut apporter des éléments de réponse sans résoudre ces questions.

À la date d’arrêt, les preuves étayaient une capacité de mise en œuvre croissante plutôt qu’un marché universel. Les informations fournies ne contenaient aucun inventaire complet des boîtiers multifournisseurs commercialisés; les démonstrations et la propriété intellectuelle annoncée doivent donc rester dans leur propre catégorie de preuves.

Un intégrateur de systèmes ne peut évaluer un chiplet uniquement en vérifiant que sa liaison s’établit. La conformité de la puce doit être connue pour la fonction, le coin de procédé et le cycle de vie visés. Elle a besoin de preuves de test qui survivent au passage de la tranche à l’assemblage du boîtier, puis au système final. Si un composant est défectueux après l’intégration, le coût peut englober les autres puces et les travaux d’assemblage qui l’entourent.

La preuve qu’une puce est reconnue conforme constitue donc une exigence commerciale autant qu’une exigence de fabrication. Les fournisseurs doivent s’accorder sur ce qui a été testé, les marges applicables, la représentation des résultats et la partie qui supporte la perte lorsque le boîtier complet échoue. Un cadre commun UCIe de gestion et de DFx peut aider à transporter les informations de test et de télémétrie. Il ne peut ni certifier la fonction interne de chaque puce ni répartir la responsabilité entre 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 des puces, les limites de test, l’assemblage du boîtier et la garantie du produit même lorsqu’elle utilise plusieurs puces internes. Un boîtier multifournisseur doit transformer ces passages de relais privés en preuves et contrats explicites.

La couche commerciale manquante n’est pas spectaculaire, mais elle déterminera si la modularité atteint les petits fournisseurs. Une liaison électrique commune abaisse un obstacle. Les garanties portant sur les puces reconnues conformes déterminent si un acheteur peut risquer le reste du boîtier sur un composant peu familier.

La sécurité, les garanties et les logiciels décideront de la formation d’un marché

Un boîtier multifournisseur crée une frontière de confiance exceptionnellement étroite. Les chiplets peuvent échanger de grands volumes de données, partager des voies de gestion et influencer des ressources que le système final traite comme un seul périphérique. Une puce compromise ou malveillante peut donc menacer davantage que sa propre fonction. Elle peut devenir une voie d’accès aux flux de contrôle et de données du boîtier.

Les travaux plus récents d’UCIe sur la gestion peuvent soutenir une détection contrôlée, les opérations sur les micrologiciels et la signalisation d’urgence. Les documents d’adhésion du consortium ont aussi cité le renforcement de la sécurité parmi les travaux en cours. Ces mécanismes sont pertinents, mais ils ne définissent pas une architecture de sécurité complète pour le boîtier. L’identité des périphériques, le démarrage sécurisé, la provenance des micrologiciels, l’attestation, l’isolation, la gestion des clés et l’assurance des fournisseurs restent des responsabilités plus larges du système.

La frontière de sécurité est concrète. Un transport protégé peut acheminer des messages provenant d’un chiplet autorisé mais compromis. Une identité forte indique au système quelle puce est présente, tandis que la sûreté du micrologiciel et les comportements autorisés restent des questions distinctes. L’attestation aide à établir un état; l’architecture du boîtier décide toujours ce que le composant peut faire une fois la confiance accordée.

Une future génération d’UCIe pourrait définir davantage de fonctions de sécurité. Les preuves fournies n’établissent ni leur calendrier ni leur forme. Pour l’heure, la conformité à UCIe ne doit pas être interprétée comme une certification de sécurité au niveau du boîtier. Les acheteurs ont besoin d’un modèle de confiance distinct pour chaque fournisseur et pour le système complet.

UCIe est décrite comme une norme industrielle ouverte, et ses spécifications peuvent être demandées publiquement selon des conditions d’évaluation. Cette ouverture compte: les équipes de conception peuvent étudier l’architecture, les outils peuvent converger vers des concepts communs et les entreprises peuvent discuter de compatibilité sans qu’un seul fournisseur possède l’interface.

Le reste de la chaîne d’approvisionnement peut rester très concentré. La fabrication avancée de tranches, le collage hybride, les interposeurs, l’assemblage des boîtiers, les équipements de test et l’automatisation de la conception électronique proviennent d’un nombre limité d’entreprises et de régions. Les contrôles à l’exportation et les politiques industrielles peuvent affecter l’accès aux nœuds de fabrication, aux outils et à la propriété intellectuelle. Une liaison commune ne crée ni nouvelle fonderie ni nouvelle chaîne d’assemblage.

Une norme ouverte n’exige pas non plus une mise en œuvre ouverte. Un contrôleur UCIe, une interface physique, une conception de chiplet, une pile de micrologiciels ou un kit de conception de boîtier peuvent rester propriétaires. L’accord d’évaluation lui-même distingue la lecture de la spécification d’une licence permettant sa mise en œuvre. Une entreprise peut prendre en charge la liaison commune tout en conservant un contrôle substantiel au-dessus et au-dessous.

Cette combinaison peut constituer la force réaliste d’UCIe. Des contrôleurs, micrologiciels et conceptions de boîtiers propriétaires peuvent néanmoins partager une liaison commune et réduire les travaux d’interface bilatéraux. Le risque consiste à traiter l’ouverture d’une couche comme la preuve d’une concurrence ou d’une portabilité à toutes les autres. Le boîtier doit être cartographié couche par couche; la confiance, le support commercial et le risque d’intégration deviennent alors visibles.

Les entreprises promotrices disposent des ressources nécessaires pour rendre UCIe crédible. Elles peuvent apporter leur expertise technique, construire des interfaces, qualifier des boîtiers et créer une demande. Elles possèdent aussi les solutions de remplacement les plus solides à un marché ouvert. Les grandes entreprises de processeurs, de cloud et de fonderie peuvent concevoir des chiplets, des liaisons internes et des processus d’assemblage propriétaires lorsque ces choix leur procurent un avantage.

Un usage sélectif est conforme aux incitations des membres. Une entreprise peut déployer UCIe aux frontières externes et conserver une interface privée dans son produit le plus intégré, tout en se différenciant par la topologie du boîtier, la conception de la mémoire ou la politique de gestion. L’adoption peut être organisée par couches plutôt que totale.

Le défi de gouvernance consiste à maintenir une frontière commune utile aux entreprises qui ne contrôlent pas toute la pile. La diversité publique du conseil aide, car les intérêts du cloud, des processeurs, des fonderies et de l’assemblage y sont représentés. Les informations fournies ne donnent pas de compte rendu public complet du poids des contributions, des votes ou de la résolution des désaccords dans les groupes de travail techniques. Une présentation identique des logos ne doit pas être confondue avec un pouvoir de négociation égal.

Une norme peut réussir même lorsque les plus grands membres conservent des avantages privés. Le test le plus exigeant consiste à déterminer si un petit fournisseur peut construire un chiplet, démontrer un profil délimité, accéder à l’assemblage et vendre à plusieurs systèmes sans transférer à l’acheteur un risque juridique et d’intégration ingérable.

Pour qu’un chiplet devienne commercialement interchangeable, l’acheteur a besoin de beaucoup plus qu’une spécification de liaison. La pièce a besoin de métadonnées fonctionnelles: ce qu’elle fait, les protocoles et débits pris en charge, la manière dont elle est détectée, le micrologiciel requis et la façon dont elle signale son état. Le concepteur du boîtier a besoin des contraintes électriques, énergétiques, thermiques et mécaniques. L’équipe logicielle a besoin d’un comportement stable d’énumération et de gestion. Les achats ont besoin de prix, de volumes, de conditions de cycle de vie, de garantie et de responsabilité.

La détection des capacités, les déclarations de profils et la gestion peuvent fournir une partie de ces informations. La norme actuelle s’arrête encore avant une interface de programmation applicative fonctionnelle complète, un catalogue universel de produits, des garanties ou des capacités de fonderie. Les documents d’UCIe et les événements publics décrivent l’objectif d’un marché viable des chiplets, tandis que les preuves publiques s’arrêtent avant une couche transactionnelle complète.

UCIe peut avoir des conséquences avant l’existence d’un marché complet. Les normes créent souvent les conditions d’un marché plutôt que les transactions elles-mêmes, laissant aux fournisseurs, aux fonderies, aux fabricants d’outils et aux acheteurs le soin de rendre l’interface finançable, testable et assortie d’un support.

Un marché mature rendrait la responsabilité lisible. Lorsqu’un boîtier tombe en panne, les parties sauraient si la cause réside dans le chiplet, la liaison, l’assemblage, le micrologiciel ou l’intégration du système, et le contrat préciserait qui supporte le coût. Tant que ces passages de relais n’existent pas, la modularité technique peut laisser à l’acheteur davantage de risques d’intégration, et non moins.

Les passages de relais en production détermineront la valeur d’UCIe

Le consortium est rapidement passé d’une base de référence en 2022 à des options automobiles et moins coûteuses en 2023, à la gestion et à la prise en charge de la 3D en 2024, puis à 64 GT/s avec des fonctions brutes et de gestion élargies en 2025. En 2026, ses travaux publics portaient de plus en plus sur la formation, la mise en œuvre et la validation plutôt que sur l’annonce d’une nouvelle spécification numérotée.

Cette succession indique les endroits où l’intégration continuait d’échouer. Les mappages de protocoles ont suivi la liaison physique; les classes de boîtiers ont suivi les premiers profils; la surveillance de l’état, la gestion, DFx et la prise en charge de la 3D ont suivi le boîtier; les débits supérieurs ont entraîné le réétalonnage, les commandes d’alimentation et une gestion auxiliaire plus souple. Chaque ajout a transformé une nouvelle hypothèse privée en élément du contrat commun.

La prochaine démonstration viendra d’une autre catégorie de preuves. Un régime de conformité délimité doit montrer quels profils fonctionnent. Des fournisseurs indépendants doivent livrer des puces qui survivent à l’assemblage du boîtier et à la validation du système. Les logiciels doivent détecter et gérer les composants sans réécriture sur mesure pour chaque association. Les contrats doivent répartir la responsabilité des pannes et du cycle de vie. Les petits fournisseurs doivent pouvoir participer sans contraindre l’acheteur à absorber toute l’incertitude.

UCIe a déjà changé les termes du débat sur les chiplets en proposant une liaison commune crédible là où dominaient auparavant des liaisons propriétaires. Sa valeur commerciale deviendra visible lorsqu’une défaillance entre fournisseurs pourra être diagnostiquée, attribuée et corrigée sans que chaque décision doive remonter vers un seul fournisseur intégré verticalement. L’interface commencera alors à fonctionner comme une infrastructure.