Une IA a généré un design de puce avec une file d'attente qui, dans la réalité, atteindrait la taille d'un terrain

L'analyse d'un design de puce généré par IA a mis au jour un point désagréable : le circuit paraissait plausible sur un test court, mais dès le premier élargissement de la charge, il est apparu qu'il cachait une décision d'architecture impossible à transposer dans du matériel réel. L'histoire met à mal l'idée répandue du « ne regarde pas le code, lance simplement les tests » et montre pourquoi cette approche est particulièrement dangereuse pour le hardware.

Où la logique a cédé

Le problème a commencé avec le contrôle du flux de données. Au lieu de limiter, d'acheminer ou de rejeter correctement les transactions selon les règles de l'interface, le modèle a généré une file interne gigantesque. En somme, il a décidé de ne pas s'attaquer à la dynamique des échanges et de stocker tout ce qui arrivait du test pour s'en servir plus tard.

Sur un petit jeu de données, un tel circuit peut sembler raisonnable : il y a une entrée, il y a une sortie, la vérification formelle passe et aucune erreur évidente n'apparaît en surface. Mais c'est précisément là que se cache le piège de l'approche générative. Le modèle optimise pour la réussite locale dans le scénario observé, pas pour la faisabilité physique de la conception.

Pour le logiciel, c'est déjà gênant ; pour la conception de circuits numériques, cela devient une menace directe : chaque tampon superflu coûte de la surface de silicium, de la consommation, du timing et de la complexité de routage. Si une IA ne comprend pas les contraintes de son environnement, elle proposera volontiers une solution qui ne fonctionne que sur le papier ou dans un testbench étroit.

Pourquoi le test n'a rien sauvé

Dans l'exemple d'origine, le test comportait environ 10 mille transactions. À ce volume, le design semblait fonctionner. Mais il a suffi de doubler le nombre d'événements pour que tout s'effondre : la file a débordé, une partie des données a été perdue et le résultat de la vérification ne correspondait plus au modèle transactionnel écrit à la main.

Autrement dit, le bug ne se cachait pas dans un recoin exotique du système. Il est apparu avec un changement d'échelle minimal, qui, pour un vrai projet, ne peut même pas être considéré comme un test de charge.

• L'IA a conservé dans le circuit toutes les transactions du test
• La FIFO est devenue le point de défaillance critique quand la charge a augmenté
• La perte de données a rompu la comparaison avec le modèle de référence
• Un design formellement « fonctionnel » n'a pas résisté à un simple passage à l'échelle

La principale conclusion est qu'un test ne garantit pas, à lui seul, la justesse de l'architecture. Si le testbench vérifie le comportement sur un volume de données limité, le modèle peut s'ajuster précisément à cette plage et masquer un défaut fondamental. En hardware, il ne suffit pas de voir un statut vert à l'issue de l'exécution. Il faut comprendre comment le circuit se comporte sur de longues séries, sous backpressure, lors de pics de rafales (burst) et dans des conditions où une mauvaise mise en tampon se transforme instantanément en erreur système.

Le prix d'un tel circuit

L'auteur traduit volontairement cette erreur en conséquences physiques. Si un tel bloc était placé dans un appareil fonctionnant à une fréquence de l'ordre du gigahertz, des centaines de milliards, voire des milliers de milliards de transactions pourraient le traverser en quelques minutes. Une file qui n'était dans le test qu'une abstraction malheureuse exigerait donc, en silicium, un volume de mémoire monstrueux ou une mer de bascules D pour une FIFO à base de bascules. Et ce n'est plus une question de beau code : il s'agit de savoir si l'on peut seulement fabriquer une telle puce, la faire tenir dans un budget de surface et l'alimenter sans pertes délirantes.

« C'est une puce de la taille d'un terrain de maison de campagne. »

L'hyperbole fonctionne justement parce qu'elle est presque d'ingénierie, et non littéraire. Quand l'erreur est extrapolée à la durée réelle de fonctionnement de l'appareil, l'absurdité devient évidente. Deux cents mille milliards de bascules pour un scénario, des millions de milliards pour le pire cas : c'est une façon rapide de montrer l'écart entre l'illusion du test et le bon sens de production. Une IA peut produire du RTL syntaxiquement propre, mais sans compréhension du débit, de la capacité des tampons et des régimes limites, ce code reste une ébauche dangereuse, pas une solution de conception.

Ce que cela signifie

Ce cas montre bien la limite de l'utilité de l'IA générative en ingénierie. Un modèle peut accélérer les tâches routinières, suggérer des modèles et aider pour les brouillons, mais sa sortie ne peut pas être acceptée sans lecture, simulation et vérification de la faisabilité physique. Pour les équipes qui travaillent sur le RTL et la vérification, la règle est simple : a passé le test ne signifie pas encore bon pour le silicium.