Jean-Marie Brunet est vice-président et directeur général de la division Vérification assistée par matériel (HAV) de Siemens EDA . Lui-même et son équipe ont récemment annoncé la disponibilité du système de vérification et de validation assistées par matériel Veloce CS, qui comprend le système d’émulation Veloce Strato CS, le système de prototypage d’entreprise Veloce Primo CS et le système de prototypage à grande vitesse Veloce proFPGA CS.
Dans un secteur qui n’évolue habituellement qu’à petits pas, Veloce CS marque une rupture car il s’agit d’un système trois-en-un complet ; une nouveauté dont Jean-Marie Brunet discute avec vous aujourd’hui.
Comment décrier le système Veloce CS ?
Jean-Marie Brunet : Le système Veloce CS est conçu pour offrir congruence, rapidité et modularité. Il prend en charge des conceptions allant de 40 millions à plus de 40 milliards de portes. Il traite des charges de travail complètes en offrant une visibilité et une congruence supérieures, ce qui permet aux équipes de sélectionner l’outil le mieux adapté aux exigences spécifiques d’une tâche, afin d’accélérer l’achèvement du projet et de réduire le coût par cycle de vérification.
Pourquoi le lancer maintenant ?
J.-M. Brunet : Nous avons pris conscience de la discontinuité créée par la convergence du matériel lié à l’IA, des produits définis par logiciel, des nouvelles technologies de procédé et de l’émergence des systèmes basés sur des chiplets . Nous avons réagi en développant trois systèmes évolutifs et économiques qui répondent directement aux besoins des équipes de conception. Notre objectif est que Veloce CS devienne l’instrument de création de la prochaine génération de circuits intégrés avancés et de modules multipuces, et qu’il permette aux équipes de conception d’atteindre de nouveaux niveaux en matière d’intégrité des conceptions, de productivité et de calendrier d’achèvement. Nous sommes porteurs d’une nouvelle proposition de valeur pour les fournisseurs de CI, créateurs d’IP ou développeurs de systèmes qui transformeront ces circuits avancés en moteur de croissance de leur chiffre d’affaires
Qu’est-ce qui a changé pour permettre d’améliorer ainsi la proposition de valeur ?
J.-M.Brunet : Des changements majeurs sont intervenus dans l’échelle de conception, le rôle du logiciel, l’environnement physique dans lequel les puces sont conçues et la technologie qui sous-tend le système Veloce CS.
L’échelle des conceptions de CI a augmenté, sous l’effet de la demande pour quelques applications-clés : les UC et GPU des centres de données et les accélérateurs pour l’IA. Dans ce dernier cas, l’explosion de la demande dans le domaine de l’entraînement des modèles d’IA générative et les recherches portant sur celle-ci sont à l’origine d’un appétit insatiable pour le matériel.
Les conceptions de puces contiennent désormais l’équivalent de dizaines de milliards de portes. Le secteur a répondu par de nouvelles générations de puces gravées en 3 nm et 2 nm et des modules multipuces. Les équipes de conception veulent traiter le RTL de ces puces comme si elles formaient une seule puce monolithique, ce qui pousse les nombres de portes équivalents au-delà de la capacité d’une seule puce 2 nm.
Dans le même temps, la taille et la complexité des piles logicielles ont augmenté plus rapidement que les capacités du matériel, en raison de l’identité des concepteurs. Jusqu’à récemment, les UC et les GPU, conçues par des fondeurs commerciaux ou des entreprises de développement d’IP, étaient soumises à des suites d’outils de vérification sophistiquées afin de prouver qu’elles mettaient correctement en œuvre une architecture de jeu d’instructions ou un jeu de commandes. Au-dessus de ce niveau, les piles logicielles – pilotes, systèmes d’exploitation, logiciels intermédiaires et surtout code applicatif – étaient le problème de l’acheteur.
Aujourd’hui, de nombreux CI sont conçus par des fournisseurs de systèmes (fournisseurs de services cloud, géants des télécoms, constructeurs automobiles, entreprises du secteur aérospatial) pour des applications spécifiques et ne constituent pas le produit final. C’est le système, y compris la pile logicielle complète, qui constitue le produit qu’une équipe de conception doit vérifier. Il ne suffit plus de vérifier la conception du RTL à l’aide de bancs d’essai synthétiques et de fragments de code dépendant du matériel. Les équipes de conception vérifient et caractérisent désormais la conception d’un système en commençant au niveau du RTL et en exécutant des charges de travail de production complètes. Face à cette nouvelle exigence, l’effort principal de la conception frontale ne consiste plus à vérifier le RTL par rapport à une spécification mais en utilisant des piles logicielles complètes, incluant le code applicatif.
Les deux branches du développement – RTL pour le matériel et logiciel pour l’application – doivent progresser en parallèle. Au début de la conception, l’essentiel de l’effort portera sur la conception et le débogage du logiciel, avec une communication bidirectionnelle entre les équipes RTL et logiciel.
Pourquoi trois systèmes ?
J.-M. Brunet : Les concepteurs RTL, les codeurs de logiciels et les ingénieurs système doivent collaborer. Pendant que l’équipe de conception RTL crée et vérifie la conception de la puce, les équipes chargées du logiciel développent et testent les pilotes, le système d’exploitation, le logiciel intermédiaire et le code applicatif et les intègrent à la conception de la puce et au matériel associé à la carte. Parallèlement, les cartes et les périphériques du système global sont également en cours de conception.
Ces tâches sont effectuées simultanément et un seul système ne peut pas répondre de manière optimale à ces trois besoins. Il en faut trois pour répondre aux exigences rigoureuses des conceptions actuelles, et les trois doivent avoir en commun une grande partie de leur ADN.
Quelle est la proposition de valeur de Siemens ?
J.-M. Brunet : Le faible coût d’achat et d’exploitation, l’intégration transparente dans le centre de données et la partageabilité définissent la proposition de valeur des systèmes Veloce Strato CS et Veloce Primo CS au niveau de l’entreprise. Mais les performances élevées, la rapidité de compilation des modèles, l’extensibilité à 44 milliards de portes et la congruence, ainsi que la communauté des modèles RTL, des opérations et des bases de données entre ces deux systèmes, ont été étendues au système à grande vitesse proFPGA CS.
Un seul langage de commande, un seul modèle de conception, une seule base de données. Le système Veloce CS relève les défis de cette génération de conceptions de pointe et de la génération suivante. La technologie que nous utilisons pour construire le système Veloce CS n’est pas celle que nous avons utilisée pour notre précédente génération de systèmes. Les FPGA des systèmes de prototypage Veloce Primo CS et Veloce proFPGA CS et les puces programmables personnalisées du système d’émulation Veloce Strato CS ont une capacité supérieure et sont plus rapides et moins énergivores. Nous utilisons la technologie des modules multipuces 2,5D et l’interconnexion optique.
Quelles sont les différences entre ces trois systèmes ?
J.-M. Brunet : Bien que les trois systèmes partagent une interface utilisateur, des modèles RTL et une base de données communs, chacun doit répondre aux exigences de son rôle dans le processus de conception. Chacun possède donc des attributs distincts et est mis en œuvre d’une manière différente.
La capacité est cruciale en raison du nombre élevé de portes. Les systèmes d’émulation et de prototypage d’entreprise doivent pouvoir contenir l’intégralité du modèle RTL compilé de la puce pour qu’il soit possible d’observer l’exécution de la charge de travail réelle. Veloce Strato CS et Veloce Primo CS offrent une évolutivité à granularité fine par plug-in de l’entrée de gamme jusqu’à l’équivalent de 45 milliards de portes, grâce à des processeurs ASIC avancés et, pour le prototypage, à des FPGA avancés, à une interconnexion à grande vitesse et à une architecture modulaire.
La rapidité est indispensable pour tester une conception de puce complète et exécuter des charges de travail réelles. Veloce Strato CS exploite pleinement ses nouveaux ASIC et l’interconnexion optique. Veloce Primo CS utilise des FPGA et une interconnexion avancés qui lui confèrent une vitesse d’exécution supérieure à celle de Veloce Strato CS.
Les modèles de grande taille nécessitent également une compilation rapide. En développant nos compilateurs de modèles RTL en même temps que les architectures internes de Veloce Strato CS et Veloce Primo CS, nous avons accéléré la compilation et évité les problèmes qui la ralentissent. Ainsi, la recompilation sera rapide lorsque le modèle RTL devra être modifié.
Il faut également que le traçage et le déclenchement fonctionnent de manière rapide et compréhensible, ce qui se traduit différemment selon le système. Pendant l’émulation, les concepteurs interagissent généralement finement avec le RTL, en observant les signaux logiques. Avec Veloce Strato CS, tous les signaux du modèle peuvent être assujettis aux commandes de traçage, de déclenchement ou de point d’arrêt. Les systèmes Veloce Primo CS et Veloce proFPGA CS, basés sur des FPGA, imposent que l’accès aux signaux individuels soit spécifié lors de la compilation du modèle. Les développeurs de logiciels, qui interagissent généralement avec le code source et les variables de la charge de travail, bénéficient de la vitesse supérieure de l’architecture FPGA. En contrepartie, ils ont moins de possibilités pour modifier leur accès aux signaux de niveau logique.
Les processus de compilation du modèle RTL pour Veloce Strato CS et Veloce Primo CS sont quasiment identiques. Un commutateur oriente le compilateur vers l’un ou l’autre système, tandis que le modèle reste le même. Veloce proFPGA CS utilise le même modèle RTL.
La congruence garantit que les équipes peuvent partager un même modèle RTL pour travailler ensemble ou séparément et communiquer efficacement. Un modèle RTL sera compilé pour produire le même comportement sur chaque système avec des vitesses d’exécution et des niveaux d’observabilité différents, même si le code compilé sera différent pour chaque système. La même commande utilisateur produira le même résultat sur Veloce Strato CS et Veloce Primo CS et sur Veloce proFPGA CS lorsque le contexte s’y prête.
Les fonctionnalités du système Veloce CS répondent directement aux besoins des équipes de conception, car les entreprises ont besoin de pouvoir partager naturellement et facilement les modèles entre les membres d’un même projet et avec d’autres entreprises.
La configurabilité par logiciel est également importante. Différentes équipes travaillent sur des modèles RTL différents et de différentes tailles, ce qui est une évidence avec les systèmes d’émulation. Mais la configurabilité par logiciel a un coût avec les systèmes de prototypage d’entreprise. La vitesse des liaisons entre les FPGA est essentielle pour la performance globale du système. Les liaisons les plus rapides sont assurées par un câblage fixe ou des câbles enfichables. Mais ces deux types de liaisons réduisent fortement la flexibilité. Pour des raisons de logistique et de sécurité, il est difficile de permettre à une équipe de conception d’accéder pendant plusieurs jours à un système de prototypage d’entreprise situé dans un centre de données éloigné pour en reconfigurer les câbles.
La granularité est un problème pour l’efficience énergétique et économique.
Les plates-formes Veloce Strato CS et Veloce Primo CS s’intègrent parfaitement dans les centres de données des entreprises : elles respectent les normes d’encombrement des racks et les conventions de câblage standard pour l’alimentation et le réseau. Veloce proFPGA CS est physiquement plus petit que les systèmes d’entreprise ; il est conçu pour une utilisation sur table dans un laboratoire, ou bien en rack pour les centres de données dans sa version lame Hexa.
Où les lecteurs peuvent-ils trouver davantage d’informations ?
J.-M. Brunet : Je les invite à télécharger notre livre blanc consacré au système Veloce CS.
Jean-Marie Brunet, vice-président et directeur général de la division Vérification assistée par matériel (HAV) de Siemens EDA
