La promesse des chiplets et le problème de l’intégration

Diviser un processeur en plusieurs puces permet d’attribuer des fonctions différentes à des blocs de silicium et, potentiellement, de combiner des procédés de fabrication. Cette modularité peut éviter qu’une conception entière dépende d’une seule grande puce, mais elle ne supprime pas le travail d’intégration : les chiplets doivent communiquer dans le boîtier avec des contraintes strictes de consommation, d’espace et de signal. La norme UCIe — Universal Chiplet Interconnect Express — vise à fournir une base commune pour cette communication die-to-die et pour certains protocoles et fonctions associés. À elle seule, elle ne constitue ni une conception de processeur, ni un format universel de boîtier, ni la garantie que deux composants de fournisseurs différents fonctionneront ensemble sans adaptation.

Cette distinction est importante pour évaluer une conception modulaire : « utiliser des chiplets » décrit une architecture ; « utiliser UCIe » décrit une interface régie par une spécification précise. Même avec une interface commune, les entreprises doivent choisir l’implémentation physique, la distribution des signaux, l’alimentation électrique, la gestion thermique et la stratégie de test. Combiner des procédés ou des fournisseurs peut apporter de la souplesse, mais ajoute aussi du travail de conception et de validation. Il faut donc considérer la baisse des coûts ou l’amélioration des performances comme des possibilités qui dépendent du cas, et non comme des conséquences automatiques de l’adoption de la norme. UCIe fournit un élément commun du système, sans remplacer l’analyse de viabilité du boîtier complet.

Ce que définit UCIe : interface, protocoles et gestion

Le consortium décrit UCIe comme une spécification d’interconnexion au niveau du boîtier qui couvre une couche physique d’E/S die-to-die, des protocoles die-to-die et une pile logicielle exploitant PCI Express et Compute Express Link. En pratique, la spécification vise à permettre aux équipes de s’accorder sur les aspects de connexion et de transport, plutôt que de réinventer chaque liaison entre puces. La version 1.1 a ajouté, entre autres, des mécanismes de fiabilité et des attributs architecturaux destinés à soutenir les plans de test et de conformité. La version 2.0 a introduit une architecture de gestion normalisée, ainsi que des fonctions de test, de débogage et de télémétrie pendant tout le cycle de vie du système en boîtier.

Ces fonctions ne constituent toutefois pas une solution complète de gestion ou de sécurité pour tous les produits : la conception doit les intégrer et définir les données recueillies, le contrôle des accès et le comportement en cas de défaillance. La distinction utile consiste à séparer ce que définit l’interface commune de ce qui reste à la charge du produit : politiques, micrologiciel, cohérence de la mémoire système, sécurité de bout en bout et comportement des applications ne sont pas automatiquement résolus par une liaison UCIe. La documentation publique de l’organisation précise le périmètre de la spécification ; pour mettre un produit en œuvre, les équipes doivent consulter la révision applicable et vérifier les droits de propriété intellectuelle ainsi que les conditions correspondantes.

Versions et débits : ce qu’apporte UCIe 3.0

UCIe 3.0 a été annoncé le 5 août 2025. Selon le consortium, la version prend en charge des débits de 48 et 64 GT/s, contre un maximum de 32 GT/s indiqué pour UCIe 2.0, et apporte des changements architecturaux. La page des spécifications met en avant un canal latéral pouvant atteindre 100 mm, une transmission continue au moyen de mappages pour Raw Mode, le téléchargement anticipé du micrologiciel via le Management Transport Protocol, une signalisation latérale prioritaire et des mécanismes d’économie d’énergie, dont le recalibrage en fonctionnement. Ces données décrivent les capacités de la révision, pas les performances d’un produit fini : la bande passante effective et la consommation dépendent également de l’implémentation et du système physique.

Les appellations UCIe-S et UCIe-A distinguent des classes destinées à différentes configurations de boîtier ; UCIe 3.0 annonce les débits de 48/64 GT/s pour les deux. UCIe 2.0 prévoit également UCIe-3D pour l’empilement tridimensionnel et le collage hybride. Il serait réducteur de transformer ces appellations en opposition simpliste entre « lent et bon marché » et « rapide et cher » : le choix dépend des règles de conception, des matériaux, de la géométrie, des capacités de fabrication et des objectifs du produit. Les informations publiques du consortium permettent de repérer les capacités de la spécification, mais pas de déterminer le débit qu’atteindra une combinaison précise de puces et de boîtier. Seule la validation de l’implémentation réelle peut le faire ; le nom de la version ne suffit pas.

Interopérabilité : une spécification n’est pas une certification globale

La compatibilité pratique comporte plusieurs niveaux. Deux implémentations doivent respecter la révision et les options communes retenues ; en outre, le boîtier, les PHY, les canaux et les outils de test doivent convenir à la configuration précise. Il faut aussi s’accorder sur les fonctions que chaque chiplet fournit au-dessus de la liaison. Ainsi, l’annonce par deux fournisseurs d’IP UCIe ne suffit pas à garantir que n’importe quelle paire de leurs produits puisse être directement connectée : la version, les protocoles activés, le boîtier, la configuration des voies ou les exigences de signal peuvent différer. La norme réduit le nombre d’accords à inventer, mais ne supprime ni les matrices de compatibilité ni les essais conjoints.

Il existe des exemples publics d’intégration entre organisations : en 2023, Intel a présenté la puce de test Pike Creek, combinant un chiplet doté d’IP UCIe fabriquée en Intel 3 et un autre doté d’IP Synopsys fabriquée en TSMC N3E, reliés par EMIB. Cette démonstration est utile pour une combinaison précise ; elle ne prouve pas que toutes les associations de fournisseurs, de procédés et de boîtiers soient interopérables. Le consortium publie des documents de conformité et décrit les attributs de test dans ses spécifications ; les éléments consultés ne permettent pas d’affirmer qu’il existe un registre public universel certifiant l’interopérabilité des produits complets dans tous les scénarios. Pour un achat, demandez les résultats de test et les conditions exactes : révision, PHY, protocoles, procédé, boîtier, température et limites de signal mesurées.

Écosystème et produits : une norme ouverte, des implémentations différentes

L’adoption peut prendre différentes formes. Les fonderies, fournisseurs d’IP, entreprises de conception et fabricants de boîtiers peuvent utiliser UCIe pour certaines parties de leur offre ; cela ne signifie pas qu’ils proposent tous un chiplet prêt à être combiné avec n’importe quel autre. La liste publique des membres et les annonces du consortium témoignent d’une participation industrielle, mais la disponibilité commerciale doit être confirmée pour le nœud, le procédé, le boîtier et le calendrier concernés. De même, des technologies d’intégration comme EMIB ou SoIC désignent des approches de boîtier et ne sont pas synonymes d’UCIe : une solution peut associer une technologie physique de boîtier à une interface de chiplet, combinaison qu’il faut vérifier pour chaque annonce.

La série Versal RF d’AMD est un exemple de produit annoncé avec UCIe : l’entreprise a indiqué que certains dispositifs intégreraient des interfaces UCIe 1.1 et qu’elle prévoyait des chiplets de production au quatrième trimestre 2027. Cette annonce porte sur une date future par rapport à cet article ; il ne faut pas la présenter comme un produit déjà disponible ni comme une preuve de compatibilité universelle. À l’inverse, NVIDIA présente NVLink-C2C comme une interconnexion chip-to-chip propriétaire pour des connexions cohérentes à haut débit dans ses systèmes. Ces options illustrent que l’industrie peut utiliser des interfaces propriétaires, ouvertes ou des combinaisons de technologies selon le produit. Elles ne permettent pas d’établir un classement équitable des performances sans comparer des spécifications équivalentes et des conditions de mesure identiques.

Comment évaluer une conception « UCIe-ready »

Pour évaluer une proposition, la première question n’est pas seulement « est-elle compatible avec UCIe ? », mais « avec quelle révision, quelle classe de PHY, quel protocole et quelle configuration exacte ? ». Demandez au fournisseur d’indiquer la révision mise en œuvre et les fonctions optionnelles, puis d’expliquer les limites de compatibilité avec les versions antérieures. Vérifiez ensuite que l’implémentation est disponible pour le procédé et le boîtier du projet, et que les modèles de canal et les flux de conception couvrent cette combinaison. Une annonce concernant une IP ou la prise en charge d’outils témoigne de l’écosystème ; elle ne vaut ni approbation automatique de la conception finale ni promesse de performances du produit.

La deuxième étape consiste à transformer l’interopérabilité en éléments vérifiables. Définissez une matrice des interfaces et des versions pour chaque chiplet ; demandez des tests de liaison dans les configurations et conditions d’utilisation prévues ; convenez de la personne chargée de diagnostiquer les défaillances et des journaux disponibles ; et incluez des essais d’intégrité du signal, de consommation, de température et de récupération après erreur. Enfin, traitez séparément l’intégration fonctionnelle : UCIe peut faciliter la liaison, mais ne garantit pas que les blocs partageront sémantique, cohérence ou logiciel sans travail supplémentaire. En pratique, la spécification réduit une partie du risque d’intégration ; elle ne fait pas disparaître la nécessité d’une ingénierie commune. Le meilleur signe de préparation n’est pas une étiquette promotionnelle, mais une documentation reliant une implémentation précise à des tests reproductibles et à des critères d’acceptation.