Douze heures pour passer d’une fiche de spécifications de 219 mots à un fichier GDSII prêt pour la fabrication. Verkor.io ne se contente pas d’annoncer un nouveau coeur RISC-V : la startup décrit, dans son rapport technique, un flux de conception numérique entièrement orchestré par un agent d’intelligence artificielle. Le sujet dépasse la performance brute du processeur VerCore. Ce qui interpelle les architectes hardware, c’est la méthodologie : un système capable d’enchaîner microarchitecture, code Verilog, vérification fonctionnelle et placement physique sans rendre la main à un ingénieur à chaque étape.

Pour mettre cette annonce en perspective, nous avons déjà détaillé le contexte général et la portée stratégique de l’opération dans notre analyse de VerCore et son impact sur le secteur des semi-conducteurs. L’objet de cet article est différent : zoomer sur le flux technique RTL→GDSII et sur la façon dont Design Conductor s’insère dans une chaîne d’outils EDA classique.

Design Conductor n’est pas un LLM, c’est un orchestrateur

Première distinction à poser. Design Conductor n’est pas un modèle de langage qui écrit du Verilog à la chaîne. Verkor.io le présente comme une couche d’orchestration qui pilote des modèles avancés sur des tâches spécialisées : proposer une microarchitecture, coder les modules HDL, générer les bancs d’essai, comparer le comportement avec un simulateur de référence, lancer les rapports de timing, ajuster le placement physique.

L’approche multi-agent change la donne pour deux raisons concrètes. D’abord, chaque sous-tâche bénéficie du modèle le plus adapté plutôt qu’un généraliste forcé à tout faire. Ensuite, l’orchestrateur peut boucler sur les rapports d’erreur (simulation, timing, lint) et réinjecter le contexte dans les prompts suivants jusqu’à obtenir un résultat passable. C’est cette logique itérative qui rapproche le système d’une méthodologie d’ingénierie réelle, plutôt que d’une génération en un seul coup.

Le flux complet : de la spec aux 1,48 GHz simulés

La spécification fournie au système tient en quelques contraintes : un coeur RISC-V RV32I avec extension ZMMUL, pipeline à cinq étages, interfaces de cache d’instructions et de données, pas d’instructions compressées, CPI cible inférieur ou égal à 1,5. Rien d’exceptionnel sur le papier. C’est le châssis classique d’un cours d’architecture des processeurs.

L’agent enchaine ensuite les étapes habituelles d’un design RTL :

• génération de propositions microarchitecturales et choix d’une variante (ici, pénalité de saut d’un cycle, forwarding précoce, multiplicateur Booth-Wallace à quatre étages),
• implémentation des modules en Verilog,
• création des testbenches et co-simulation avec Spike, le simulateur de référence RISC-V,
• analyse des traces VCD, conversion en CSV, identification des fautes (lectures de registres erronées, logique de flush du pipeline après un saut),
• synthèse logique et placement-routage sur le PDK académique ASAP7,
• génération du fichier GDSII final.

Résultat brut : 1,48 GHz simulés en 7 nm académique et 3 261 points au benchmark CoreMark. Verkor.io compare ce score à un Intel Celeron SU2300 de 2011, un processeur basse consommation discret même pour son époque. La comparaison est volontairement modeste : VerCore n’est pas un produit, c’est un démonstrateur du flux.

Pourquoi le GDSII compte plus que les MHz

L’étape qui mérite l’attention n’est pas le chiffre du benchmark. C’est le passage au GDSII. Ce format décrit le layout physique du circuit, géométries des transistors, couches métalliques, vias, et constitue le livrable transmis à la fonderie pour le tape-out. Dans une chaîne de production traditionnelle, atteindre ce point mobilise des architectes, des ingénieurs RTL, des spécialistes de la vérification fonctionnelle, des experts en analyse de timing, des équipes de backend physique et un empilement d’outils EDA propriétaires.

Verkor.io rappelle un ordre de grandeur de l’industrie : un développement de puce de pointe peut dépasser 400 millions de dollars et s’étaler sur 18 à 36 mois, avec des effectifs de plusieurs centaines d’ingénieurs. Boucler le même type de flux (sur un coeur très simple, certes) en une douzaine d’heures change la perspective sur l’exploration de variantes en amont d’un projet. C’est là que le potentiel paraît le plus tangible : tester rapidement plusieurs microarchitectures avant de figer celle qu’on confiera à une équipe humaine.

ASAP7 et OpenROAD : pourquoi l’open source rend l’expérience possible

Sans ASAP7, ce projet n’existe pas. Ce PDK pédagogique en 7 nm a été publié par l’Université d’État de l’Arizona en collaboration avec ARM Research. Il offre un modèle de processus suffisamment réaliste pour synthétiser, placer et router un circuit, sans imposer les NDA et les coûts de licence des PDK commerciaux des fondeurs. Combiné à une chaîne d’outils ouverts comme OpenROAD, il transforme un flux complet de backend physique en environnement scriptable, donc accessible à un agent autonome.

RISC-V joue exactement le même rôle côté architecture. ISA ouverte, modulaire, documentée, exempte de royalties : on peut tester un nouveau coeur sans négocier d’accord de licence avec Arm ou Intel. Modèles ouverts, outils ouverts, ISA ouverte : la pile technique au complet est lisible et automatisable. Il est peu probable qu’une expérience comparable aurait pu se mener sur un coeur Arm Cortex avec les outils de Cadence ou de Synopsys.

Les limites que Verkor.io reconnaît

Le rapport ne masque pas les angles morts du système. Plusieurs points méritent d’être soulignés.

Les modèles peuvent raisonner de manière imparfaite sur du Verilog. Le HDL décrit un matériel concurrent, alors que les LLM ont été entraînés majoritairement sur du code séquentiel. Cette confusion entre sémantique matérielle et sémantique logicielle revient régulièrement et explique une partie des erreurs corrigées à chaud par l’orchestrateur.

La vérification reste le point délicat. Passer une co-simulation contre Spike et obtenir des chiffres CoreMark cohérents ne couvre qu’une fraction de l’espace de comportements d’un processeur en production. Une vérification industrielle inclut la couverture fonctionnelle exhaustive, le formal proof, les corner cases timing, la validation post-silicium. C’est l’étape où les vraies surprises coûtent cher : un bug découvert après tape-out se compte en millions.

Enfin, VerCore n’a pas été fabriqué. Le flux s’arrête au GDSII vérifié en simulation. Une implémentation FPGA est annoncée pour la prochaine Design Automation Conference de Long Beach en juillet, mais le passage au silicium réel reste à faire, et c’est là que la photolithographie, les variations de processus et les marges de timing transforment souvent un design élégant en circuit récalcitrant.

L’enjeu réel : compresser l’exploration, pas remplacer l’ingénieur

Lu froidement, le travail de Verkor.io ne vise pas à supprimer les architectes silicium. Il propose un outil pour compresser le temps d’exploration en amont d’un projet : combien de variantes microarchitecturales peut-on tester avant de figer un design ? Combien de PDK peut-on cibler pour la même description RTL ? Combien d’itérations sur le sous-système cache avant de choisir le bon trade-off latence / surface ?

Cet usage place l’IA en complément des équipes existantes, pas en substitut. La même logique apparaît déjà ailleurs dans la chaîne des semi-conducteurs : on l’a vu sur la recomposition de la carte des puces d’inférence entre Samsung, TSMC et Nvidia, ou sur la façon dont la pression IA réhabilite des CPU Intel de binning inférieur. Chaque acteur cherche à récupérer du temps, des marges ou de la flexibilité, et l’automatisation du flux RTL→GDSII s’inscrit dans cette logique plutôt que dans une rupture complète.

Reste à voir ce que d’autres équipes feront du rapport quand Verkor.io publiera les fichiers de conception. La reproductibilité sera l’arbitre. Si le flux passe entre les mains d’une université ou d’un laboratoire indépendant et produit un GDSII cohérent sur une variante non triviale, alors la méthodologie aura prouvé sa robustesse. Sinon, VerCore restera un point dans la cartographie des démonstrateurs IA appliqués au hardware : intéressant, isolé, en attente de confirmation.

Questions fréquentes

Quelle différence entre Design Conductor et un LLM qui génère du Verilog ?

Design Conductor est une couche d’orchestration multi-agent. Il découpe le flux de conception (microarchitecture, RTL, testbench, vérification, placement) en tâches spécialisées, choisit le modèle adapté à chacune et boucle sur les rapports d’erreur. Un LLM seul, même entraîné au HDL, ne gère pas cet enchainement itératif et perd vite le contexte sur un projet à plusieurs centaines de fichiers.

Pourquoi le GDSII est-il considéré comme une étape critique ?

Le GDSII est le format de layout physique transmis à la fonderie pour la fabrication. Atteindre ce point implique d’avoir validé le RTL, passé la synthèse logique, fait le placement-routage et obtenu un timing acceptable. C’est la frontière entre la conception et la production. Y arriver de façon automatisée sur un PDK académique est techniquement significatif, même si la production en masse demande des étapes supplémentaires.

Pourquoi avoir choisi ASAP7 et RISC-V plutôt que des outils commerciaux ?

Les PDK commerciaux des fondeurs (TSMC, Samsung, Intel) sont sous NDA, propriétaires et fermés aux scripts externes. ASAP7 est un PDK académique en 7 nm publié par l’Université d’État de l’Arizona avec ARM Research, librement scriptable. Combiné à OpenROAD côté backend et à RISC-V côté ISA, l’ensemble forme une pile ouverte qu’un agent autonome peut piloter sans bloqueur juridique ni licence.

Combien de temps une équipe humaine met-elle pour un flux comparable ?

Sur un coeur RISC-V simple comparable à VerCore, une équipe réduite peut produire un GDSII en plusieurs semaines à quelques mois selon la maturité des outils. Verkor.io cite plutôt l’ordre de grandeur d’un projet de puce de pointe : 18 à 36 mois et plus de 400 millions de dollars, mais cette comparaison concerne des designs incomparablement plus complexes que VerCore.

Que vaut réellement le score CoreMark de 3 261 obtenu par VerCore ?

Le score est honorable pour un coeur RV32I scalaire à cinq étages, sans extensions vectorielles ni out-of-order. Il situe VerCore dans la gamme d’un microcontrolleur embarqué ou d’un coeur de gestion, pas d’un processeur applicatif moderne. Verkor.io le compare à un Intel Celeron SU2300 de 2011 pour souligner que l’enjeu est la méthodologie, pas la performance.