Automatiser la génération de tests C pour une vérification complète des SoC embarqués

Les conceptions de SoC deviennent de plus en plus complexes, pourtant de nombreuses suites de tests de vérification au niveau système consistent encore en des milliers de lignes de code C écrites manuellement — une approche archaïque qui contredit le principe d'automatisation. En particulier, les tests C exécutés sur les processeurs embarqués pour valider l'ensemble du dispositif avant la fabrication restent largement manuels.

L'automatisation de la création de tests booste la productivité à travers les étapes de développement SoC. Les méthodes à contraintes aléatoires dans un banc de test UVM génèrent des vecteurs aléatoires spécifiques aux scénarios, améliorant la couverture au niveau bloc. Cependant, la conception reste une boîte noire, avec le stimulus, les vérifications et le code de couverture écrits séparément — un processus fastidieux et propice aux erreurs pour les grands blocs.

Étendre ces méthodes au niveau système est difficile car elles doivent intégrer le code de test du processeur avec les transactions I/O, généralement exécutées sur émulateurs ou prototypes. La vérification complète du SoC nécessite d'exercer les processeurs eux-mêmes, mais l'UVM et autres techniques à contraintes aléatoires omettent généralement le code processeur. En pratique, l'UVM est appliquée au SoC en remplaçant les processeurs par des I/O virtuels, laissant le sous-système sans le processeur sous test.

Face aux lacunes des bancs de test à contraintes aléatoires, les ingénieurs se rabattent sur l'écriture manuelle de tests C s'exécutant sur les processeurs en simulation et émulation matérielle. Cependant, ces plateformes ne peuvent pas supporter un OS complet ; les tests s'exécutent en mode bare-metal, augmentant l'effort de composition. L'exécution coordonnée multi-cœur, multi-thread est rare, si bien que les comportements critiques — concurrence et cohérence — reçoivent une vérification limitée.

Génération automatique de tests C

La génération automatisée de tests C libère du temps d'ingénierie et étend la couverture. Les cas de test générés couvrent davantage les fonctionnalités du SoC que les tests manuels, dévoilant des cas limites difficiles. Les tests multi-thread, multi-processeurs exercent tous les chemins parallèles, valident la concurrence, stressent la cohérence mémoire et se synchronisent avec les transactions I/O. Résultat : la couverture fonctionnelle au niveau système dépasse régulièrement 90 %, bien au-delà des approches traditionnelles.

L'outil de génération de tests — Test Suite Synthesis — s'appuie sur un modèle de scénario clair, basé sur des graphes, qui encapsule le comportement de conception visé. Les ingénieurs peuvent créer ces modèles en C++ natif en utilisant le standard Accellera Portable Stimulus ou visuellement, reflétant les diagrammes de flux de données de puce traditionnellement esquissés sur tableau blanc lors des discussions de conception.

Chaque modèle encapsule stimulus, vérifications, métriques de couverture et données de débogage, donnant au générateur toutes les informations requises pour produire des tests C auto-vérifiants de haute qualité qui exercent chaque aspect de la conception. Des modèles hiérarchiques et modulaires permettent de réutiliser les tests au niveau bloc dans les modèles SoC complets et de les partager entre équipes et projets. L'outil de synthèse décompose un unique modèle d'intention en tests concurrents s'étendant sur threads et ports I/O, assurant une synchronisation étroite.

Avantages de la synthèse de suite de tests

Un avantage clé est la capacité de définir des objectifs de couverture au niveau du modèle d'intention. Après spécification de l'intention, l'outil l'analyse pour estimer le nombre de cas de test requis et la couverture fonctionnelle attendue.

Dans un SoC typique, des milliers de tests peuvent être générés. En contraignant l'intention, les ingénieurs peuvent cibler des objectifs de couverture spécifiques et concentrer l'outil sur les zones critiques. Cela élimine le cycle itératif fastidieux de définition des tests, exécution de la vérification, évaluation de la couverture et reconfiguration.

Une étude de cas sur un grand SoC d'un leader des semi-conducteurs a démontré une réduction de 80 % du temps de composition des tests par rapport aux tests manuels. L'automatisation a généré des cas plus rigoureux, faisant passer la couverture de 84 % à 97 %. Les modèles se sont avérés portables across environments.

Un unique modèle d'intention peut produire des cas de test pour plateformes virtuelles, simulation RTL, émulation, prototypes FPGA, voire la puce fabriquée lors de la validation post-silicium.

Le débogage reste un gouffre de temps au niveau SoC. Quand un test révèle un défaut, les ingénieurs doivent remonter à l'origine du test et au modèle de scénario sous-jacent. En corrélant chaque cas de test à sa représentation graphique, des tests modulaires et auto-contenus permettent une isolation et une analyse rapides des bogues.

Scénarios d'application

Les cas de test synthétisés peuvent piloter des scénarios d'utilisation réalistes. Prenons l'exemple du SoC de caméra numérique illustré Figure 1.

Figure 1 : Exemple de SoC de traitement d'image. (Source : Breker Verification Systems)

Les composants au niveau bloc du SoC comprennent deux processeurs, périphériques et mémoire. Un graphe simplifié sous le diagramme de blocs illustre les chemins de haut niveau pour la vérification. Un scénario — chemin du haut — lit un JPEG depuis une carte SD, l'achemine vers le processeur photo via une région mémoire, transforme l'image pour l'affichage, la charge dans un second bloc mémoire, puis l'envoie au contrôleur d'affichage. Chaque bloc de haut niveau est hiérarchique, contenant de nombreuses actions et décisions.

L'outil de synthèse planifie les tests randomisés en conséquence. Sous sa forme la plus simple, les tests s'exécutent séquentiellement en un seul thread, comme illustré. La vraie puissance émerge quand l'outil entrelace les applications sur plusieurs threads et processeurs, exécutant autant d'instances concurrentes que le permet la conception et allouant la mémoire selon des motifs complexes. Une vue alternative dans la figure montre les tests répartis sur trois threads, exploitant diverses régions mémoire.

Bien que l'illustration soit de haut niveau, l'outil de synthèse aplatit réellement le graphe hiérarchique en milliers d'actions et connexions, incorporant des décisions randomisées passant par un algorithme solveur. Au fur et à mesure de la traversée du graphe, des algorithmes de planification IA analysent les sorties désirées et affinent les tests d'entrée pour un alignement optimal. L'outil fournit aussi des services de type OS — allocation mémoire, accès à la carte d'adresses, gestion d'interruptions — pour supporter des structures de test complètes, puis planifie les tests aléatoirement tout en allouant stockage et ressources.

Conclusion

Tout comme les bancs de test à contraintes aléatoires ont éliminé l'effort manuel de la vérification bloc, le contenu de test synthétisé pour les SoC à processeurs embarqués a prouvé qu'il réduit l'effort de vérification au niveau système. L'approche s'étend maintenant à la vérification bloc et à la validation post-silicium. Les tests C automatisés incarnent le principe « automatiser chaque fois que possible », offrant des gains de couverture dramatiques et des calendriers de vérification compressés.