Le vérificateur formel disait « prouvé ». La puce était quand même défaillante.

La première fois que l'un de nos propres outils m'a menti, il l'a fait poliment. Le moteur formel a renvoyé une coche verte. Chaque propriété que nous lui avions demandé de prouver revenait prouvée. La bibliothèque d'assertions semblait complète. Sur le papier, la conception était vérifiée.

Il nous a fallu deux jours pour comprendre que le certificat ne valait rien — et que tout ce que j'avais supposé au sujet de la vérification IA des semi-conducteurs nous protégeait de la mauvaise défaillance.

Les propriétés avaient été générées par un grand modèle de langage que nous avions enveloppé autour du moteur formel — exactement le genre de démonstration agentique et léchée de conception de puces que tout le monde construisait. Et le moteur les avait prouvées en quelques millisecondes, ce qui aurait dû être le signal d'alerte. Elles étaient prouvées parce que les conditions qui les auraient mises à l'épreuve ne se déclenchaient jamais. Une propriété qui dit « toute requête finit par obtenir une autorisation » est trivialement vraie si la requête ne peut jamais se produire. Le solveur n'avait pas tort. Il a répondu à la question que nous avions posée par accident, et cette question était vide. C'est le moment où j'ai compris ce que ces pipelines de vérification IA doivent réellement défendre — et pourquoi presque personne parmi ceux qui en vendaient un ne se défendait contre la bonne chose.

Je veux vous raconter ce que nous avons découvert, car les classes de bugs qui tuent les puces modernes ne sont pas celles que l'industrie prétend pouvoir attraper. Nous construisons des pipelines de vérification personnalisés pour les équipes de conception de puces fabless — des modèles à poids ouverts affinés, enveloppés autour du moteur formel qu'une équipe possède déjà, s'exécutant entièrement sur son propre matériel — et toute l'approche est née d'un premier échec sur ce point. Vous pouvez en voir la forme sur veriprajna.com/solutions/semiconductor-ai-verification. Mais l'approche ne prend son sens qu'une fois que vous avez vu une conception « réussie » échouer.

Un chiffre qui devrait effrayer tout directeur financier de société fabless

Une seule statistique cadre tout le problème. L'étude Functional Verification 2024 du Wilson Research Group / Siemens EDA — le benchmark le plus ancien de l'industrie — a situé le succès au premier silicium à 14 %. Le plus bas niveau atteint en vingt ans de suivi. En 2020, ce chiffre tournait autour de 32 %. Il a plus que diminué de moitié en quatre ans.

Ce n'est pas l'histoire d'ingénieurs devenus paresseux. C'est l'histoire d'une complexité qui dépasse les outils, et d'une spécification qui mute plus vite que le banc de test qui la poursuit. La même étude a constaté qu'environ 70 % des respins sont causés par des erreurs liées à des changements de spécification — et non par de purs bugs logiques.

Le succès au premier silicium n'a pas chuté parce que les équipes de conception se sont détériorées. Il a chuté parce que la spécification évolue désormais plus vite que la vérification ne peut la clore.

Je suis resté longtemps avec ce chiffre de 70 %, car il met discrètement en accusation bon nombre d'argumentaires « l'IA pour la conception de puces ». Si la plupart des respins proviennent de la dérive de spécification, alors un outil qui n'attrape que les bugs logiques ne traite qu'une part du problème tout en la faisant passer pour le problème tout entier.

Et le coût de l'erreur est brutal d'une manière que les gens du logiciel sous-estiment. Un jeu de masques en 5 nm coûte 10 à 20 M$. En 3 nm, on approche des 40 M$, avec plus de soixante-dix couches de masques dont plus de vingt couches EUV. Un tape-out complet en 2 nm coûte désormais de l'ordre de 725 M$ tout compris. Quand quelque chose passe entre les mailles du filet, un respin représente un glissement de calendrier de 3 à 6 mois qui s'ajoute à la facture des masques. Sur une fenêtre produit de dix-huit mois, un glissement de six mois peut effacer la moitié du chiffre d'affaires d'une puce sur toute sa durée de vie. Le directeur financier ne voit pas la vérification comme un centre de coûts. Il la voit comme une assurance contre une unique erreur à huit chiffres.

Comment un LLM hallucine-t-il réellement dans le matériel ?

Votre équipe utilise déjà des LLM sur du Verilog. Je ne vais pas prétendre le contraire, et personne parmi ceux qui vous démarchent ne le devrait non plus. Le domaine de recherche est bien réel maintenant — les articles sur des LLM écrivant du Verilog sont passés d'un seul en 2020 à soixante-quatre en 2025. Sur les problèmes les plus difficiles du benchmark VerilogEval, les modèles de classe GPT-4 atteignent environ 43 % de correction fonctionnelle. Utile. Pas digne de confiance.

La question intéressante n'est pas de savoir si les modèles aident. C'est comment ils échouent, car les modes de défaillance ne ressemblent pas à ceux que les ingénieurs logiciels sont formés à craindre. Après suffisamment de nuits blanches à me demander pourquoi du RTL « à l'air correct » avait mal tourné, j'ai commencé à trier les défaillances en cinq classes.

La première est la plus inoffensive. L'hallucination syntaxique — du code qui, tout simplement, ne compile pas. Verilator ou le front-end de synthèse l'attrape en quelques secondes. Tout le monde sait déjà comment gérer cela, et c'est la classe que l'on montre du doigt quand on veut affirmer que le problème est résolu.

La deuxième est celle où ça commence à faire mal. L'hallucination sémantique, et le cas d'école est l'affectation bloquante contre non bloquante. Un modèle entraîné sur du Python et du C lit le Verilog comme si les instructions s'exécutaient de haut en bas. Il écrit donc une affectation bloquante — un simple = — à l'intérieur d'un bloc always_ff cadencé où le langage exige l'affectation non bloquante <=. Le concepteur voulait un pipeline à deux cycles. Avec des affectations bloquantes, le deuxième étage lit la nouvelle valeur du premier, et non l'ancienne, et le silicium livre un contournement à un cycle. Certains simulateurs ordonnancent les événements dans un ordre qui masque entièrement la course. Ça simule très bien. Ça se synthétise en la mauvaise machine.

La troisième classe est celle qui m'a appris à garder la spécification AMBA ouverte sur un second écran. L'hallucination protocolaire. Le code compile, passe quatre-vingt-dix pour cent des tests dirigés, puis affirme un signal write-data-valid avant que l'esclave ne soit prêt à accepter l'adresse — une violation du handshake AXI. Ou bien il maintient un signal valid à l'état haut tout en changeant les données en dessous. Ou bien il déclenche une sous-clause enfouie à la page 84 de la spécification du bus qu'aucun humain n'a mémorisée. La puce fonctionne parfaitement sur votre banc de test interne et se bloque à l'instant où elle est câblée à un contrôleur mémoire tiers. On ne peut pas venir à bout de cela par la force brute avec plus de cycles de simulation. On l'attrape avec des bibliothèques d'assertions pré-vérifiées écrites pour chaque protocole.

La quatrième classe est celle qui nous a dupés, et c'est la dangereuse.

Pourquoi « prouvé » est-il le mot le plus dangereux dans un rapport de vérification ?

Vacuité. Le modèle génère une assertion SystemVerilog. Le moteur formel la prouve. Vous livrez. Et la propriété était trivialement vraie parce que son antécédent — la partie « si » — n'est jamais devenu vrai en premier lieu.

Imaginez une propriété d'arbitre : si une requête est levée, une autorisation doit suivre dans un certain nombre de cycles. Supposons maintenant que le même modèle, essayant d'être utile, ait aussi écrit une hypothèse qui force le signal de requête à l'état bas. Le moteur formel prouve consciencieusement la propriété d'autorisation en quelques millisecondes, car il n'y a aucune requête pour jamais la violer. L'arbitre réel en dessous pourrait être complètement cassé. Le certificat dit « prouvé ». Il ne vaut rien.

Une preuve formelle qui s'exécute en quelques millisecondes n'est pas rapide. Elle est suspecte. Le moteur n'a peut-être rien prouvé du tout.

Ce n'est pas un risque marginal. Siemens publie des avertissements sur les preuves vacues depuis 2017, et le domaine livre encore des flux sans vérification automatique de vacuité. Quand je dis aux gens qu'un flux de vérification formelle sans détection de vacuité est pire qu'une absence de vérification formelle, ils croient que je dramatise. Ce n'est pas le cas. Une absence de vérification vous laisse convenablement effrayé. Un « prouvé » vacue vous laisse confiant et dans l'erreur, avec un bloc validé en route vers le tape-out. C'est la défaillance qui a failli être livrée dans notre propre prototype initial, et elle a changé de façon permanente ce que nous construisons.

La cinquième classe est celle que la simulation, structurellement, ne peut pas voir. Les angles morts du franchissement de domaines d'horloge. Un LLM lit les noms de signaux ; il ne perçoit pas les domaines d'horloge. Il connecte donc un signal d'un domaine CPU à 2 GHz directement dans une bascule d'un domaine périphérique à 400 MHz, en sautant le synchroniseur à double bascule qui prévient la métastabilité. La simulation RTL ne modélise pas la métastabilité — la régression passe donc, à chaque fois, et le silicium se bloque sur le terrain. Voilà pourquoi les bugs de CDC dévorent des jeux de masques. C'est aussi pourquoi Accellera a ouvert une norme d'interopérabilité CDC/RDC en 2024 : la fragmentation entre les outils CDC commerciaux était devenue suffisamment grave pour casser la validation finale.

Les classes deux à cinq partagent une propriété terrifiante : elles passent la simulation. Elles ne se manifestent que dans le silicium. C'est le sous-ensemble de bugs qui fait encore exploser les tape-outs, et c'est précisément le sous-ensemble qu'un argumentaire « attrape les bugs logiques » laisse de côté.

Le mur des fournisseurs devant lequel une équipe de conception de puces se tient réellement

Quand je suis parti chercher une aide véritablement indépendante pour un tape-out, j'ai trouvé moins d'options que je n'en avais quelques années plus tôt — et ce n'est pas de la nostalgie, c'est la structure du marché. Les trois éditeurs EDA parmi lesquels un responsable de vérification de conception peut réellement choisir — Synopsys, Cadence, Siemens — sont passés de moins de 75 % du marché il y a dix ans à plus de 85 % aujourd'hui. Ajoutez l'acquisition d'Ansys pour 35 Md$ par Synopsys, et les quatre premiers contrôlent environ 90 %. Le terrain sur lequel une startup fabless fait ses achats s'est rétréci, et non élargi, exactement au moment où le problème est devenu plus difficile.

Et les acteurs en place ne restent pas les bras croisés sur l'IA. Synopsys a livré AgentEngineer en mars 2026, un flux de vérification agentique revendiquant une productivité multipliée par deux à cinq, et il repose sur VC Formal — la pile agentique de fournisseur la plus crédible que j'aie évaluée. Cadence a annoncé son ChipStack AI Super Agent en février 2026 et fait tourner Cerebrus AI Studio pour une implémentation pilotée par apprentissage par renforcement, JasperGold restant le moteur formel de référence auquel tous les autres sont comparés. Je le dis sans détour : JasperGold et VC Formal sont véritablement excellents. Quiconque ouvre son argumentaire en les dénigrant vous a annoncé qu'il n'a jamais mené un vrai tape-out à son terme.

Le hic, c'est le prix et la posture. La base tarifaire historique de JasperGold tournait autour de 225 K$ plus 45 K$ par siège — acceptable pour une grande société fabless, hors de portée des startups RISC-V et d'accélérateurs IA en phase précoce qui font le travail le plus intéressant. Et les toutes nouvelles fonctionnalités d'IA des acteurs en place sont cloud-first, ce qui entre frontalement en collision avec la seule exigence sur laquelle ces clients ne céderont pas. Plus de détails là-dessus dans un instant.

Puis il y a la vague de startups, et elle est bruyante. Aux derniers DAC et DVCon, un responsable de vérification avec qui je travaille avait été démarché par huit sociétés différentes d'« IA agentique pour la conception de puces » en un seul trimestre. ChipAgents a levé 74 M$ début 2026 et revendique une productivité de conception et de vérification décuplée. Normal Computing a levé 50 M$ sous la conduite du Catalyst Fund de Samsung, développant l'auto-formalisation — des LLM qui traduisent directement l'intention de l'ingénieur en propriétés formelles et les prouvent — et affirme que la moitié des dix plus grandes entreprises mondiales de conception de semi-conducteurs l'utilisent. Il y en a d'autres : MooresLabAI qui génère des bancs de test complets, Bronco pour l'analyse de régression, Silimate pour la prédiction puissance-performance-surface.

Certaines d'entre elles sont réelles. Aucune ne résout le véritable problème du client, à savoir qu'il a désormais acheté trois de ces outils ponctuels et n'a aucune idée de la façon de les faire fonctionner ensemble à l'intérieur du flux de validation finale auquel il fait déjà confiance.

L'histoire du placement par apprentissage par renforcement que personne ne veut dire à voix haute

Il existe une tentation parallèle dans la conception de puces au-delà de la vérification : utiliser l'apprentissage par renforcement pour réaliser le floorplanning physique — décider où les gros blocs se posent sur la puce. C'est séduisant, et le résultat le plus cité est contesté d'une manière que la plupart des argumentaires escamotent commodément.

L'article de Google paru dans Nature en 2020 affirmait que l'apprentissage par renforcement bat le recuit simulé pour le placement des macros, et il a été utilisé dans du vrai silicium — des générations de TPU ont été livrées avec. Mais en 2023, Nature a ajouté une note éditoriale après que des préoccupations méthodologiques ont été soulevées. Igor Markov, aujourd'hui chez Synopsys, a publié une critique ligne par ligne dont la comparaison phare est difficile à oublier : l'approche par apprentissage par renforcement a pris 32,31 heures, une base de référence par recuit simulé optimisée en a pris 12,5, et un outil commercial de Cadence a terminé le même travail en 0,05 heure. DeepMind a répliqué avec un article intitulé « That Chip Has Sailed. » Des années plus tard, aucune réplication externe indépendante n'a confirmé les affirmations initiales, et la critique comme la réfutation sont toujours d'actualité.

J'évoque ceci à cause de ce qui se passe quand un consultant propose le placement par apprentissage par renforcement à une vraie équipe de vérification formelle et fait comme si la controverse n'existait pas. Ils le flairent en moins de dix minutes, et vous avez perdu l'auditoire. La position honnête est qu'il existe de véritables niches — le floorplanning thermique des chiplets et des 3D-IC, le layout analogique, l'optimisation d'IP RISC-V sur outillage ouvert — où une approche hybride justifie son coût. Un assaut frontal contre les moteurs de placement des acteurs en place, non. Connaître la différence, et la dire à voix haute, c'est tout le métier.

Ce qui a changé après que notre outil nous a dupés

Voilà donc où le désastre de la preuve vacue nous a menés. Nous avons cessé d'essayer de construire une meilleure IA qui écrit du Verilog, parce que c'est une course encombrée avec huit concurrents financés, et nous avons commencé à construire ce qu'aucun d'eux ne vend : la couche d'intégration neutre vis-à-vis des fournisseurs qui rend fiables les outils existants d'une équipe.

Concrètement, cela implique quelques décisions, chacune imposée par une défaillance que nous avions vue. Nous affinons un modèle à poids ouverts — Qwen Coder, Llama, quel que soit celui qui convient — sur le propre corpus RTL du client, ses spécifications, son historique de bugs passés, car un modèle qui n'a pas vu votre style maison hallucine à son encontre. Nous l'enveloppons autour de quelque moteur formel que l'équipe possède déjà : JasperGold, VC Formal, Questa Formal, ou le SymbiYosys open source. Nous ne leur demandons jamais d'arracher l'outil de référence auquel ils font déjà confiance. Et chaque propriété que le modèle propose passe par des contrôles de vacuité et de couverture avant que quiconque ne soit autorisé à lire le mot « prouvé » — car nous avons appris à la dure qu'une preuve non gardée est du théâtre.

Les bibliothèques d'assertions pré-vérifiées comptent tout autant que le modèle. Pour un cœur RISC-V, le harnais formel est livré avec les contrôles de conformité AXI4, AHB et TileLink, les assertions de risques de pipeline, le scoreboarding load-store, les propriétés de correction de l'unité de débogage — les choses qui attrapent l'hallucination protocolaire et sémantique avant que le silicium ne le fasse. Ce n'est pas spéculatif. Le cabinet de vérification formelle Axiomise a trouvé plus de 65 bugs dans Ibex, le cœur RISC-V ouvert au sein d'OpenTitan de Google, y compris des bugs d'instruction de branchement dans l'unité de débogage que seule la vérification formelle pouvait attraper. La vérification formelle fonctionne sur RISC-V. La ressource rare n'est pas la méthode ; c'est une équipe qui sait la manier.

La véritable ouverture ici n'a jamais été un modèle Verilog plus intelligent. C'était un harnais honnête enveloppé autour des outils coûteux auxquels une équipe fait déjà confiance.

Pourquoi ne pas simplement l'exécuter dans le cloud ?

On me pose sans cesse cette question, et la réponse est la même raison pour laquelle chaque startup EDA-IA cloud-first est morte-née auprès des clients qui m'intéressent : le RTL, ce sont les joyaux de la couronne, et il ne quitte pas les locaux.

Le code de niveau transfert de registres d'une société fabless est l'entreprise. Les clients de la défense et de l'aérospatiale en ont besoin isolé (air-gapped), parfois dans une installation sécurisée. Les équipes fabless commerciales veulent du sur site, du cloud privé virtuel au strict minimum. Nous exécutons donc tout sur le propre matériel du client — inférence vLLM ou similaire sur leur cluster H100 ou H200 existant, récupération locale sur leur propre corpus, aucun RTL ne franchissant jamais la frontière du réseau. Les toutes nouvelles fonctionnalités agentiques des acteurs en place sont cloud-first ; c'est un atout pour eux et un non-démarreur pour une équipe de conception de puces sensible à sa propriété intellectuelle. La plus grande ouverture que je perçois n'est pas du tout un problème d'algorithmes. C'est un problème de déploiement et d'intégration que les personnes disposant des meilleurs algorithmes ont décidé de ne pas résoudre.

L'autre question vient des équipes automobiles, et c'est celle qui décide de tout pour elles. Livrez une puce dans une voiture en ASIL C ou D — les niveaux d'intégrité de sécurité où l'ISO 26262 cesse de simplement suggérer la vérification formelle et commence à l'imposer — et l'outil lui-même doit porter un dossier de qualification TCL2 ou TCL3. Les moteurs de base des acteurs en place disposent de cette certification tierce ; un tout nouvel outil d'IA, non. J'ai vu un outil véritablement meilleur mis sur la touche dans un programme automobile pour exactement cette raison : pas de dossier de qualification, pas de place dans le flux de validation finale, fin de la conversation. Nous n'essayons donc pas d'être l'outil qualifié. Nous aidons les équipes à exécuter l'assistance par IA aux côtés des moteurs qualifiés des acteurs en place sans casser la chaîne de qualification — car dans l'automobile, un outil techniquement supérieur incapable de survivre à un audit ne vaut rien.

Le certificat n'est pas la puce

Je reviens sans cesse à ces deux jours passés à faire confiance à une coche verte qui ne signifiait rien. La leçon n'était pas « les LLM sont mauvais en Verilog ». Ils s'améliorent à chaque trimestre. La leçon était que, dans le matériel, l'écart entre a l'air vérifié et est vérifié se mesure en jeux de masques à huit chiffres et en glissements de six mois — et les outils qui se ruent sur cet espace se précipitent surtout pour rendre la partie « a l'air vérifié » plus rapide.

Sur un jeu de masques à 10 M$, un « prouvé » que vous ne pouvez pas remonter jusqu'à une preuve non vacue, exécutée sur du matériel que vous contrôlez, contre des assertions écrites par quelqu'un qui a lu la page 84 de la spécification — ce n'est pas de la vérification. C'est un espoir aux belles valeurs de production. Si vous voulez voir comment nous faisons la différence, tout est exposé sur veriprajna.com/solutions/semiconductor-ai-verification.

La puce se moque de ce que dit le rapport. Elle ne fait que ce que le silicium a réellement été construit pour faire. La vérification est la discipline consistant à rendre ces deux choses identiques — et à l'instant où une IA vous dit qu'elles sont identiques en quelques millisecondes, c'est exactement à ce moment-là que vous devriez tendre la main vers la spécification.