La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

INF3500 : Conception et implémentation de systèmes numériques Pierre Langlois Cours #7 Vérification.

Présentations similaires


Présentation au sujet: "INF3500 : Conception et implémentation de systèmes numériques Pierre Langlois Cours #7 Vérification."— Transcription de la présentation:

1 INF3500 : Conception et implémentation de systèmes numériques Pierre Langlois Cours #7 Vérification dun modèle VHDL

2 INF3500 : Conception et implémentation de systèmes numériques Plan pour aujourdhui Introduction: retour sur la vérification avec un banc dessai: sections 7.1 à 7.10 Élaboration dun plan de test: section 7.11 Composition dun ensemble de vecteurs de test: section 7.12 – tests de boîte noire – tests de boîte blanche Concepts avancés: section Des parenthèses sur VHDL, des précisions sur les notes de cours, des trucs pour utiliser Active-HDL, et des exemples!

3 INF3500 : Conception et implémentation de systèmes numériques Flot de conception de circuits numériques 3 (notes, section 4.2)

4 INF3500 : Conception et implémentation de systèmes numériques Vérification: concepts fondamentaux La vérification est un processus par lequel on vérifie quun design rencontre bien ses spécifications. La vérification complète dun circuit est normalement un problème très difficile. Dans lindustrie de la conception numérique, on considère en général que le processus de vérification nécessite autant defforts que le processus de conception lui-même. La vérification dun circuit est un art qui repose sur la maîtrise de trois principes: – la compréhension de la spécification; – le contrôle des entrées et de signaux internes du circuit à vérifier; et, – lobservation des sorties, des signaux internes et de létat du circuit à vérifier. 4 (notes, section 7.1)

5 INF3500 : Conception et implémentation de systèmes numériques Vérification par banc dessai Un banc dessai permet dappliquer des vecteurs de test à un circuit et dobserver sa sortie dans le but de vérifier quil rencontre ses spécifications. Un banc dessai doit effectuer les tâches suivantes : – instancier le circuit à vérifier; – générer des vecteurs de test et les appliquer aux ports dentrée du circuit; – [utile]: générer automatiquement des réponses attendues aux vecteurs de test; – [utile]: comparer les réponses du circuit aux réponses attendues, et indiquer toute différence entre les deux par une condition derreur. – (pour circuit séquentiel): générer un signal dhorloge et un signal de réinitialisation 5 (notes, section 7.2 et 7.10)

6 INF3500 : Conception et implémentation de systèmes numériques Vecteurs de test encodés dans un tableau de constantes 6 nouveau type: tableau de std_logic_vector de 3 éléments application de tous les vecteurs architecture arch2 of add3bitsTB is component add3bits -- déclaration du module à vérifier port (Cin, X, Y : in std_logic; Cout, S : out std_logic); end component; -- signaux pour les vecteurs de tests signal Cin, X, Y : std_logic; -- signaux pour les réponses signal Cout, S : std_logic; type tableauSLV3 is array (natural range <>) of std_logic_vector(2 downto 0); constant vecteurs : tableauSLV3 := ("000", "001", "010", "011", "100", "101", "110", "111"); begin -- instanciation du module à vérifier UUT : add3bits port map (Cin, X, Y, Cout, S); process -- application des vecteurs de test emmagasinés dans le tableau begin for k in vecteurs'low to vecteurs'high loop (Cin, Y, X) <= vecteurs(k); wait for 10 ns; end loop; end process; end arch2; déclaration dune constante contenant les vecteurs de test Ici on peut faire un test exhaustif, mais quelles valeurs placer dans le tableau des constantes en général? (notes, section 7.4)

7 INF3500 : Conception et implémentation de systèmes numériques Vérification exhaustive à laide dune boucle Pour un circuit combinatoire, il est parfois possible de faire une vérification exhaustive. Au lieu dun tableau, on peut utiliser une boucle. 7 library ieee; use ieee.numeric_std.all; architecture arch3 of add3bitsTB is component add3bits -- déclaration du module à vérifier port (Cin, X, Y : in std_logic; Cout, S : out std_logic); end component; -- signaux pour les vecteurs de tests signal Cin, X, Y : std_logic; -- signaux pour les réponses signal Cout, S : std_logic; begin -- instanciation du module à vérifier UUT : add3bits port map (Cin, X, Y, Cout, S); process -- application exhaustive des vecteurs de test begin for k in 0 to 7 loop (Cin, Y, X) <= to_unsigned(k, 3); wait for 10 ns; end loop; end process; end arch3; (notes, section 7.5.1) La vérification exhaustive nest pas toujours possible.

8 INF3500 : Conception et implémentation de systèmes numériques Un test pseudo-aléatoire peut venir compléter un test plus dirigé. library ieee; use ieee.numeric_std.all; use ieee.math_real.all; architecture arch4 of add3bitstb is … -- comme précédemment begin -- instanciation du module à vérifier UUT : add3bits port map (Cin, X, Y, Cout, S); process -- génération aléatoire de vecteurs de test variable seed1 : positive := 1; variable seed2 : positive := 2; variable aleatoire : real; variable t : integer := -1; begin uniform(seed1, seed2, aleatoire); < aleatoire < 1.0 aleatoire := floor(aleatoire * 8.0); <= aleatoire <= 7.0 t := integer(aleatoire); -- 0 <= t <= 7 (Cin, Y, X) <= to_unsigned(t, 3); wait for 10 ns; end process; end arch4; Vérification pseudo-aléatoire 8 (notes, section 7.5.2) Un test pseudo-aélatoire peut être intéressant, mais il ne permet pas par lui-même de savoir à quel point le circuit a été vérifié.

9 INF3500 : Conception et implémentation de systèmes numériques Vérification dun circuit séquentiel 9 (notes, section 7.10) library ieee; use ieee.std_logic_1164.all; use std.textio.all; entity cctsequentielex1TB is end cctsequentielex1TB; architecture arch1a of cctsequentielex1TB is signal reset : std_logic := '0'; signal clk : std_logic := '0'; signal X : std_logic := 'X'; signal Z : std_logic := 'X'; constant periode : time := 10 ns; begin clk <= not clk after periode / 2; reset <= '0' after 0 ns, '1' after periode / 4; UUT : entity cctsequentielex1(arch2) port map (reset, clk, X, Z); process (clk) constant vecteurX : std_logic_vector := " "; variable compte : natural range 0 to vecteurX'length := 0; variable tampon : line; -- pointeur vers objet de type string begin if (falling_edge(clk)) then -- *** front différent de l'UUT *** write(tampon, "temps: "); write(tampon, now, unit => ns); write(tampon, ", x: " & std_logic'image(x)); write(tampon, ", z: " & std_logic'image(z)); write(tampon, ", compte: " & integer'image(compte)); writeline(output, tampon); -- écriture à la console if compte = vecteurX'length then report "simulation terminée" severity failure; else X <= vecteurX(compte); compte := compte + 1; end if; end process; end arch1a; A B Comment savoir si le circuit a été adéquatement vérifié? Toutes les transitions possibles entre les états ont-elles été testées au moins une fois? Y a-t-il dautres critères à vérifier? Pour un circuit séquentiel, « vérification exhaustive » veut dire: pour chaque état, appliquer chaque entrée possible.

10 INF3500 : Conception et implémentation de systèmes numériques Plan pour aujourdhui Introduction: retour sur la vérification avec un banc dessai: sections 7.1 à 7.10 Élaboration dun plan de test: section 7.11 Composition dun ensemble de vecteurs de test: section 7.12 – tests de boîte noire – tests de boîte blanche Concepts avancés: section Des parenthèses sur VHDL, des précisions sur les notes de cours, des trucs pour utiliser Active-HDL, et des exemples!

11 INF3500 : Conception et implémentation de systèmes numériques Élaboration dun plan de test Un plan de test est un document qui détaille la stratégie employée pour effectuer la vérification dun système. La complexité et le niveau de détail dun plan de test dépendent de la taille du module, circuit, sous-système ou système à vérifier. Un plan de test complet pourrait entre autres détailler: – la couverture du test: quels requis de la spécification doivent être vérifiés par le test? – les méthodes de test: comment le système sera-t-il vérifié? quelles sont les conditions de réussite et déchec des cas de test? – les responsabilités de test: qui est responsable de quels tests? Un plan de test sommaire peut être élaboré en trois étapes : 1.Extraire les fonctionnalités requises du système à partir de ses spécifications; 2.Prioriser les fonctionnalités à vérifier; et, 3.Créer des vecteurs de test. 11 (notes, section 7.11)

12 INF3500 : Conception et implémentation de systèmes numériques Élaboration dun plan de test 1. Extraire les fonctionnalités requises du système La spécification architecturale décrit linterface du système avec le monde extérieur et ses relations dentrées et sortie. La spécification architecturale ne spécifie pas comment le comportement interne du système doit être réalisé. Il est difficile dextraire toutes les fonctionnalités requises à partir de la spécification. Il est encore plus difficile dautomatiser cette extraction. Certaines fonctionnalités sont implicites. Dautres fonctionnalités ou comportements ne doivent pas être présents. 12 (notes, section 7.11) Concevoir et décrire une file d'attente en VHDL. Le nombre maximum d'éléments dans la file et la largeur des données en bits doivent être paramétrables. Un signal d'horloge synchronise toutes les activités de la file. Le signal reset permet de vider la file. Les ports din et dout sont respectivement l'entrée et la sortie de la file. Les ports empty et full indiquent respectivement que la file est vide ou bien qu'elle est pleine. Quand le signal wr_en (write enable) est activé, la valeur placée sur le port din sera insérée dans la file lors de la prochaine transition active du signal d'horloge clk. Quand le signal rd_en (read enable) est activé, la valeur qui est dans la file depuis le plus longtemps sera placée sur le port dout lors de la prochaine transition active du signal d'horloge clk. Il doit être possible d'écrire une nouvelle valeur dans la file et de lire la valeur la plus ancienne simultanément. Quand la file est pleine, le signal wr_en n'a aucun effet - il n'est pas possible d'écrire par dessus le contenu présent de la file. Quand la file est vide, le signal rd_en n'a aucun effet. Il doit être possible d'écrire une nouvelle valeur dans la file et de lire la valeur la plus ancienne simultanément.

13 INF3500 : Conception et implémentation de systèmes numériques Élaboration dun plan de test 1. Extraire les fonctionnalités requises du système Exemple pour une unité de file dattente (FIFO). 13 (notes, section 7.11) Quatre catégories de fonctionnalités à vérifierExemple de fonctionnalité Il est possible de placer le système dans son état de départ valide à partir de nimporte quel état. Retour à létat de départ quand le signal reset est activé. À partir dun état valide et étant donnée une entrée valide, le système doit se placer dans le bon état valide. Écriture dans la file (quand la file nest pas pleine). À partir dun état valide et étant donnée une entrée valide, le système ne doit pas se placer dans un état non valide ou un état incorrect. À partir dun état valide et étant donnée une entrée non valide, le système ne doit pas se placer dans un état non valide ou un état incorrect. Écriture dans la file (quand la file est pleine).

14 INF3500 : Conception et implémentation de systèmes numériques Élaboration dun plan de test 2. Prioriser les fonctionnalités à vérifier Il y a souvent une très grande quantité de fonctionnalités à vérifier. Il peut être utile de les placer en ordre de priorité. 1.Les fonctionnalités qui correspondent à des contraintes de sécurité devraient être considérées en premier. 2.Les fonctionnalités qui correspondent à des besoins fondamentaux du système identifiés dans les spécifications devraient être vérifiées de façon prioritaire. 3.Les fonctionnalités qui faciliteraient lutilisation du système peuvent avoir une priorité plus faible. 4.Enfin, les fonctionnalités facultatives ou futures du système peuvent avoir une priorité encore plus faible. 14 (notes, section 7.11)

15 INF3500 : Conception et implémentation de systèmes numériques Élaboration dun plan de test 3. Créer un ensemble de vecteurs de test On crée un ensemble de vecteurs de test pour chaque fonctionnalité à vérifier. Il faut établir comment vérifier la fonctionnalité et comment établir quelle est satisfaite ou non à partir des signaux du système. On détermine les vecteurs de test spécifiques qui permettent de stimuler la fonctionnalité désirée. Pour aider au processus de création des vecteurs de test, il est nécessaire de bien documenter chaque étape. 15 (notes, section 7.11)

16 INF3500 : Conception et implémentation de systèmes numériques Élaboration dun plan de test 3. Créer un ensemble de vecteurs de test Par exemple, le plan de test peut comporter un tableau dans lequel on identifie les fonctionnalités à vérifier ainsi que leur priorité, assigner une personne responsable et suivre leur statut dans le temps : en développement, débutée, écrite, appliquée, révisée, etc. 16 (notes, section 7.11) FonctionnalitéPrioritéResponsableStatut de la tâche 1. Réinitialisation1ArmandAssignée 2. Écrire dans la pile2ArmandÉcrite 3. Lire de la pile2AsmaÉcrite 4. Écriture et lecture simultanées2AlexisEn dév. 5. Pile pleine a.Fonctionnement du signal full b.Écriture impossible 2AlexisEn dév. 6. Pile vide a.Fonctionnement du signal empty b.Lecture impossible 2ArmandAssignée 7. Signaux overflow et underflow4ArmandAssignée

17 INF3500 : Conception et implémentation de systèmes numériques Plan pour aujourdhui Introduction: retour sur la vérification avec un banc dessai: sections 7.1 à 7.10 Élaboration dun plan de test: section 7.11 Composition dun ensemble de vecteurs de test: section 7.12 – tests de boîte noire – tests de boîte blanche Concepts avancés: section Des parenthèses sur VHDL, des précisions sur les notes de cours, des trucs pour utiliser Active-HDL, et des exemples!

18 INF3500 : Conception et implémentation de systèmes numériques Cinq qualités dun bon ensemble de vecteurs de test Le problème de la création dun ensemble de vecteurs de test nest pas simple. Les vecteurs de test choisis doivent permettre de vérifier que le circuit rencontre ses spécifications. Les cinq qualités principales dun bon ensemble de vecteurs de test sont: – Efficace pour découvrir des bogues, cest-à-dire que chaque vecteur de test vérifie plusieurs fonctionnalités en même temps, et donc que peu de vecteurs de tests sont nécessaires. – Identifie la source des bogues, pour aider à leur éradication. – Reproductible, donc il est facile de recréer le bogue. – Automatisé à laide dun banc dessai. – Exécutable dans un temps raisonnable. dépend de la taille et de la complexité du circuit et de lampleur du projet 18 (notes, section ) Laboratoire de 3 heures: quelques minutes Projet intégrateur: de plusieurs minutes à quelques heures Système de grande envergure: de plusieurs heures à quelques jours

19 INF3500 : Conception et implémentation de systèmes numériques Le test exhaustif Les tests exhaustifs permettent dobserver le comportement du circuit pour toutes les conditions possibles dentrée. En pratique il est impossible deffectuer un test exhaustif dans un temps raisonnable. Pour un circuit combinatoire avec M entrées, il faut 2 M vecteurs de test. Pour un circuit combinatoire avec: – N bascules, S = 2 N états, et – M entrées, R = 2 M transitions possibles à partir de chaque état, il faudrait prévoir 2 N + M vecteurs de test différents juste pour effectuer toutes les transitions possibles du système au moins une fois. 19 (notes, section )

20 INF3500 : Conception et implémentation de systèmes numériques Exemple: conversion de secondes 20 Combien de vecteurs de test sont nécessaires pour un test exhaustif? library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; entity convSecondes is port ( secondesIn : in unsigned(7 downto 0); minutesOut : out unsigned(2 downto 0); secondesOut : out unsigned(5 downto 0) ); end convSecondes;

21 INF3500 : Conception et implémentation de systèmes numériques Exemple: conversion de couleurs de RGB à CMYK Les images sont habituellement encodées dans lespace à trois dimensions RGB. Une imprimante utilise plutôt lespace CMY: cyan (C), magenta (M) et jaune (Y), les couleurs complémentaires de rouge, vert et bleu. Les équations de conversion, pour des valeurs exprimées sur 8 bits, sont: C = 255 – R; M = 255 – G; Y = 255 – B 21 A. Stodghill, Tip oday: ask for a a refill, Green Options, 2007/06/18. Consulté le 4 septembre 2009, tiré de

22 INF3500 : Conception et implémentation de systèmes numériques Exemple: conversion de couleurs de RGB à CMYK 22 Combien de vecteurs de test sont nécessaires pour un test exhaustif? library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; entity convRGB2CMYK is port ( rouge, vert, bleu : in unsigned(7 downto 0); cyan, magenta, jaune, noir : out unsigned(7 downto 0) ); end convRGB2CMYK;

23 INF3500 : Conception et implémentation de systèmes numériques Exemple: machine à états 23 Combien de vecteurs de test sont nécessaires pour un test exhaustif? Quelles informations sont nécessaires pour déterminer le nombre de vecteurs de tests? library IEEE; use IEEE.std_logic_1164.all; entity machineAEtats is port ( reset, CLK : in STD_LOGIC; x : in STD_LOGIC_VECTOR(1 downto 0); sortie : out STD_LOGIC ); end machineAEtats; architecture arch of machineAEtats is type type_etat is (S1, S2, S3, S4); signal etat : type_etat := S1; begin …

24 INF3500 : Conception et implémentation de systèmes numériques Exemple: joueur de blackjack Description du jeu de base Le jeu oppose des joueurs à un croupier qui joue pour le compte de la banque. Le but du jeu est daccumuler plus de points que la banque sans dépasser 21. Les cartes ont les valeurs suivantes : – les cartes numérotées ont leur propre valeur (2 à 10); – les figures valent 10; et, – las peut valoir 1 ou 11, selon ce qui est le plus avantageux – une main contenant un as qui peut prendre une des deux valeurs est dite facile. Le croupier distribue deux cartes visibles à chaque joueur, puis se donne une carte visible et une carte cachée. Chaque joueur peut alors tirer une carte ou arrêter, de façon à obtenir la meilleure main possible. Finalement, le croupier révèle sa carte cachée et tire sur un total de 16 ou moins. Un joueur gagne sa mise si sa main est meilleure que celle du croupier. Il récupère sa mise si sa main est égale à celle du croupier. Il perd sa mise si son total est supérieur à 21 ou inférieur au total du croupier. 24 (notes, section 6.7)

25 INF3500 : Conception et implémentation de systèmes numériques Exemple: joueur de blackjack 25 (notes, section 6.7) Combien de vecteurs de test sont nécessaires pour un test exhaustif? Quelles informations sont nécessaires pour déterminer le nombre de vecteurs de tests? library IEEE; use IEEE.std_logic_1164.all; entity blackjack is port ( clk: in std_logic; reset: in std_logic; carteValide : in std_logic; valeurCarte: in integer range 2 to 11; tirer: out std_logic; depasse: out std_logic; total: out integer range 0 to 31 ); end blackjack; architecture arch2 of blackjack is signal somme : integer range 0 to 31; signal calculeSomme : std_logic; signal initSomme : std_logic; signal moinsDix : std_logic; type type_etat is (depart, tire, ajoute, verifie, corrige, fini); signal etat : type_etat; …

26 INF3500 : Conception et implémentation de systèmes numériques Exemple: microprocesseur Combien de vecteurs de test sont nécessaires pour vérifier un microprocesseur de façon exhaustive? – Énoncez vos suppositions – Donnez un ordre de grandeur de la réponse – Estimez le temps nécessaire en supposant que vous pouvez appliquer un vecteur de test à chaque milliseconde. 26

27 INF3500 : Conception et implémentation de systèmes numériques Plan pour aujourdhui Introduction: retour sur la vérification avec un banc dessai: sections 7.1 à 7.10 Élaboration dun plan de test: section 7.11 Composition dun ensemble de vecteurs de test: section 7.12 – tests de boîte noire – tests de boîte blanche Concepts avancés: section Des parenthèses sur VHDL, des précisions sur les notes de cours, des trucs pour utiliser Active-HDL, et des exemples!

28 INF3500 : Conception et implémentation de systèmes numériques Tests de boîte noire (ou tests fonctionnels) Le terme « test de boîte noire » fait référence à un test qui ne suppose aucune connaissance de limplémentation du système. En anglais: black box, opaque box, closed box, functional test. Les tests de boîte noire sappuient uniquement sur les spécifications du système. Plus le système est complexe, et plus il faut utiliser ce genre de test. Il est difficile de déterminer à quel point le système a été vérifié par ce genre de test. Les tests de boîte noire ne permettent pas en général de découvrir des comportements non spécifiés du système. 28 (notes, section )

29 INF3500 : Conception et implémentation de systèmes numériques Vecteurs de test choisis par partitionnement en classes (test de boîte noire) 29 (notes, section )

30 INF3500 : Conception et implémentation de systèmes numériques Vecteurs de test choisis par partitionnement en classes (test de boîte noire) Lensemble des valeurs dentrée du système est partitionné en classes séparées. Le principe du partitionnement en classes sappuie sur la supposition suivante: – deux données dune même classe sont similaires et le comportement du système est semblable pour elles On doit choisir des données qui appartiennent à chacune des classes. – Un test faible consiste en un ensemble de vecteurs de tests où au moins un élément de chacune des classes serait présent au moins une fois. – Un test fort consiste en un ensemble de vecteurs de test où toutes les interactions entre les classes seraient présentes au moins une fois. Le nombre de vecteurs de test est alors égal au produit du nombre de classes pour chacune des entrées du système. 30 (notes, section )

31 INF3500 : Conception et implémentation de systèmes numériques Vecteurs de test choisis par partitionnement en classes (test de boîte noire) - exemple Un module dun chronomètre doit calculer la date du lendemain à la fin de la journée. On peut identifier les classes de données dentrée suivantes. – Pour les années : {année divisible par 4}, {année centenaire}, {autres années}. – Pour les mois : {mois de 30 jours}, {mois de 31 jours}, {mois de février}. – Pour les jours : {jour est entre 1 et 28}, {jour est 29}, {jour est 30}, {jour est 31}. Pour un test fort, on devrait choisir au moins un vecteur de test pour chacune des combinaisons de classes. – cas du mois de 31 jours avec les quatre classes de jour et les trois classes dannées. – cas du mois de février, le jour 31, lannée centenaire (pas valide). – etc. Il nest pas facile en général dénumérer toutes les classes de données possibles. La combinaison de vecteurs de test couvrant toutes les combinaisons de classes peut être très grande. 31 (notes, section )

32 INF3500 : Conception et implémentation de systèmes numériques Test faible - quatre vecteurs, un exemple: – {{classe 1-1}, {classe 2-1}, {classe 3-1}}, – {{classe 1-2}, {classe 2-2}, {classe 3-2}}, – {{classe 1-3}, {classe 2-1}, {classe 3-3}}, – {{classe 1-1}, {classe 2-1}, {classe 3-4}} Test fort - 24 vecteurs: – {{classe 1-1}, {classe 2-1}, {classe 3-1}}, – {{classe 1-1}, {classe 2-1}, {classe 3-2}}, – {{classe 1-1}, {classe 2-1}, {classe 3-3}}, – {{classe 1-1}, {classe 2-1}, {classe 3-4}}, – {{classe 1-1}, {classe 2-2}, {classe 3-1}}, – {{classe 1-1}, {classe 2-2}, {classe 3-2}}, – {{classe 1-1}, {classe 2-2}, {classe 3-3}}, – {{classe 1-1}, {classe 2-2}, {classe 3-4}}, – etc. Vecteurs de test choisis par partitionnement en classes (test de boîte noire) 32 (notes, section ) {classe i-j} : un élément de la classe i-j par exemple: {classe année-divisible par 4}: 1904 {classe mois-mois de 30 jours}: 4 (avril)

33 INF3500 : Conception et implémentation de systèmes numériques Vecteurs de test choisis par analyse des valeurs limites (test de boîte noire) Cette approche découle de lobservation que les erreurs se produisent souvent aux valeurs limites des données (exemple: débordement dune addition). On devrait inclure dans les vecteurs de test, pour chaque donnée, jusquà sept valeurs différentes: 33 (notes, section ) ValeurExemple pour le jour, mois de janvier Une valeur juste inférieure à la valeur minimale0 La valeur minimale1 Une valeur juste supérieure à la valeur minimale2 Une valeur nominale15 Une valeur juste inférieure à la valeur maximale30 La valeur maximale31 Une valeur juste supérieure à la valeur maximale32

34 INF3500 : Conception et implémentation de systèmes numériques Vecteurs de test choisis par analyse des valeurs limites (test de boîte noire) Vérifier toutes les combinaisons possibles des valeurs limites de chacune des variables: 7 n cas différents pour n variables. Si le nombre de variables est trop grand, on peut éliminer les valeurs interdites (sous le minimum et en haut du maximum) et on obtient alors 5 n cas différents. On peut encore réduire le nombre de combinaisons en fixant toutes les variables à leur valeur nominale, sauf une ou deux à la fois qui passent à travers leurs valeurs limites. 34 (notes, section ) y Espace des entrées possibles x Exemple pour deux variables x et y.

35 INF3500 : Conception et implémentation de systèmes numériques Exemple: conversion de couleurs de RGB à CMYK 35 Quels vecteurs de test choisir selon lanalyse des valeurs limites? - en version complète - en version réduite Comment ces ensembles se comparent-ils au test exhaustif? library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; entity convRGB2CMYK is port ( rouge, vert, bleu : in unsigned(7 downto 0); cyan, magenta, jaune, noir : out unsigned(7 downto 0) ); end convRGB2CMYK;

36 INF3500 : Conception et implémentation de systèmes numériques Vecteurs de test pseudo-aléatoires (test de boîte noire) Les vecteurs de test pseudo-aléatoires ont lavantage dêtre simples à générer. Ils peuvent compléter de façon intéressante un ensemble de vecteurs de tests composé avec une autre méthode. Quelques principes doivent être respectés pour les tests pseudo-aléatoires : – Il est utile de distinguer entre des valeurs valides et non valides appliquées au système, et sassurer de générer surtout des valeurs de test valides. – Le test doit être reproductible, donc il faut choisir des valeurs de graines connues (et non la valeur de lhorloge) pour lancer la génération des nombres pseudo-aléatoires. – Le test devrait avoir un objectif précis en restreignant les valeurs aléatoires générées à une seule classe. – La distribution des valeurs aléatoires devrait être connue et contrôlable pour correspondre aux conditions dopération du système. 36 (notes, section )

37 INF3500 : Conception et implémentation de systèmes numériques Plan pour aujourdhui Introduction: retour sur la vérification avec un banc dessai: sections 7.1 à 7.10 Élaboration dun plan de test: section 7.11 Composition dun ensemble de vecteurs de test: section 7.12 – tests de boîte noire – tests de boîte blanche Concepts avancés: section Des parenthèses sur VHDL, des précisions sur les notes de cours, des trucs pour utiliser Active-HDL, et des exemples!

38 INF3500 : Conception et implémentation de systèmes numériques Tests de boîte blanche (ou tests structurels) Le terme « test de boîte blanche » fait référence à un test qui nécessite de connaître le fonctionnement interne du système. En anglais: white box, glass box, clear box, structural test. En sappuyant sur des principes de couverture, on peut calculer des métriques permettant de déterminer à quel point le test a vérifié le système. Les tests de boîte blanche ne permettent pas en général de découvrir les fonctionnalités manquantes du système. 38 (notes, section )

39 INF3500 : Conception et implémentation de systèmes numériques Couverture de code (test de boîte blanche) Dans la couverture de code, on choisit des vecteurs de test pour exercer un élément particulier du design ou de sa description. Il y en a plusieurs : – Couverture dénoncés : pourcentage des énoncés du code exécutés. – Couverture de blocs : pourcentage de blocs dénoncés délimités par des structures de contrôle qui ont été exécutés. Cette métrique a lavantage dêtre plus représentative que la couverture dénoncés, parce que les blocs comportant plusieurs énoncés nont pas un poids plus important que les autres. – Couverture de branchements : pourcentage des choix de branchement exécutés. – Couverture dexpressions : pourcentage des composantes des expressions booléennes qui ont affecté la valeur de ces expressions. – Couverture détats : pourcentage du nombre détats visités. – Couverture de transitions : pourcentage des transitions de chaque état ayant été prises. – Couverture de changements de signaux : pourcentage de signaux binaires ayant passé de 0 à 1 et de 1 à (notes, section )

40 INF3500 : Conception et implémentation de systèmes numériques Couverture de code (test de boîte blanche) Pour chacune des couvertures possibles, on peut calculer une métrique qui exprime: – le nombre de fois où chaque situation se produit; ou, – le pourcentage des situations qui se sont produites. Par exemple, on voudrait atteindre 100% de couverture des énoncés. Si on nest quà 90%, cela signifie quil faut stimuler le circuit avec dautres vecteurs de test. Le code doit être instrumenté pour obtenir les métriques (par un outil). Un outil peur présenter linformation obtenue de façon conviviale pour faciliter la sélection de vecteurs de test. Les différents éléments de couverture ne sont pas tous indépendants. Par exemple, la couverture détats et la couverture de transitions sont effectivement des sous-ensembles de la couverture dénoncés et de branchements. Démonstration avec Active-HDL. 40 (notes, section )

41 INF3500 : Conception et implémentation de systèmes numériques Parenthèse: outils dActive-HDL pour la couverture de code Configuration de lenvironnement: – Design > Settings > Compilation > VHDL > Enable Debug – Design > Settings > Coverage/Profiler> Coverage : Code, Expression, Path – Design > Settings > Coverage/Profiler> Code Coverage > Collect data per instance Procédure: – Choisir le banc dessai comme entité à simuler – Initialiser la simulation – Simulation > Toggle Coverage > Toggle On, OK – Lancer la simulation – Arrêter la simulation (essentiel pour que les rapports soient écrits sur le disque) 41 (pas dans les notes)

42 INF3500 : Conception et implémentation de systèmes numériques Parenthèse: outils dActive-HDL pour la couverture de code Tools > Code Coverage Viewer – File > Open: Ouvrir le fichier coverage/results.ccl – Inspecter les rapports de couverture Count: nombre dexécutions de la ligne BC: branch coverage, nombre dexécutions vraies et fausses de chaque branchement EC: expression coverage Tools > Toggle Coverage Viewer – File > Open: Ouvrir le fichier toggle.xml – Inspecter le rapport de couverture 42 (pas dans les notes)

43 INF3500 : Conception et implémentation de systèmes numériques Création de vecteurs de test selon la couverture de code Un bon ensemble de vecteurs de tests produit une couverture de code de 100%. Mais … des métriques de couverture de 100% pour un ensemble de vecteurs de test ne garantissent pas que le circuit rencontre toutes ses spécifications. Les métriques de couverture de code complètent les autres types de tests et donnent une certaine assurance au concepteur que le circuit est bien vérifié. Il peut y avoir des exceptions, comme par exemple: – des énoncés qui sont en place pour protéger le système lors dentrées non valides – des énoncés pour ramener le système dans un état valide à partir dun état non valide Ces deux cas nécessitent des vecteurs de test spéciaux. 43 (notes, section )

44 INF3500 : Conception et implémentation de systèmes numériques Couverture de paramètres dopération (test de boîte blanche) La couverture de code nindique que si certaines situations ont été exercées ou non, sans égard à la fonctionnalité du système. Un test plus puissant consiste à identifier les paramètres dopération du système et à vérifier la couverture des valeurs possibles de ceux-ci. Par exemple, pour une file dattente, un paramètre serait le nombre déléments dans la file. Il est important de vérifier lopération de la file quand celle-ci est vide, presque vide, pleine et presque pleine, ainsi quen situations mitoyennes. Pour obtenir la couverture des paramètres dopération, les étapes suivantes peuvent être suivies : – Énumérer les paramètres dopération du module; – Pour chaque paramètre, déterminer la gamme des valeurs possibles et identifier les valeurs qui doivent absolument être vérifiées et dans quelles circonstances; – Instrumenter le code afin de noter les valeurs de paramètre utilisées; – Simuler le système; et, – Calculer le rapport des valeurs utilisées sur le nombre de valeurs totales; – Établir si les valeurs à vérifier lont été. 44 (notes, section )

45 INF3500 : Conception et implémentation de systèmes numériques Couverture fonctionnelle (test de boîte blanche) Dans ce genre de couverture, on énumère toutes les fonctions que le système doit pouvoir effectuer. Par exemple, dans un processeur, il doit être possible de transférer la valeur dun registre vers un autre. On doit donc choisir des vecteurs de test qui exercent chacune des fonctions de la spécification. 45 (notes, section )

46 INF3500 : Conception et implémentation de systèmes numériques Plan pour aujourdhui Introduction: retour sur la vérification avec un banc dessai: sections 7.1 à 7.10 Élaboration dun plan de test: section 7.11 Composition dun ensemble de vecteurs de test: section 7.12 – tests de boîte noire – tests de boîte blanche Concepts avancés: section Des parenthèses sur VHDL, des précisions sur les notes de cours, des trucs pour utiliser Active-HDL, et des exemples!

47 INF3500 : Conception et implémentation de systèmes numériques Concepts avancés de vérification Analyse statique du code La meilleure façon de réduire le nombre de bogues dans un design est de réduire les chances de leur introduction dans celui-ci. En adoptant des pratiques de codage favorisant la vérification, on augmente les chances datteindre ce but. Guides de codage: – développés avec le temps en se basant sur lexpérience des concepteurs; – restreignent lutilisation dun langage à un sous-ensemble robuste et sécuritaire. Il existe des outils de vérification du respect des guides de codage qui effectuent une analyse statique du code. Le premier programme de la sorte sappelait lint, et ce terme est souvent appliqué aux outils comme au processus. 47 (notes, section )

48 INF3500 : Conception et implémentation de systèmes numériques Parenthèse: outils pour lanalyse statique du code Outils ALINT dAldec – voir le site web 48 (pas dans les notes)

49 INF3500 : Conception et implémentation de systèmes numériques Concepts avancés de vérification Analyse statique du code En VHDL et dans les autres HDL, une analyse statique peut détecter des erreurs potentielles et augmenter la qualité du code. Ces erreurs potentielles peuvent se situer à plusieurs niveaux, et la liste suivante donne quelques exemples : – Opérandes de largeurs différentes dans une expression; – Énoncés conditionnels dont tous les cas ne sont pas couverts et qui créent des états implicites; – Énoncés conditionnels qui se recoupent; – Nom dentité différent du nom du fichier; – Insertion de signaux de contrôle dans le chemin dune horloge; – Signaux ou variables qui ne sont pas initialisés avant dêtre utilisés; – Signaux ou variables auxquels on nassigne jamais de valeur ou qui ne sont jamais utilisés; et, – Expression constante dans une structure de condition. 49 (notes, section )

50 INF3500 : Conception et implémentation de systèmes numériques Concepts avancés de vérification Vérification hiérarchique Une approche hiérarchique simplifie leffort de vérification. Cette approche devrait correspondre à la hiérarchie naturelle du système. Trois niveaux: – Modules (p. ex. additionneur ou décodeur): comportement simple, pleine visibilité, test exhaustif {génie logiciel: test unitaire} – Unités (p. ex. une UAL): choisir des vecteurs de test à partir des spécifications, bonne bonne visibilité de linterface entre les modules, vérification des interactions entre les modules {génie logiciel: test dintégration} – Système: vérifier les fonctionnalités de haut niveau, vérifier que les interconnections entre les unités sont correctes {génie logiciel: test de système} 50 (notes, section )

51 INF3500 : Conception et implémentation de systèmes numériques Concepts avancés de vérification Détection, identification et suivi des bogues Le but de la sélection des vecteurs de test et leur application au circuit en simulation est de découvrir les bogues du circuit. Quand un bogue survient: 1.Identifier les conditions où le bogue est devenu apparent: version du code, suite de vecteurs de tests qui a mené à la défaillance, paramètres de simulation. 2.Déterminer la source du bogue: une stratégie consiste à réduire la portée du circuit ou de lensemble de vecteurs de test. 3.Documenter le bogue dans un système de suivi: enregistrer le bogue, les conditions pour le produire, son statut, sa priorité, les actions prises pour le résoudre. Un graphique de la fréquence dapparence de nouveaux bogues dans un système donne une indication générale de la fiabilité de celui-ci. 51 (notes, section )

52 INF3500 : Conception et implémentation de systèmes numériques Banc dessai et entrées et sorties par fichiers en VHDL On sest concentrés à date sur la génération algorithmique de vecteurs de test à lintérieur dun banc dessai codé en VHDL. Dans le processus de conception dun système numérique, on passe souvent par une modélisation de haut niveau, par exemple avec Matlab. Lors de cette modélisation, on génère souvent une grande quantité de cas de test et de réponses attendues qui sont entreposés dans un fichier. Le banc dessai peut lire ces cas de test et les réponses associées. Le banc dessai peut aussi écrire ses résultats dans un fichier. Utilités: – si la simulation dure plusieurs heures; – si on désire obtenir des résultats progressifs; – si on doit effectuer un traitement plus complexe des résultats dans un autre environnement que le simulateur VHDL. Par exemple, on pourrait vouloir afficher une image générée sous la forme dun flux de pixels par un module. 52 (notes, section 7.7)

53 INF3500 : Conception et implémentation de systèmes numériques Banc dessai et entrées et sorties par fichiers en VHDL Les entrées et sorties de fichier en VHDL se font à laide dobjets de la catégorie file. Comme on traite du texte lors de ces opérations, on utilise aussi les types et les fonctions définis dans le package textio qui fait partie du langage. 53 (notes, section 7.7)

54 INF3500 : Conception et implémentation de systèmes numériques Banc dessai et entrées et sorties par fichiers en VHDL Exemple Module à vérifier et fichier de stimuli et réponses 54 (notes, section 7.7) library ieee; use ieee.std_logic_1164.ALL; use ieee.numeric_std.all; entity detecteurPremier is port ( I : in unsigned(5 downto 0); F : out std_logic ); end detecteurPremier; architecture flotdonnees of detecteurPremier is begin with to_integer(I) select F <= '1' when 2 | 3 | 5 | 7 | 11 | 13 | 17 | 19 | 23 | 29 | 31 | 37 | 41 | 43 | 47 | 53 | 59 | 61 | 63, -- erreur! '0' when others; end flotdonnees; -- colonne1: entiers de 0 à colonne2: P pour premier, N pour pas premier 0 N 1 N 2 P 3 P 4 N 5 P...

55 INF3500 : Conception et implémentation de systèmes numériques Banc dessai et entrées et sorties par fichiers en VHDL Exemple Banc dessai 55 (notes, section 7.7) library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; use std.textio.all; entity detecteurPremierTB is end detecteurPremierTB; architecture arch2 of detecteurPremierTB is component detecteurPremier -- déclaration du module à vérifier port (I : in unsigned(5 downto 0); F : out std_logic); end component; signal I : unsigned(5 downto 0); -- signal pour les vecteurs de tests signal F : std_logic; -- signal pour les réponses constant filename : string := "premiers.txt"; file vecteurs : text open read_mode is filename; -- format du fichier: -- colonne1: entier, colonne2: 'P' pour premier, 'N' pour pas premier begin -- instanciation du module à vérifier UUT : detecteurPremier port map (I, F);

56 INF3500 : Conception et implémentation de systèmes numériques Banc dessai et entrées et sorties par fichiers en VHDL Exemple Banc dessai 56 (notes, section 7.7) process variable tampon : line; -- pointeur vers un objet de type string variable n : integer; variable c : character; begin while not endfile(vecteurs) loop readline(vecteurs, tampon); if tampon(1 to 2) /= "--" then -- passer les lignes de commentaires read(tampon, n); -- lecture de l'entier read(tampon, c); -- lecture du séparateur read(tampon, c); -- lecture de l'indication: premier ('P') ou non ('N') I <= to_unsigned(n, 6); wait for 10 ns; assert ((c = 'P') = (F = '1') and (c = 'N') = (F = '0')) report "erreur pour l'entrée " & integer'image(n) severity error; end if; end loop; deallocate(tampon); -- relâcher la mémoire du tampon report "simulation terminée" severity failure; end process; end arch2;

57 INF3500 : Conception et implémentation de systèmes numériques Banc dessai et entrées et sorties par fichiers en VHDL Exemple: écriture dans un fichier Banc dessai 57 (notes, section 7.7) process variable tampon : line; -- pointeur vers objet de type string variable tampon2 : line; begin -- La procédure writeline libère le pointeur quand elle a fini, -- donc il faut construire une copie de l'objet si on veut l'afficher 2 fois. -- À partir d'un pointeur, on va chercher le contenu avec '.all'. write(tampon, string'(" ** sortie de simulation, detecteurPremierTB.vhd ** ")); write(tampon2, tampon.all); -- copier la chaîne de caractères writeline(resultats, tampon); -- écriture dans le fichier writeline(output, tampon2); -- écriture à la console for k in 0 to 63 loop -- application exhaustive des vecteurs de test I <= to_unsigned(k, 6); wait for 10 ns; write(tampon, string'("temps: ")); write(tampon, now, unit => ns); write(tampon, string'(", entier: ") & integer'image(k)); write(tampon, string'(", sortie: ") & std_logic'image(F)); write(tampon2, tampon.all); -- copie la chaîne de caractères writeline(resultats, tampon); -- écriture dans le fichier writeline(output, tampon2); -- écriture à la console end loop; report "simulation terminée" severity failure; end process;

58 INF3500 : Conception et implémentation de systèmes numériques Notions à retenir et maîtriser Importance relative 1. Le plan de test: nommer, expliquer et appliquer les trois étapes à suivre10 2. Évaluer la complexité dun test exhaustif pour des circuits combinatoires et séquentiels10 3. Énumérer les cinq qualités dun bon ensemble de vecteurs de test10 4. Tests de boîte noire a.Décrire le principe général b.Le partitionnement en classe: décrire et utiliser c.Analyse des valeurs limites: décrire et utiliser d.Tests pseudo-aléatoire: décrire les principes à respecter, utiliser ce test Tests de boîte blanche a.Décrire le principe général b.La couverture de code: décrire et utiliser c.Couverture de paramètres dopération et couverture fonctionnelle: décrire Analyse statique du code, vérification hiérarchique, et suivi des bogues: décrire5 11. Banc dessai et entrées-sorties par fichier: analyser, comprendre et expliquer le code5 Total100 Résumé: vérification 58


Télécharger ppt "INF3500 : Conception et implémentation de systèmes numériques Pierre Langlois Cours #7 Vérification."

Présentations similaires


Annonces Google