Création de cas de test au niveau IP qui peuvent être réutilisés au niveau SoC

Il peut y avoir plusieurs raisons qui peuvent bloquer les cas de test à exécuter, cela peut être dû au fait que l'environnement de test n'est pas prêt ou qu'il y a un échec ailleurs qui nous empêche d'exécuter le cas de test. L'élément bloquant ici est le flux basé sur C - Pour le processeur, le code hexadécimal est requis et nous le générons à l'aide d'un fichier C alors que la vérification du niveau IP est généralement basée sur SV-UVM. Mais est-il trop facile de réutiliser des cas de test de niveau IP au niveau de la conception du SoC? Oui, c'est ce que nous allons discuter.

En règle générale, nous consacrons beaucoup d'efforts à la création de cas de test aléatoires de contraintes au niveau de la vérification au niveau IP, mais ils ne sont pas réutilisés au niveau du SoC. Comment pouvons-nous utiliser les cas de test de niveau IP au niveau SoC avec des efforts supplémentaires mineurs lors de la création de cas de test à la vérification au niveau IP elle-même.

Voyons d'abord le flux de cas de test de niveau SoC basé sur le processeur.

Vous aurez deux fichiers dans votre scénario de test de niveau SoC. ie C et System Verilog (.SV référencé désormais dans cet article). Dans le fichier C, nous écrivons des registres conditionnels / inconditionnels en écriture / lecture sur n'importe quelle adresse IP du développement SoC.

Du côté SV, nous pourrions avoir beaucoup de code basé sur UVM pour vérifier la fonctionnalité de l'IP comme la création de paquets à partir de / pour VIP, séquences de démarrage, etc. Dans les cas de test de niveau IP, nous avons généralement un fichier.ie «.SV». Dans ce fichier «.SV», nous aurons à la fois des registres d'écriture / lecture et du code basé sur UVM comme des séquences de démarrage.

L'idée est de créer un flux dans lequel nous pouvons séparer le registre d'écriture / lecture et d'autres codes basés sur UVM dans deux fichiers / classes «.SV» différents dans les cas de test de niveau IP. Des fichiers séparés peuvent être créés pour le code d'écriture / lecture de registre (identique au code «.C» dans la vérification basée sur l'UC) et le reste du code UVM (identique au code «.SV» dans la vérification basée sur l'UC).

Si nous avons déjà ces deux fichiers séparés dans le cas de test au niveau IP lui-même, nous pouvons convertir le fichier qui contient le code d'écriture / lecture du registre en fichier C en utilisant simplement un simple script Perl. Ces deux «.SV» classés peuvent être exécutés en tant que threads parallèles lors de l'exécution du scénario de test.

Prenons l'exemple de test ci-dessous.

L'exemple de cas de test mentionné ci-dessus est ce que nous faisons généralement dans les cas de test de niveau IP.

Nous voulons maintenant réorganiser ce cas de test de niveau IP afin qu'il puisse également être utilisé au niveau SoC sans aucune modification / effort significatif. Nous y parviendrons en créant deux fichiers «.SV» séparés comme discuté initialement avec un fichier contenant des informations d'écriture / lecture de registre et d'autres liées à la séquence VIP de l'exemple ci-dessus.

L'organigramme ci-dessous décrit la communication entre le côté c et «.sv» à l'aide de sync_method.

sync_method est requis à Conception de niveau SoC parce que vous avez besoin d'un mécanisme qui fournit un contrôle de synchronisation d'exécution pour effectuer certaines écritures / lectures de registre à partir du processeur (qui est dans le fichier C), c'est-à-dire

Dans l'exemple ci-dessus, nous configurons d'abord les registres IP du contrôleur I2C à partir du fichier C, puis nous passons le contrôle au côté «.SV» pour démarrer la séquence VIP (c'est-à-dire que nous ne pouvons pas commencer la séquence VIP à 0 heure car la configuration du contrôleur n'est pas encore terminée) en utilisant sync_method.

De même, nous passons le contrôle du côté «.SV» au fichier C en utilisant sync_method une fois la séquence VIP terminée. Dans le fichier C, nous pouvons vérifier la valeur du registre d'état de l'IP du contrôleur (vérification de l'état).

La logique de sync_method () utilisée dans l'exemple de test ci-dessus est hors de la portée de cet article.

Nous pouvons utiliser ce flux de test dans les cas de test de niveau IP, puis lorsque nous le migrons vers la vérification de niveau SoC, et les mêmes cas de test peuvent être réutilisés en convertissant simplement le fichier SV (qui contient le code d'écriture / lecture du registre) en fichier C en utilisant Perl simple scénario.

Conclusion

C'est ainsi que nous pouvons créer les cas de test de niveau IP qui peuvent être réutilisés au niveau de la conception de niveau SOC, ce qui peut effectivement économiser environ 30% à 70% du temps que nous avons passé à créer des cas de test SOC en fonction de la complexité du protocole et du cas de test. Chez eInfochips, nous fournissons des services de conception de SoC de bout en bout sur tout le flux de conception de produits connectés, du conseil de test et de la mise en œuvre au support des tests de fin de vie, garantissant une qualité de produit élevée, l'excellence opérationnelle et l'agilité. Nous connecter aujourd'hui pour en savoir plus sur nos services d'ingénierie silicium.

Source : https://www.einfochips.com/blog/creating-ip-level-test-cases-which-can-be-reused-at-soc-level/