Tous pour un, un pour tous : une histoire entreprenante de la vérification matérielle du SoC

Les équipes de conception de SoC sont chargées d’effectuer une vérification complète au niveau du système avant la création de masques de production coûteux. Pour accomplir cette tâche, les équipes doivent examiner minutieusement tous les blocs matériels, toutes les interactions entre ces blocs et le logiciel spécialement conçu pour l’application finale avant même que la puce ne soit construite. Alors que les émulateurs matériels et les cartes prototypes FPGA de bureau sont deux participants bien connus à cette vérification, les plates-formes prototypes FPGA d’entreprise prennent désormais leur place à leurs côtés en tant que troisième participant.

Alors que la simulation domine dans les premières étapes d’une conception, son utilisation est limitée aux blocs de circuits en raison de performances inadéquates. Une fois que la vérification complète de la puce commence, une plus grande vitesse est nécessaire à la fois pour gérer le nombre énorme de tests requis pour obtenir une couverture matérielle complète et pour intégrer le logiciel au matériel. L’émulation a assumé l’essentiel de ce fardeau. En parallèle, lorsque le code RTL atteint la stabilité, la validation de l’application logicielle peut commencer. En raison de leur vitesse d’exécution supérieure, les cartes de prototypage de bureau excellent dans ce domaine.

Au cours des dix dernières années, un nouvel outil comble le fossé entre les puissantes capacités d’analyse/débogage de l’émulateur et les performances brutes de la carte de prototypage. Appelé « prototypage FPGA d’entreprise », il allie les caractéristiques d’émulation et le prototypage de bureau pour répondre aux nouveaux cas d’utilisation qui déchargent les émulateurs. Cela permet à une équipe de vérification d’augmenter ses ressources de vérification basées sur le matériel à haute vitesse tout en optimisant le coût total de possession. Ensemble, l’émulation, le prototypage d’entreprise et le prototypage de bureau peuvent mettre un SoC sur le marché plus rapidement et avec une plus grande confiance dans l’exactitude du silicium.

Tâches d’émulation – nouvelles et anciennes

Les émulateurs sont devenus les chevaux de bataille de la vérification du matériel SoC. Capables d’exécuter des ordres de grandeur plus rapidement que la simulation, ils ont été essentiels pour vérifier l’incroyable quantité de matériel placé sur une seule puce.

La conception de l’émulateur reflète un équilibre entre les performances, l’infrastructure requise pour implémenter le large éventail de conceptions possibles et, plus important encore, l’instrumentation complète qui permet un débogage approfondi en cas de problème. Par conséquent, même s’ils ne s’exécutent pas aussi vite qu’une application finale, ils s’exécutent suffisamment rapidement pour démarrer les systèmes d’exploitation tout en explorant les logiciels de bas niveau tels que les pilotes et les programmes sans système d’exploitation.

L’émulation en circuit, ou ICE, est une autre tâche d’émulation qui était auparavant plus répandue. En connectant l’émulateur à des réseaux physiques ou à un autre matériel pour fournir un trafic de données réaliste, il est possible d’exercer en profondeur la conception sous test (DUT) avec des charges de travail réelles et de déterrer des bogues profondément enracinés. Cependant, étant donné que les connexions ICE nécessitaient des adaptateurs de débit pour ralentir les débits de données du monde réel pour correspondre à la vitesse de l’émulateur, les équipes de vérification sont passées à des générateurs de trafic virtualisés au lieu d’ICE.

Les générateurs de trafic virtuel peuvent être connectés sur le réseau sans nécessiter d’adaptateurs de débit correspondant à la vitesse de l’émulateur, facilitant le déploiement sans pilote d’émulateurs dans les centres de données, accessibles de n’importe où dans le monde 24h/24 et 7j/7. Les générateurs de trafic virtualisés peuvent créer des charges de travail réalistes pour un large éventail d’applications. Voir figure 1.

Le rôle des cartes prototypes de bureau

Bien que les émulateurs puissent tester des logiciels de bas niveau, ils ne sont pas toujours le meilleur outil pour vérifier les logiciels d’application de niveau supérieur. Un tel logiciel doit d’abord être débogué au niveau logiciel, où la vitesse d’exécution rapide est primordiale et le débogage matériel n’est pas nécessaire. L’exécuter sur un émulateur est excessif et inefficace. Sans oublier qu’il y a plus de développeurs de logiciels que le nombre d’émulateurs disponibles ne pourrait en servir.

Les cartes prototypes de bureau ont été la réponse à ce besoin. Ils sont configurés une fois que la conception matérielle s’est stabilisée, avec peu de modifications de conception de silicium à venir pendant le cycle de vérification restant. Le réseau FPGA reconfigurable permet d’optimiser les performances lors de la mise en œuvre du DUT. Ils peuvent fonctionner jusqu’à un ordre de grandeur plus rapidement que l’émulateur.

Ces cartes sont distribuées aux développeurs de logiciels qui les connectent à leurs serveurs de bureau. Lorsque vient le temps d’exécuter des tests logiciels, ils peuvent obtenir des résultats basés sur la conception matérielle réelle beaucoup plus rapidement.

En raison de leur vitesse, il a été plus facile de connecter ces cartes directement à des sources de données réelles sans avoir recours à des adaptateurs de débit, favorisant le déplacement d’ICE hors des émulateurs et sur des cartes prototypes de bureau.

La vitesse d’exécution remarquable obtenue en optimisant manuellement l’interconnexion de quelques FPGA sur les cartes contraste avec la capacité de conception limitée par rapport à l’émulation. Moins de composants signifie également un coût inférieur qui facilite la prolifération parmi les développeurs de logiciels.

Les hautes performances et la portabilité des cartes prototypes FPGA en font des véhicules uniques en tant que plates-formes de démonstration pour les fournisseurs OEM de blocs IP.

L’environnement de vérification entièrement SoC comportait jusqu’à récemment ces deux moteurs de vérification assistée par matériel : l’émulateur hébergé dans un centre de données avec des ressources accessibles via le réseau ; et la carte prototype de bureau située dans les bureaux des développeurs de logiciels pour un accès facile.

Les émulateurs doivent être déchargés

L’émulateur a un rôle central de vérification du SoC. En plus du débogage matériel et de l’intégration matériel/logiciel, il peut être utilisé efficacement pour exécuter de longues suites de régression composées d’un grand nombre de tests. A titre d’exemple, les tests déjà réussis doivent être réexécutés à chaque changement de circuit pour garantir l’intégrité du DUT. L’exécution de ces suites de régression aussi rapidement que possible est essentielle pour éviter de dépasser la fenêtre de temps allouée à la tâche de vérification. L’émulateur peut relever le défi, mais ses capacités de débogage étendues restent inutilisées. Ce n’est que lorsqu’un test de régression échoue que ces puissantes capacités de débogage entrent en jeu pour retracer le bogue et déterminer la cause première de l’échec. De toute évidence, immobiliser une ressource aussi précieuse pour une tâche qui n’utilise que les performances mais pas les moyens de débogage est inefficace.

Un prototype de bureau pourrait être un moyen d’exécuter des régressions matérielles encore plus rapidement que l’émulation, mais ils sont généralement entre les mains des développeurs de logiciels où ils exécutent des régressions logicielles. Les mettre entre les mains des équipes de matériel signifierait envoyer des cartes à un nombre encore plus grand de développeurs. Si un prototype pouvait être instancié dans le centre de données de la même manière qu’un émulateur, il serait alors accessible de n’importe où pour une utilisation par régression matérielle.

Le prototypage d’entreprise comble le vide

C’est le rôle de la plateforme de prototypage d’entreprise. Il est monté en rack et accessible à distance au même titre que l’émulateur. Il fonctionne à une vitesse plus proche de celle d’un prototype de bureau que d’un émulateur, favorisant son déploiement pour exécuter des suites de régression et décharger l’émulateur. Si un test de régression échoue, les ressources de débogage disponibles sur l’émulateur peuvent être mises en action en déplaçant facilement ce test dans l’environnement d’émulation pour le débogage de la cause première.

Dès la sortie de la boîte, un prototype d’entreprise fonctionne cinq fois plus vite qu’un émulateur. Avec quelques travaux d’optimisation de réseau FPGA supplémentaires, ce gain peut être augmenté jusqu’à 10 fois. L’avantage évident est que les suites de régression s’exécuteront plus rapidement, aidant à supporter le fardeau nocturne sans embourber les émulateurs.

En plus d’offrir une vitesse d’exécution plus rapide, la plate-forme de prototype d’entreprise s’adapte à des tailles de conception plus grandes que la carte de prototype de bureau et est moins coûteuse que l’émulateur, ce qui contribue à multiplier son adoption par de plus grandes équipes d’ingénieurs de vérification/validation.

Tout comme leurs homologues de bureau, les prototypes d’entreprise peuvent être utilisés pour ICE, en exploitant des connexions de source de données directes et non virtualisées. Alors que les sources de données physiques utilisées pour l’émulation subissent une latence de transaction supplémentaire en raison de la connexion réseau, une connexion de données directe fournit ces données plus proches du temps réel.

En prenant en charge les régressions, la vérification logicielle avec des charges de travail réelles et les tests virtuels et ICE, le prototype d’entreprise peut alléger la charge de travail de l’émulation tout en offrant les avantages des fonctionnalités, de la vitesse et du coût du prototype.

Les émulateurs peuvent héberger n’importe quel nombre de conceptions un jour donné. Ils sont même assez grands pour héberger plusieurs projets en même temps. Leur facilité de configuration sur le réseau permet de maximiser leur utilisation. Pour cette raison, un ensemble donné de tests peut s’exécuter sur un émulateur un jour et un autre le lendemain.

La configuration, y compris la connexion des sources de données ICE, se produit au début du projet, et ces prototypes sont ensuite disponibles selon les besoins jusqu’à la fin du projet. À ce stade, ils peuvent être réutilisés pour un autre projet sans les expédier dans le monde entier.

La connexion de vérification complète du SoC

Combinant des émulateurs, des cartes de prototypage FPGA de bureau et des plates-formes de prototypage FPGA d’entreprise, et travaillant sur la même conception de SoC où un est pour tous et tous sont pour un, une équipe de vérification peut assembler une triade de vérification assistée par matériel parfaitement adaptée. Cela garantit une vérification et une validation approfondies et exhaustives du matériel et des logiciels d’un SoC moderne et complexe.

Le tableau I résume les principales différences entre les trois moteurs de vérification assistée par matériel. (Source du tableau : Lauro Rizzatti)

Caractéristiques principales	Matériel Émulateur	Prototype FPGA d’entreprise	Prototype FPGA de bureau
Noyau programmable	Puce propriétaire	FPGA commercial
Évolutivité	Jusqu’à 2.5BG/Rack	Jusqu’à 80xFPGA/Rack	Jusqu’à 4xFPGA/carte
Granularité	Niveau Conseil	Niveau FPGA
Interconnexion FPGA	Reprogrammable	Reconfigurable manuellement
Multi-utilisateur	Oui	Oui	Non
DUT Mémoires	Modèles SW	Modèles SW	Modèles matériels
Compilation	Pleinement Automatique	Front-end partagé avec émulation	Autonome
Mode de déploiement	ICE, Virtuel, Hybride	ICE, Virtuel, Hybride	Principalement de la GLACE
Déboguer	Visibilité totale	Basé sur la sonde	Basé sur la sonde
Utilisation typique	Débogage HW et intégration HW/SW	Logiciel et système Validation	Logiciel et système Validation
Plateforme de démonstration	Non	Non	Oui

En résumé:

• Émulateurs fournir la capacité et la visibilité de débogage nécessaires pour vérifier les grands SoC, y compris le matériel, les pilotes logiciels, les systèmes d’exploitation et des portions de code d’application.
• Prototypes de FPGA d’entreprise fournir du matériel plus performant pour exécuter des suites de régression d’émulation, exécuter des tests ICE et vérifier le logiciel d’application.
• Prototypes de FPGA de bureau sont disponibles pour les développeurs de logiciels qui souhaitent un contact plus direct avec leurs prototypes pour des tests locaux. Ces tests peuvent aller et venir entre l’unité de bureau et l’unité d’entreprise pour maximiser l’utilisation des ressources disponibles. De plus, les développeurs peuvent envoyer des prototypes de bureau à leurs clients pour faciliter l’intégration, la vérification et la validation du système.

Le système prototype d’entreprise offre une capacité supérieure à celle de la carte prototype de bureau et offre une vitesse plus élevée et un coût par porte et mégahertz inférieur à celui d’un émulateur. Cela aide les équipes de vérification à réduire le coût global de possession de leurs ressources de vérification matérielle tout en accélérant le cycle de vérification.