Comment créer un banc d'essai d'auto-vérification

Les deux dernières lignes de code du processus permettent de terminer le test en douceur. Le texte "Test :OK" est imprimé sur la console, puis la simulation est arrêtée en utilisant le mot clé VHDL-2008 "finish".

Notez que si vous exécutez ModelSim avec le bouton Exécuter par défaut, ModelSim vous invitera avec la boîte de dialogue Quitter une fois le banc d'essai terminé avec succès. Ce comportement peut être modifié lors du lancement de Vsim à partir d'un script ou de la ligne de commande. Ajoutez le commutateur "-onfinish stop" à la commande Vsim, comme décrit dans la référence de commande ModelSim.

Vérification de la sortie

Maintenant, nous alimentons le DUT avec des entrées, mais il n'y a aucune vérification de la sortie. Le testbench affichera "Test :OK", que la sortie soit correcte ou non. Faisons quelque chose à ce sujet.

Lors de la création d'un algorithme de vérification, vous devez toujours essayer d'implémenter le test différemment que dans le DUT. Sinon, une faille fondamentale dans la logique peut passer inaperçue car elle est présente dans le DUT ainsi que dans l'algorithme du banc de test.

Suivant ce principe, nous allons tester la sortie du DUT non pas en vérifiant que le code Gray est correct, mais plutôt qu'un seul bit change d'un nombre au suivant. Après tout, c'est toute la raison d'utiliser le code Gray en premier lieu. Le code ci-dessous montre un processus qui effectue ce type de vérification.

PROC_CHECKER : process
    variable prev : std_logic_vector(gray'range);
    variable count : integer;
begin
  wait on bin;

  prev := gray;

  -- Wait for all delta cycles to propagate
  wait for 1 ns;
  
  -- Count the number of changed bits
  count := 0;
  for i in gray'range loop
    if gray(i) /= prev(i) then
      count := count + 1;
    end if;
  end loop;

  assert count = 1
    report integer'image(count) & " bits changed, should have been 1"
    severity failure;
  
end process;

Le processus est sensible au bin signal, l'entrée du DUT. Nous aurions pu utiliser une liste de sensibilité avec le même résultat, mais je préfère utiliser uniquement les instructions Wait dans le code de testbench. C'est une convention qui permet de savoir facilement si vous avez affaire à un testbench ou à un module RTL simplement en regardant comment le code est écrit.

Sur la ligne des secondes, nous copions la sortie DUT précédente. N'oubliez pas qu'il s'agit du premier delta-cycle après le bin le signal a changé et le DUT ne peut pas encore réagir. Ainsi, il est prudent de copier la sortie DUT en supposant qu'il s'agit de l'ancienne valeur.

Ensuite, nous attendons 1 nanoseconde pour permettre à toute la logique combinatoire du DUT de se terminer. Maintenant, la sortie du DUT devrait être stable et nous pouvons examiner sa valeur en toute sécurité.

Dans le morceau de code suivant, nous utilisons une boucle For pour compter le nombre de bits modifiés sur la sortie du DUT.

Enfin, vient l'instruction Assert qui vérifie que le nombre de bits modifiés est exactement 1. Les instructions Assert fonctionnent en vérifiant la condition, qui dans ce cas est count = 1 . Si la condition est évaluée à false , une assertion sera générée et le simulateur s'arrêtera avant que le message "Test :OK" ne soit imprimé.

Il est sage d'inclure l'instruction report facultative avec l'instruction assert. Ce texte sera imprimé si l'assertion échoue. Dans notre exemple, je fournis une brève explication de l'événement qui a provoqué l'échec du testbench.

Exécuter le banc d'essai

Il est temps d'exécuter notre testbench pour vérifier que le DUT fonctionne correctement. Après avoir démarré la simulation dans ModelSim et appuyé sur le bouton "run -all", nous voyons que le message "Test :OK" est imprimé sur la console.

VSIM 1> run -all
# ** Note: Test: OK
#    Time: 170 ns  Iteration: 0  Instance: /gray_converter_tb

Tester le banc d'essai

J'aime toujours créer une condition d'échec dans le DUT juste pour voir que le testbench fonctionne. Parfois, cela vient naturellement en raison d'erreurs réelles dans le DUT pendant que vous le développez. Mais si ce n'est pas le cas, créez simplement une erreur brièvement pour tester le testbench.

Pour ce faire, je vais éditer le code DUT pour créer une erreur bloquée à 0 sur le bit numéro 3. Après ce test, je supprimerai l'erreur en sachant que le testbench est capable de détecter de telles erreurs. Le code ci-dessous montre le processus DUT avec la ligne de code supplémentaire.

process(bin) is
begin
  gray(gray'high) <= bin(bin'high);

  for i in bin'high - 1 downto bin'low loop
    gray(i) <= bin(i + 1) xor bin(i);
  end loop;

  -- Emulate a stuck at zero error
  gray(3) <= '0';

end process;

Lorsque nous exécutons le testbench maintenant, nous pouvons voir que le testbench s'arrête et que l'erreur est imprimée avant que la ligne "Test :OK" ne soit atteinte. La transcription de la console ModelSim est présentée ci-dessous.

VSIM 2> run -all
# ** Failure: 0 bits changed, should have been 1
#    Time: 81 ns  Iteration: 0
Process: /gray_converter_tb/PROC_CHECKER File: gray_converter_tb.vhd
# Break in Process PROC_CHECKER at ray_converter_tb.vhd line 61

Démarrer avec les bancs de test d'auto-vérification

Vous devriez être en mesure de créer un banc d'essai d'auto-vérification en utilisant ce que vous avez appris dans cet article. Prenez l'habitude de toujours créer des bancs d'essai autovérifiés pour tous vos modules VHDL. Cela vous fera gagner du temps à long terme.

Il est normal d'être créatif lors de l'écriture de bancs d'essai. Plus que lors de l'écriture de modules RTL car toutes les constructions VHDL ne peuvent pas être synthétisées, mais le testbench n'a pas besoin d'être synthétisable. Attendez-vous à passer au moins autant de temps à écrire des tests qu'à écrire le DUT.

Si vous voulez vous lancer sérieusement dans les tests, vous pourriez être intéressé par mon * prochain cours VHDL et FPGA. Dans le cours, je vous guiderai à travers le processus de conception complet, de l'idée au prototype de FPGA fonctionnel. Nous allons créer plusieurs bancs d'essai autovérifiés.

Mise à jour le 12 octobre 2020 : J'ai terminé le cours. Cliquez sur l'image ci-dessous pour en savoir plus.

Je vais vous enseigner les meilleures pratiques pour créer avec succès des conceptions VHDL et FPGA de la bonne manière. Les connaissances que j'ai acquises au cours de nombreuses années dans le milieu universitaire et après avoir travaillé comme ingénieur matériel dans l'industrie de la défense vous seront transmises.

En savoir plus sur le cours Dot Matrix VHDL et FPGA ici !

Ouvre :

À déterminer .