Intégrer l'intelligence artificielle agentive au développement de semi-conducteurs

Les équipes de développement matériel font face à un défi unique à l'ère de l'IA : alors que les ingénieurs logiciels adoptent rapidement les assistants de programmation par IA, les concepteurs matériels se sentent souvent laissés pour compte. Pourquoi? En raison des contraintes uniques de l'industrie des semi-conducteurs :

• Langages propriétaires – La plupart du code Verilog de production est confidentiel
• Chaînes d'outils commerciales – Les outils EDA (Electronic Design Automation) sont des systèmes fermés auxquels les grands modèles de langage ne peuvent pas accéder directement
• Complexité de l'infrastructure – Les connaissances sont dispersées entre plusieurs systèmes déconnectés

Ces contraintes rendent difficile le fonctionnement efficace de solutions d'IA génériques dans les environnements de développement matériel. Chez Annapurna Labs, qui fait partie d'Amazon, nous croyons que la réponse ne réside pas simplement dans la construction de meilleurs modèles de fondation, mais dans le développement d'architectures d'intelligence artificielle agentive capables de combler l'écart entre les grands modèles de langage à usage général et le monde spécialisé du développement matériel. Nous appliquons le paradigme agentif au développement de la prochaine génération de puces Trainium.

Dans ce blogue, nous décrivons ce qui devient possible lorsque des agents d'IA (comme Kiro) comprennent votre flux de travail de développement matériel et s'y intègrent.

Les grands modèles de langage modernes peuvent générer un code Verilog raisonnable pour les conceptions matérielles, mais pas d'une qualité aussi élevée que le code Python ou C, puisque la plupart du code Verilog de niveau industriel est confidentiel. Même si vous parveniez à générer du bon code, comment savoir s'il fonctionne réellement? En logiciel, vous pouvez exécuter du code Python instantanément et voir les résultats. En matériel, l'histoire est totalement différente.

Un grand modèle de langage peut écrire du Verilog, mais il ne peut pas le compiler avec vos outils EDA commerciaux en utilisant les paramètres personnalisés et les flux de construction de votre équipe, interpréter les erreurs de compilation qui nécessitent une connaissance approfondie et spécifique à l'outil, analyser les formes d'onde ou les rapports de couverture pour comprendre l'exactitude fonctionnelle, ou itérer en fonction de la rétroaction réelle de l'outil plutôt que d'hypothèses hallucinées. Même si nous parvenions à enseigner toutes ces compétences à un grand modèle de langage, il reste un autre problème : les outils EDA commerciaux ont des temps de démarrage à froid et d'exécution considérables. Lancer un simulateur, charger des bibliothèques et exécuter même des vérifications de base peut prendre de quelques minutes à quelques heures. Cela crée une boucle de rétroaction inacceptablement lente — l'IA génère du code, attend 10 minutes pour les résultats de compilation, puis tente une autre itération. Ce qui devrait être une conversation interactive devient un aller-retour lent et frustrant.

Mais la vérification exige plus que de compiler du code ou de vérifier une propriété, et combler cet écart est difficile parce que les connaissances de l'équipe matérielle sont dispersées entre des systèmes déconnectés. Lorsqu'un ingénieur de vérification demande « Pourquoi ce banc d'essai (lien) échoue-t-il? », trouver la réponse exige de naviguer dans :

• Des spécifications de conception et d'architecture réparties entre plusieurs documents
• Du code source distribué entre de nombreux dépôts Git
• Des journaux de régression enterrés dans des serveurs centralisés, de grande taille, qui peuvent ne pas tenir dans des fenêtres de contexte de 1 M
• Des révisions de conception et des décisions cachées dans des fils de billets

Un assistant IA générique ne peut pas résoudre ce problème. Il ne peut répondre qu'aux questions basées sur ce que vous collez explicitement dans la conversation. Ce dont les équipes matérielles ont réellement besoin, c'est d'un agent IA qui sait où chercher — un agent capable de rechercher intelligemment dans vos documents de spécifications, de parcourir votre historique Git, d'analyser des journaux de régression massifs et de synthétiser l'information à travers toute votre infrastructure. Les grands modèles de langage les plus avancés d'aujourd'hui sont assez intelligents, mais ils sont déconnectés des outils et du contexte sur lesquels les ingénieurs matériels s'appuient chaque jour.

Les architectures agentives résolvent ce problème en rendant les grands modèles de langage capables, pas seulement intelligents. Plutôt que d'enseigner davantage le matériel à l'IA, nous fournissons à des agents comme Kiro les outils pour interagir avec votre infrastructure réelle. Dans cette approche, le Model Context Protocol (MCP) agit comme un pont entre l'IA et nos systèmes de développement matériel. L'agent IA découvre ces outils et les enchaîne pour accomplir des tâches complexes. Cette orchestration est vraiment puissante et a transformé notre processus de développement.

Le diagramme ci-dessous montre comment un agent IA interagit avec des serveurs MCP spécifiques au domaine matériel pour accomplir une tâche.

Le développement matériel comporte deux phases majeures : le frontal (spécification, conception RTL et vérification) et le back-end (conception physique, fabrication, emballage et validation post-silicium). Ce billet se concentre sur les flux de travail frontaux, semblables au SDLC (Software Development Life Cycle). Voyons comment cela fonctionne en pratique avec trois exemples concrets :

• Boucles de rétroaction rapide avec des outils open source. Lorsqu'un ingénieur demande à Kiro de générer une nouvelle implémentation de module, l'agent ne se contente pas de générer du code et de s'arrêter. Il peut plutôt tirer parti d'outils open source comme Slang (un compilateur Verilog rapide) et EBMC (un vérificateur de modèles bornés) pour fournir une rétroaction quasi instantanée. Plutôt que d'attendre des minutes pour le démarrage à froid d'un simulateur commercial, l'agent obtient des résultats de compilation en quelques secondes, détecte immédiatement les erreurs de base et itère rapidement. Ce n'est que lorsque le code réussit ces vérifications rapides qu'il passe à la vérification complète par outil commercial. Cette validation multiniveau améliore considérablement à la fois la vitesse et la qualité du code.
• Compilation intelligente avec des outils internes. Nous avons des flux de construction spécifiques, des scripts personnalisés et des connaissances institutionnelles sur la façon dont les modules doivent être compilés. Plutôt que de nous attendre à ce qu'un grand modèle de langage comprenne cela (ce qu'il ne peut pas faire), nous fournissons un tutoriel détaillé en markdown ainsi que des outils internes comme serveurs MCP. Lorsque l'agent Kiro doit compiler un module, il lit le tutoriel et appelle votre infrastructure de construction réelle — les mêmes scripts que vos ingénieurs utilisent. De même, lors de l'analyse de journaux de régression pouvant contenir des millions de lignes, le serveur MCP inclut des fonctions d'analyse intégrées qui extraient les informations d'erreur, les traces de pile et les motifs d'échec. L'agent reçoit des renseignements structurés, pas des fichiers bruts de taille gigaoctet qui feraient déborder n'importe quelle fenêtre de contexte.
• Accès unifié aux ressources dispersées avec un agent. Nous avons déployé notre agent IA Silicon unifié au-dessus d'un serveur MCP qui fournit un accès transparent à la base de connaissances distribuée de l'équipe, incluant les documents de spécifications, les dépôts Git, les bases de données de régression et les systèmes de billetterie. Lorsque vous demandez à Kiro, avec le soutien de l'agent Silicon AI, « Pourquoi le module DMA a-t-il échoué au test de fumée? », l'agent effectuera possiblement ce qui suit :
  • Interroger la base de données de régression pour la dernière exécution du test de fumée DMA, extraire la signature de l'échec
  • Rechercher dans Git les changements récents apportés au module DMA et au code de banc d'essai connexe
  • Récupérer la spécification DMA pour comprendre le comportement attendu et identifier le problème probable
  • Déposer un billet avec les détails de l'échec, l'hypothèse de cause première et les correctifs suggérés

L'ensemble du processus prend moins d'une minute, en tirant du contexte de cinq systèmes différents, ce qui prendrait environ 20 minutes à un ingénieur pour naviguer manuellement.

La magie ne réside pas dans le grand modèle de langage, mais dans l'orchestration. L'agent IA choisit intelligemment quels outils utiliser, dans quel ordre, en fonction de la tâche à accomplir. Il sait quand utiliser des outils open source rapides pour une itération rapide, quand invoquer notre infrastructure de construction interne pour une compilation précise et quand interroger des ressources distribuées pour le contexte de débogage.

Lorsque ces capacités agentives sont intégrées dans un produit comme Kiro, les équipes matérielles constatent des résultats transformateurs.

Avant l'intégration d'outils de Kiro, générer un banc d'essai local pour un module de taille moyenne, syntaxiquement correct (~10 blocs différents), prenait en moyenne 30 minutes à un agent IA générique. Le processus impliquait des allers-retours répétés : l'ingénieur décrit les exigences, l'IA génère du code, la compilation échoue en raison de fichiers manquants ou de chemins incorrects, l'IA réessaie, et le cycle se répète.

Après l'intégration d'outils internes de génération de liste de fichiers, la même tâche prend en moyenne 5 minutes — une accélération de 6 fois validée sur plusieurs blocs et essais répétés. Les gains de temps sont encore plus importants pour les modules plus complexes, et les modèles de langage moins performants en bénéficient de façon encore plus marquée. La différence? L'agent IA invoque maintenant intelligemment les bons outils de génération de liste de fichiers, en tirant parti de votre infrastructure de construction existante plutôt que de deviner les dépendances de fichiers.

Au-delà de l'accélération, nous obtenons aussi moins d'itérations, mais de meilleure qualité. L'agent IA a accès à des outils puissants et éprouvés qui génèrent du code correct dès le premier essai, plutôt que d'itérer indéfiniment sur des approches fondamentalement erronées. Un ingénieur de notre équipe l'a parfaitement résumé : « Avant, je générais un banc d'essai avec un assistant IA et je passais plus de 20 minutes à donner de la rétroaction pour corriger des erreurs de base — inclusions manquantes, chemins de module erronés, paramètres incorrects. Maintenant, avec l'intégration des outils internes de Kiro, j'obtiens immédiatement quelque chose qui se compile et s'exécute. Je peux concentrer mon temps sur le véritable défi de vérification, pas sur la lutte contre le système de construction. »

Au cours des 30 derniers jours, plus de 80 % des ingénieurs de l'équipe matérielle ont utilisé l'assistant IA spécifique à l'équipe, et plus de 30 % des ingénieurs l'utilisent quotidiennement — un résultat impressionnant pour une équipe matérielle où les ingénieurs sont notoirement sceptiques envers les nouveaux outils.

L'étendue des cas d'utilisation en dit long.

• « Déboguer cet échec de régression au lien xxx » – L'agent analyse les journaux, recoupe les changements de code récents dans Git, et détermine qu'un changement précis du commit précédent a causé l'échec de régression. Il vérifie ensuite le système de billetterie de l'équipe pour des rapports existants du même problème — et si aucun n'existe, il dépose automatiquement un nouveau billet avec l'analyse de la cause première.
• « Comment mettre en place le flux de vérification formelle pour ce nouveau module? » – Plutôt que de demander aux ingénieurs seniors, l'agent recherche dans notre système de partage de documents le guide de configuration exact et génère le script FV initial en fonction des instructions.
• « Y a-t-il suffisamment de licences de simulation pour mon exécution de régression? » – L'agent interroge le serveur de licences en temps réel, affiche la disponibilité par serveur et l'utilisation actuelle, identifie quels utilisateurs détiennent le plus de licences, et signale tout serveur à capacité maximale — donnant aux ingénieurs une visibilité instantanée qui exigeait auparavant de consulter plusieurs tableaux de bord.
• « Qu'est-ce qui bloque le jalon de tape-out? » – L'agent effectue une analyse à travers plusieurs tableaux de bord, corrèle les billets ouverts, vérifie les taux de réussite de régression, et synthétise un résumé de l'état du projet qui prendrait des heures à un humain à compiler.

Ce sont les questions que les ingénieurs posent des dizaines de fois par jour, ce qui exigeait auparavant des changements de contexte, des recherches manuelles et des connaissances institutionnelles. Maintenant, elles sont répondues en quelques secondes, avec des citations et des prochaines étapes concrètes.

L'industrie du matériel n'a pas seulement besoin de grands modèles de langage qui génèrent du Verilog à partir de zéro. Ce qui est bien plus important, c'est de soutenir l'ensemble du cycle de vie du développement matériel. Plutôt que de se concentrer uniquement sur la génération de code, la véritable occasion est d'utiliser l'IA pour assister l'ensemble du processus — des spécifications et de l'exploration de conception à la vérification, à la validation et à la productivité des développeurs. Ce virage vers des flux de travail de développement matériel assistés par l'IA est à la fois plus pratique aujourd'hui et, en fin de compte, plus percutant pour l'industrie.

Les assistants de programmation par IA génériques se sont améliorés, mais ils continueront d'être limités par leur déconnexion des flux de travail de développement matériel. L'avenir appartient aux systèmes agentifs spécifiques à un domaine qui comprennent non seulement la syntaxe du Verilog, mais tout l'écosystème du développement matériel : vos flux de construction, vos méthodologies de vérification, vos pratiques de débogage et les connaissances accumulées de votre équipe. Des agents comme Kiro — augmentés de capacités comme le Steering, les Powers et des serveurs MCP personnalisés adaptés aux flux de travail matériels — démontrent que cet avenir est déjà en train de se dessiner aujourd'hui.

• Les assistants IA génériques sont actuellement insuffisants pour les flux de travail matériels en raison de l'écart de connaissances, de l'opacité des outils et de la fragmentation de l'infrastructure
• L'IA agentive avec MCP change la donne en donnant aux grands modèles de langage un accès structuré aux ressources et outils réels de votre équipe
• L'impact réel provient de l'intégration, pas de l'isolation, là où les agents IA peuvent compiler votre code Verilog, interroger vos spécifications et analyser vos journaux pour offrir de véritables gains de productivité
• La technologie est prête maintenant : des agents comme Kiro démontrent que l'IA agentive pour le matériel n'est pas une vision d'avenir, mais quelque chose que vous pouvez déployer dès aujourd'hui

La question à laquelle font face les équipes matérielles n'est pas « L'IA transformera-t-elle nos flux de travail? » C'est plutôt « Sommes-nous en train de construire l'infrastructure qui permettra à l'IA de transformer nos flux de travail? » Les outils que vous créez aujourd'hui détermineront la valeur que votre équipe tirera de l'IA demain.

Nous vous recommandons de commencer petit : choisissez un point de douleur (génération de banc d'essai, triage de régression, recherche de spécifications), construisez un outil qui y répond, et exposez cet outil à un agent IA. Vous découvrirez rapidement que le goulot d'étranglement n'était pas l'intelligence ou les connaissances de l'IA, mais l'accès à votre univers.