Application de la vérification basée sur des modèles dans le développement de circuits intégrés ASIC pour l'automobile

Dans les entreprises de semi-conducteurs qui développent pour l’industrie automobile, les équipes d’ingénierie sont invitées à fournir des systèmes de plus en plus complexes dans des délais serrés. Le respect de ces délais serrés s’accompagne de difficultés liées aux tests de dernière minute. Par exemple, attendre que le RTL soit disponible pour démarrer la vérification fonctionnelle comporte un risque de dépassement de coûts et de retards de livraison. Les défauts de conception et les problèmes d’exigences détectés à ce stade sont beaucoup plus coûteux et difficiles à corriger, et les équipes perdent un temps précieux à débugger des scénarios irréalistes. Dans cet environnement, le shift-left testing, dans lequel les activités de vérification sont menées le plus tôt possible dans le cycle de développement, répond à ces défis de test en phase tardive.

Certains membres de notre équipe chez Allegro MicroSystems ont adopté une nouvelle approche de shift-left ou décalage vers la gauche, utilisant l’approche Model-Based Design pour les blocs DSP qui intègre la génération de code HDL pour les ASIC à signaux mixtes, ainsi que la génération de test benches UVM (Universal Verification Methodology) pour la vérification au niveau RTL. Avec cette approche de vérification basée sur un modèle, nous bénéficions d'une vérification fonctionnelle précoce dans Simulink^® et d’une vue au niveau du système du design qui facilite la collaboration entre les ingénieurs système et les équipes de vérification (Figure 1). La vérification précoce du modèle conduit à une meilleure qualité du HDL, car les problèmes de design et d’exigences de haut niveau sont détectés et éliminés avant la génération du code. Nous espérons que cette détection précoce des bugs permettra d’économiser deux mois de travail de vérification. Nous bénéficions également de tests rigoureux de l’implémentation HDL dans notre environnement UVM et de la réutilisation des modèles et des ressources de test dans tous les projets.

Des exigences à la spécification exécutable jusqu'à l’implémentation

Dans un workflow de développement traditionnel, l'ingénieur système rédige des exigences textuelles qui sont utilisées par l'équipe de design numérique (architectes système et ingénieurs RTL) pour produire la spécification et, à partir de là, le design RTL. Notre groupe, l’équipe de vérification numérique, serait ensuite responsable de la création d’un plan de test basé sur la spécification et la vérification fonctionnelle pour garantir que le design RTL est conforme à la spécification. Dans ce workflow, lorsqu'un défaut est détecté (généralement tard dans le cycle de développement), il peut falloir beaucoup de temps pour déterminer si la cause première du défaut réside dans l'implémentation, la spécification ou les exigences d'origine.

Avec notre approche actuelle, le workflow est conçu pour permettre la vérification de l’architecture et des exigences beaucoup plus tôt. Une fois les exigences définies dans Jama Connect^® par l'ingénieur système, l'équipe de design numérique crée un modèle de spécification d'architecture dans Simulink. Ce modèle agit comme une spécification exécutable du système. En exécutant des simulations avec ce modèle, l’équipe effectue des tests unitaires et d’intégration model-in-the-loop pour valider les exigences et vérifier l’architecture (Figure 2). Lors de notre premier projet utilisant cette approche, ces simulations nous ont aidés à identifier plusieurs problèmes, notamment un scénario dans lequel les instructions conditionnelles se contredisaient, conduisant à une sortie invalide pour certaines combinaisons de stimuli d’entrée.

Dans l’étape suivante du développement, l’équipe traduit le modèle d’architecture en un modèle d’implémentation plus convivial pour le hardware, en préparation de la génération de code avec HDL Coder™. Cela peut inclure, par exemple, la conversion d'algorithmes de virgule flottante à virgule fixe, ou le passage d'un traitement par trames à un traitement continu, en streaming.

Modèles de banc d'essai et vérification dans Simulink

À mesure que l’équipe de design numérique crée des composants dans le modèle d’implémentation, des modèles de test bench Simulink pour ces composants sont développés en parallèle. Chaque modèle de test bench Simulink contient les sous-systèmes suivants correspondant aux composants UVM : séquence, pilote, DUT, prédicteur, moniteur et tableau de bord (Figure 3). Seuls les sous-systèmes de séquence, DUT et de tableau de bord sont requis pour la génération du test bench avec HDL Verifier™.

Le sous-système séquence génère des stimuli pour le dispositif testé, ou sous-système DUT, qui dans ce workflow est le modèle d'implémentation créé dans Simulink. Ce sous-système crée et randomise des stimuli à l'aide de code MATLAB^® et de blocs Simulink, y compris le bloc Test Sequence. Son entrée de départ est utilisée pour initialiser le générateur de nombres aléatoires MATLAB. Le sous-système tableau d'affichage collecte la sortie du DUT et la compare à la sortie attendue via les blocs Assertion for DPI-C, qui sont utilisés pour générer des composants DPI-C contenant des assertions SystemVerilog (Figure 4). (L'interface de programmation directe SystemVerilog [DPI] est une interface entre SystemVerilog et un langage de programmation étranger tel que le C. HDL Verifier peut générer des composants DPI-C constitués de code C avec du code de liaison SystemVerilog ; les composants DPI-C résultants peuvent ensuite être exécutés par des simulateurs HDL prenant en charge SystemVerilog.)

L'exécution de simulations dans Simulink avec le modèle de test bench ainsi qu’avec divers outils de vérification et de validation de modèle, tels que Simulink Test™, valide davantage le modèle d'implémentation par rapport aux exigences. Nous récupérons les résultats de ces simulations de Simulink dans Jama pour faciliter les tests basés sur les exigences. De plus, Simulink Design Verifier™ peut être utilisé pour identifier la logique de code mort dans le mode.

Génération de code, génération de test bench, et simulation et test HDL

Une fois le modèle d'implémentation et les modèles de test bench construits et utilisés pour terminer la phase de vérification du design du workflow dans Simulink, nous commençons la phase suivante : génération et vérification de code HDL. Dans cette phase, nous utilisons HDL Coder pour générer du code HDL synthétisable à partir des composants du modèle d'implémentation. Nous utilisons également HDL Verifier, en particulier la fonction uvmbuild du module complémentaire ASIC Testbench, pour générer des test benches UVM complets à partir des modèles de test bench Simulink (Figure 5). (Une autre fonction incluse dans ASIC Testbench, dpigen, génère des composants DPI-C à partir de code MATLAB ou de modèles Simulink pour les équipes de design qui n'utilisent pas d'environnements UVM.)

À l'aide du test bench généré, nous exécutons ensuite des tests dans notre environnement UVM sur le code généré à partir du modèle d'implémentation avec d'un simulateur numérique, tel que Cadence^® Simulateurs Xcelium™ (Figure 6). Nous étendons le test bench UVM généré selon les besoins pour ajouter des randomisations contraintes plus complexes, des vérificateurs d'assertions et des groupes de couverture SystemVerilog pour l'analyse de couverture fonctionnelle. Lorsqu'un test échoue dans l'environnement UVM, nous utilisons la configuration d’origine et de la mémoire du test ayant échoué pour reproduire les conditions d'échec dans une simulation Simulink, ce qui permet à l'ingénieur design de débugger et de corriger la situation d’échec beaucoup plus facilement, par rapport au débuggage direct au niveau HDL.

Prochaines étapes

Alors que les exigences des clients deviennent de plus en plus fortes et que les délais de livraison se réduisent, la vérification basée sur les modèles que nous avons adoptée aide nos équipes à fournir des algorithmes et des systèmes plus sophistiqués avec un délai de mise sur le marché réduit. Nous prévoyons d'étendre cette approche shift-left ou décalage vers la gauche à d'autres projets, où nous anticipons que la réutilisation par l’équipe de vérification, des modèles et des environnements de test Simulink associés, permettra d'économiser deux mois supplémentaires d’efforts de développement sur des projets de complexité moyenne chez Allegro. À l’avenir, nous explorons également les opportunités pour nos équipes d’ingénierie système et nos clients de réutiliser les modèles.