Automatisation des cas de test C pour la vérification du système intégré

Alors que les conceptions de systèmes sur puce (SoC) progressent vers une plus grande complexité, des suites de tests contenant des milliers de lignes de code pour la vérification au niveau du système continuent d'être écrites à la main, une pratique étrangement ancienne et inefficace défiant l'adage « automatiser dès que possible." Cela est particulièrement vrai pour les tests C qui s'exécutent sur les processeurs intégrés d'un SoC pour vérifier l'ensemble du dispositif avant la fabrication.

Il a été démontré que l'automatisation de la composition des tests de vérification dans la mesure du possible augmente la productivité pour de nombreuses phases de développement de SoC. Les techniques aléatoires contraintes, par exemple, dans un banc d'essai de la méthodologie de vérification universelle (UVM), utilisent des vecteurs de test randomisés dirigés vers des scénarios spécifiques pour augmenter la couverture. Bien que ceux-ci aient augmenté l'efficacité de la vérification au niveau du bloc matériel, la conception est toujours perçue comme une boîte noire avec un stimulus, des vérifications et un code de couverture écrits séparément, ce qui reste une tâche onéreuse et sujette aux erreurs pour les gros blocs.

Il est difficile d'étendre cette méthodologie au niveau système, étant donné la nécessité de combiner le code de test du processeur avec des transactions d'E/S, souvent exécutées sur un émulateur ou un système de prototypage. Pour vérifier correctement un SoC, les processeurs eux-mêmes doivent être exercés. UVM et d'autres approches aléatoires contraintes ne tiennent pas compte du code exécuté sur les processeurs. En effet, pour utiliser UVM sur un SoC, les processeurs sont souvent supprimés et remplacés par des entrées et sorties virtuelles sur le bus SoC permettant de vérifier le sous-système moins le processeur.

Les ingénieurs de vérification de SoC reconnaissent les limites des bancs de test aléatoires contraints, les poussant à écrire à la main des tests C à exécuter sur les processeurs à la fois pour la simulation et l'émulation matérielle, même s'ils sont limités dans l'exercice complet de la conception du SoC. Les performances de ces plates-formes de vérification ne sont pas suffisantes pour exécuter un système d'exploitation (OS) complet, de sorte que ces tests s'exécutent « bare-metal », ce qui ajoute une surcharge importante à l'effort de composition. Il est inhabituel que des tests manuscrits, en particulier sans l'aide des services du système d'exploitation, s'exécutent de manière coordonnée sur des processeurs multicœurs exploitant plusieurs threads. Le résultat est que les aspects du comportement du SoC, tels que les opérations simultanées et la cohérence, sont minimalement vérifiés.

Générer automatiquement des tests C

Bien entendu, les tests C générés automatiquement permettront une utilisation plus efficace des ressources d'ingénierie. Ils augmentent également la couverture. Les cas de test C générés peuvent exercer plus de fonctionnalités du SoC que les tests écrits à la main et rechercheront des cas de coin complexes difficiles à imaginer. Les cas de test multithreads et multiprocesseurs peuvent utiliser tous les chemins parallèles au sein de la conception pour vérifier la simultanéité. Ils peuvent déplacer les données entre les segments de mémoire pour mettre l'accent sur les algorithmes de cohérence et se coordonner avec les transactions d'E/S lorsque les données doivent être envoyées aux entrées de la puce ou lues à partir de ses sorties. L'effet global de ceci est d'augmenter la couverture fonctionnelle du système, généralement supérieure à 90 % par rapport à des nombres généralement bien inférieurs.

Le logiciel de génération de tests, connu sous le nom de Test Suite Synthesis, utilise un modèle de scénario graphique facile à comprendre qui capture le comportement de conception prévu. Ces modèles peuvent être écrits à l'aide du standard Accellera Portable Stimulus Standard en C++ natif ou décrits visuellement. Les modèles de scénario sont créés par des ingénieurs de conception ou de vérification dans le cadre du développement de SoC, car ils ressemblent aux diagrammes de flux de données de puce traditionnels qui peuvent être dessinés sur un tableau blanc pour expliquer une partie des spécifications de conception.

Ces modèles incluent intrinsèquement des stimuli, des vérifications, des détails de couverture et des informations de débogage, fournissant au générateur tout ce dont il a besoin pour produire des cas de test C auto-vérifiés de haute qualité qui mettent l'accent sur tous les aspects de la conception. Parce qu'ils sont hiérarchiques et modulaires, tous les tests développés au niveau du bloc peuvent être entièrement réutilisés dans le cadre du modèle de SoC complet et facilement partagés avec différentes équipes et entre projets. Enfin, le modèle d'intention unique peut être décomposé par l'outil de synthèse pour fournir les tests simultanés sur les threads et les ports d'E/S, tous synchronisés ensemble.

Avantages de la synthèse de suites de tests

Un avantage important de la synthèse de suites de tests est la possibilité de définir des objectifs de couverture dès le départ sur le modèle d'intention. Une fois l'intention spécifiée, l'outil peut l'analyser pour comprendre le nombre de tests qui pourraient être produits et la couverture de l'intention fonctionnelle qui serait atteinte.

Pour un SoC, cela peut compter plusieurs milliers de tests. Les objectifs de couverture peuvent ensuite être fixés en limitant l'intention à tester et en concentrant l'outil sur des domaines clés. Cette capacité évite la douloureuse boucle itérative qui se produit dans les approches traditionnelles, qui consiste à configurer les tests, exécuter l'outil de vérification, comprendre la couverture obtenue, puis réinitialiser les tests encore et encore.

Dans un projet typique sur un grand SoC développé par une société de semi-conducteurs bien connue, les ingénieurs de vérification ont réduit le temps de composition des tests à 20 % de ce qui nécessitait auparavant des tests manuscrits. La technologie d'automatisation a produit des cas de test plus rigoureux, augmentant la couverture de 84 % à 97 %. De plus, les modèles sont portables.

Un seul modèle peut générer des cas de test pour des plates-formes virtuelles, une simulation de niveau de transfert de registre (RTL), une émulation, des prototypes de réseau de portes programmables sur site (FPGA) ou une puce réelle en laboratoire en cours de validation post-silicium.

Le débogage est un autre puits de temps pour les ingénieurs, en particulier au niveau du SoC. Si un cas de test découvre un bogue de conception caché, l'ingénieur de vérification doit comprendre quel test a déclenché le bogue pour en retrouver la source. Un échec de scénario de test peut être dû à une erreur dans le modèle de scénario, il doit donc être possible de corréler le scénario de test au graphique où l'intention de conception a été capturée. Ce processus crée des tests hautement modulaires et autonomes qui sont facilement décomposés, de sorte que le test exécuté pour le bogue découvert est facile à voir.

Scénarios d'application

Les cas de test synthétisés peuvent exercer des cas d'utilisation réalistes, appelés scénarios d'application, pour la conception. Par exemple, considérons le SoC d'appareil photo numérique illustré à la figure 1.

cliquez pour agrandir l'image

Figure 1 :Exemple de SoC de traitement d'images. (Source :Systèmes de vérification Breker)

Les composants de niveau bloc SoC comprennent deux processeurs, les périphériques et la mémoire. Un graphique simple pour le SoC est présenté sous le schéma fonctionnel. Le graphique comprend les chemins de haut niveau possibles qui peuvent être exercés dans le processus de vérification du SoC. Par exemple, un scénario possible, exprimé dans le chemin supérieur du graphique, lit une image JPEG à partir de la carte SD et la transmet au processeur photo via une région allouée en mémoire. L'image est traitée sous une forme qui peut être affichée et chargée dans un deuxième bloc en mémoire. De là, il est transmis au contrôleur d'affichage. Bien entendu, chacun de ces blocs de haut niveau est de nature hiérarchique avec de nombreuses actions et décisions exécutées dans le cadre du processus.

L'outil de synthèse prendra le test randomisé et les programmera de manière appropriée. Dans la forme la plus simple, comme le montre la figure, le test peut être planifié dans un seul thread, suivi du test suivant et ainsi de suite. Cependant, la capacité des cas de test à stresser le SoC provient de l'imbrication des applications sur plusieurs threads et plusieurs processeurs. L'outil exécutera autant d'applications en parallèle que pris en charge par la concurrence inhérente à la conception, en allouant la mémoire au fur et à mesure de la manière la plus tortueuse possible. Ceci est également montré comme une alternative dans la figure où les tests sont répartis sur trois threads, en utilisant diverses régions allouées à travers les mémoires SoC.

Bien sûr, cet exemple est présenté à un niveau élevé pour rendre le processus clair. En réalité, le graphe hiérarchique sera aplati par l'outil de synthèse, créant un grand nombre d'actions et de connexions. Ceux-ci incluront également des décisions aléatoires, qui doivent être exécutées via un algorithme de résolution. Au fur et à mesure que le graphique est parcouru, des algorithmes de planification d'IA sont utilisés pour inspecter les sorties souhaitées et optimiser les tests d'entrée pour y correspondre. L'outil de synthèse comprend des services de type système d'exploitation qui allouent de la mémoire, fournissent un accès à la carte d'adresses, traitent les interruptions et d'autres tâches nécessaires pour terminer les structures de test. Les tests sont ensuite programmés de manière aléatoire avec le stockage et d'autres ressources alloués de manière appropriée.

Conclusion

Tout comme les bancs de test aléatoires contraints éliminaient le travail manuel pour la vérification des blocs, il a été prouvé que le contenu de test synthétisé pour les SoC à processeur intégré réduisait l'effort de vérification au niveau du système. De plus, cette solution est maintenant appliquée au niveau du bloc et pour la validation post-silicium. Dans cet exemple, les cas de test C automatisés appliquent l'adage « automatiser chaque fois que possible », améliorant considérablement la couverture tout en raccourcissant les calendriers de vérification.