L’intelligence artificielle dans la conception des puces évolue vers un rôle qui dépasse l’amélioration d’outils individuels de simulation ou de planification, pour devenir une couche de coordination entre les étapes de conception, les équipes, les contraintes et les connaissances spécialisées. Cette évolution ne signifie toutefois pas qu’il faille confier les spécifications de la puce ou la décision finale de validation à des modèles probabilistes ; la valeur pratique dépendra de la capacité des systèmes à transmettre l’intention de conception, les hypothèses et les preuves entre les outils sans en perdre le sens.
Ce besoin apparaît à un moment où les conceptions intègrent des dizaines de milliards de transistors et combinent des chiplets et plusieurs matrices, tandis que le coût de conception aux nœuds avancés peut atteindre des centaines de millions de dollars. Dans cet environnement, un seul cycle de reconception peut menacer l’ensemble du programme, tandis que la pénurie d’ingénieurs expérimentés rend de plus en plus prioritaire la réduction du délai nécessaire pour obtenir des résultats.
Le problème se situe entre les outils
La conception d’une puce passe par des étapes spécialisées comprenant l’exploration architecturale, le RTL, la vérification, la synthèse, le placement-routage, l’analyse du timing et de la puissance, la vérification physique, les tests DFT, puis la comparaison avec les résultats post-fabrication. Ces outils ont souvent été développés par des entités différentes, à l’aide de modèles de données, d’hypothèses et de définitions divergents de ce que signifie l’achèvement d’une tâche.
Il ne suffit donc pas de transférer des fichiers entre les outils. Il faut préserver les contraintes, l’intention de conception et le contexte d’ingénierie, faute de quoi les ingénieurs doivent réinterpréter les exigences et élaborer manuellement les tests, les propriétés et les exceptions. Les points faibles récurrents comprennent l’absence de modèle sémantique commun, la perte d’informations lorsque le travail passe de la conception à la vérification, la multiplicité des formats de données et des bases de données fermées, ainsi que le temps consacré par les ingénieurs à faire correspondre les contraintes, les compromis et les exceptions de timing entre des étapes adjacentes.
Un outil peut atteindre un objectif local, comme améliorer les performances, tout en créant ensuite un problème de congestion, de timing ou de cycles ECO. C’est là qu’apparaît l’opportunité de l’intelligence artificielle : améliorer le flux dans son ensemble plutôt que chaque outil indépendamment des résultats en aval.
De l’assistant au coordinateur du flux de travail
Les responsables de Siemens EDA, Synopsys, Arteris, Keysight EDA, ChipAgents et d’autres estiment que l’automatisation agentique peut coordonner des tâches qui prenaient autrefois des semaines, comme la mise en relation de l’insertion DFT, de l’analyse du timing et de la correction des problèmes. Mais cela exige un accès aux connaissances méthodologiques accumulées par les équipes et une représentation unifiée des intentions de conception, et pas seulement la capacité à appeler les outils.
Les usages envisagés vont de boucles d’optimisation entre les frontières des outils à des couches d’assistants et d’agents reliant les étapes de l’architecture, du RTL, de la vérification et de la conception physique, puis à une couche d’interopérabilité reposant sur des modèles de données indépendants des fournisseurs. Des initiatives comme Schema Ontology de Si2 et le CDC/RDC Integration Standard d’Accellera sont citées comme des exemples de l’infrastructure nécessaire pour permettre aux agents d’interpréter les résultats des outils sans reconstruire le contexte à chaque transition.
Qu’est-ce qui prouve que le résultat est correct ?
La vitesse seule ne suffit pas dans la conception des puces. L’intelligence artificielle peut proposer des propriétés, des assertions ou des corrections, mais la proposition reste une hypothèse jusqu’à sa vérification par un moteur déterministe. Comme l’explique l’analyse, exécuter un modèle de langage ou obtenir une réponse à partir d’un prompt ne constitue pas une preuve ; la preuve est un résultat complet obtenu par rapport à une propriété correcte et reproductible.
C’est pourquoi les modèles opérationnels tendent à laisser les spécifications et la décision de sign-off à l’ingénieur, tout en isolant les modifications proposées dans un environnement sandbox et en les soumettant à un examen avant leur adoption. L’agent peut analyser les échecs, proposer une correction, relancer la regression, puis présenter les changements et le résultat à l’ingénieur au lieu de modifier directement le code.
Cette prudence est d’autant plus importante que les outils de vérification eux-mêmes peuvent contenir des erreurs. L’article mentionne une étude qui a révélé 16 erreurs distinctes dans trois outils commerciaux de vérification de l’équivalence entre C et RTL, notamment des cas où des conceptions non équivalentes ont été déclarées équivalentes. L’automatisation doit donc transmettre non seulement les données, mais aussi les limites de chaque résultat, ses hypothèses, son état probatoire et son historique de reproductibilité.
Pourquoi cette évolution est-elle importante ?
Le prochain critère de compétitivité dans l’EDA ne sera pas le nombre d’agents ni la quantité de temps économisée par un outil isolé, mais la capacité du flux à produire des preuves auditables à travers ses frontières. Cela est particulièrement important pour les conceptions liées à la sûreté, à la sécurité et à l’automobile, où il ne suffit pas d’affirmer que le système a convergé plus rapidement ; il faut savoir quelles propriétés sont prouvées, lesquelles restent limitées, ce que l’intelligence artificielle a proposé et ce qui n’a pas été vérifié.
Les contraintes restent toutefois claires. Les modèles actuels ne sont pas suffisamment spécialisés, peu coûteux ou conscients de la physique pour générer à la demande du RTL, des layouts analogiques, des boîtiers avancés ou des netlists entièrement optimisées avec une vérification finale. De même, l’ajout d’une interface d’intelligence artificielle ne résout pas le goulot d’étranglement si la configuration de la simulation prend toujours des heures et son exécution des jours. La valeur apparaît lorsque les analyses fondamentales sont rapides, automatisées, déterministes et utilisables pendant l’évolution de la conception.
La lecture la plus importante est que l’intelligence artificielle n’abolira pas les frontières entre les spécifications, l’implémentation, la vérification et la validation. Elle peut toutefois réduire le coût de réconciliation à chaque frontière, à condition que celles-ci cessent d’être des lieux de perte de sens pour devenir des points de collecte de preuves. En pratique, le modèle le plus proche de la réalité reste le suivant : l’intelligence artificielle pour l’exploration, la coordination et la rapidité, et les moteurs EDA déterministes pour prouver la validité du résultat.