Accélération de la vérification des circuits intégrés de traitement du signal avec HDL Verifier

La vérification des designs de circuits intégrés (CI) de traitement du signal pose plusieurs défis uniques qui peuvent mettre à rude épreuve les méthodes de test conventionnelles. La complexité algorithmique des filtres, des mélangeurs et d'autres fonctions avancées de traitement du signal nécessite une validation rigoureuse pour garantir que le circuit intégré implémenté se comporte comme prévu, avec une précision au bit près. De plus, étant donné que les circuits intégrés fonctionnent souvent sur une large gamme d’entrées et de configurations possibles, il est essentiel d’évaluer les cas particuliers, c’est-à-dire des scénarios rares mais critiques, qui peuvent échapper aux plans de test axés sur des séquences prédéfinies et prévisibles.

Mon équipe chez NXP a adopté un nouveau workflow pour la vérification des circuits intégrés afin de relever ces défis. Basé sur MATLAB^®, Simulink^®, et HDL Verifier™, ce workflow intègre des techniques de vérification aléatoire contrainte (CRV) et de méthodologie de vérification universelle (UVM) pour valider les cas limites et explorer l'espace d'état avec des entrées aléatoires tout en maintenant le contrôle grâce à des contraintes (Figure 1). Dans ce workflow, que nous avons récemment utilisé pour vérifier un circuit intégré de tuner radio pour l'industrie automobile, les modèles MATLAB et Simulink sont exportés sous forme de composants SystemVerilog DPI-C à l'aide de HDL Verifier et intégrés comme modèles de référence dans le banc d'essai de vérification pour notre environnement de vérification basé sur un simulateur Xcelium™ de Cadence^®. Cette approche nous a non seulement permis de réduire le temps de vérification de 20 à 30 %, mais elle nous a également permis d’augmenter la couverture de test et de trouver davantage de défauts d’implémentation plus tôt dans le développement.

Comparaison des anciens et des nouveaux workflows

Précédemment, lors des tests de designs de circuits intégrés similaires, nous utilisions généralement MATLAB pour générer des stimuli d'entrée pour notre système complet. Nous exécutions ensuite des simulations dans MATLAB ou Simulink et capturions les résultats sous forme de modèle de référence. Une fois l’implémentation RTL terminée, nous appliquions les mêmes stimuli au DUT et vérifiions ses résultats par rapport au modèle de référence. Bien que cette approche ait fonctionné, elle présentait quelques inconvénients. Premièrement, la vérification était faite, pour la plupart, de bout en bout, ce qui rendait difficile l’identification de la cause profonde des défauts puisque tous les composants étaient testés ensemble. Deuxièmement, il n’était pas facile d’effectuer une vérification aléatoire contrainte. Par conséquent, si des scénarios et des cas d’utilisation courants étaient vérifiés, de nombreux cas limites ne l’étaient pas. Troisièmement, cette approche n’adhérait pas à l’UVM, qui est depuis devenu le cadre standard dans notre façon de mettre en œuvre des bancs d’essai.

Désormais, le nouveau workflow permet la réutilisation directe de nos modèles de référence MATLAB et Simulink existants dans notre environnement de simulation HDL (Cadence Xcelium). Chaque composant du modèle de référence correspond à son homologue dans le DUT. L'exemple de chaîne de traitement du signal illustré dans la figure 2 comprend par exemple un filtre modélisé dans Simulink, suivi d'un mélangeur et d'un deuxième filtre modélisé dans MATLAB. Nous utilisons HDL Verifier pour générer du code C pour le modèle avec le wrapper SystemVerilog DPI-C, nous permettant d'intégrer chaque composant dans le banc de test.

Les composants du modèle de référence et les composants DUT sont exécutés en parallèle dans l'environnement de simulation HDL, et leurs sorties sont évaluées en temps réel par un vérificateur qui agit comme un tableau de bord UVM, effectuant des comparaisons précises au bit près de la sortie de chaque paire de composants associée (par exemple, le mélangeur du modèle de référence et le mélangeur DUT) ainsi que de toute la chaîne de bout en bout.

Randomisation des entrées et visualisation des résultats

Après avoir exécuté des tests préliminaires (dans ce cas avec un ensemble de flux radio AM, FM et DAB prédéfinis) sur le banc d'essai pour vérifier la fonctionnalité de base des algorithmes de traitement du signal, l'étape suivante du workflow est la vérification aléatoire contrainte. Cette étape implique des simulations approfondies dans lesquelles, des valeurs aléatoires sont attribuées à tous les paramètres de configuration du design, dans une plage limitée. Par exemple, nous modifions les paramètres du mixeur, les paramètres du filtre, les délais, les gains et d’autres paramètres de configuration clés et exécutons des simulations pour évaluer la performance du design pour chaque ensemble d’options de configuration aléatoire.

Pour chaque test, nous pouvons examiner les résultats détaillés, y compris les paramètres spécifiques qui ont été utilisés, les entrées utilisées comme stimuli pour l'IP, les résultats de l'implémentation du modèle de référence, les résultats de l'implémentation RTL et le résultat de la comparaison du vérificateur (Figure 3).

Nous examinons également les rapports présentant les résultats agrégés pour une série complète de composants (Figure 4). Ces rapports indiquent le nombre de vérifications effectuées pour chaque composant de la chaîne et le nombre d’erreurs, c’est-à-dire le nombre d’écarts identifiés entre les sorties RTL et les sorties du modèle de référence.

Lorsqu'une erreur est identifiée, nous vérifions à la fois l'implémentation du modèle de référence dans MATLAB ou Simulink, et nous vérifions l'implémentation RTL. Dans certains cas, nous avons identifié la source de l'écart dans le design de référence d'origine, mais le problème provient le plus souvent d'une erreur d'implémentation RTL. Dans les deux cas, une fois le défaut diagnostiqué et corrigé, nous réexécutons les simulations de test pour vérifier que le correctif a complètement résolu les différences entre le modèle de référence et l'implémentation RTL.

Principales améliorations et prochaines étapes

L’un des avantages évidents de notre nouveau workflow basé sur HDL Verifier est la possibilité d’identifier rapidement la source des défauts. Par rapport à une approche qui repose sur des tests de bout en bout, une approche orientée UVM qui permet des tests au niveau des composants et au niveau du système, comme celle que nous avons appliquée, facilite grandement l'identification du sous-système présentant le défaut ainsi que des stimuli spécifiques pour ce composant qui peuvent être utilisés pour reproduire le défaut.

De plus, étant donné que les paramètres aléatoires testent souvent le système d’une manière que les ingénieurs concepteurs n’auraient pas anticipée, le nouveau workflow facilite la découverte des défauts d’implémentation beaucoup plus tôt dans le processus de développement, par rapport aux plans de test conventionnels axés sur des cas d’utilisation bien établis. En bref, nous pouvons trouver des défauts sans vérifications manuelles et sans investir trop de temps à réfléchir à des scénarios inhabituels et à des cas limites à tester.

Nous sommes en mesure de réutiliser nos modèles MATLAB et Simulink existants dans des simulations HDL et les avantages de cette réutilisation continuent de croître à chaque rotation ou révision ultérieure du circuit intégré. En combinant ces avantages, nous avons pu réduire de manière significative le temps de vérification, atteignant jusqu’à 30 % de gain lors du développement du circuit intégré de traitement du signal radio. Sur la base de ce gain de temps et des autres avantages que nous avons obtenus, d’autres équipes NXP cherchent à adopter le même workflow pour le développement d’un frontal radio pour un circuit intégré radar et d’autres designs de circuits intégrés.