07 verification (vhdl)

Conception et implmentation des systmes numriques

Cours #7Vrification dun modle VHDL


Plan

Introduction: retour sur la vrification avec un banc dessai laboration dun plan de test Composition dun ensemble de vecteurs de test:

tests de bote noire tests de bote blanche

Concepts avancs:


Flot de conception de circuits numriques

code HDL

schma

diagramme dtats

gnration de code

HDL

synthse implmentationgnration du

fichier de configuration

vrification par simulation annotationdes dlais

Extraction statique des mtriques dimplmentation(ressources, dlai, puissance)

contraintes (temps et espace)

vrification de la puce

puce


Vrification: concepts fondamentaux

La vrificationest un processus par lequel on vrifie quun design rencontre bien ses spcifications.

La vrification complte dun circuit est normalement un problme trs difficile. Dans lindustrie de la conception numrique, on considre en gnral que le

processus de vrification ncessite autant defforts que le processus de conception lui-mme.

La vrification dun circuit est un art qui repose sur la matrise de trois principes: la comprhension de la spcification; le contrle des entres et de signaux internes du circuit vrifier; et, lobservation des sorties, des signaux internes et de ltat du circuit vrifier.


Vrification par banc dessai

Un banc dessai permet dappliquer des vecteurs de test un circuit et dobserver sa sortie dans le but de vrifier quil rencontre ses spcifications.

Un banc dessai doit effectuer les tches suivantes: instancier le circuit vrifier; gnrer des vecteurs de test et les appliquer aux ports dentre du circuit; [utile]: gnrer automatiquement des rponses attendues aux vecteurs de test; [utile]: comparer les rponses du circuit aux rponses attendues, et indiquer toute

diffrence entre les deux par une condition derreur. (pour circuit squentiel): gnrer un signal dhorloge et un signal de rinitialisation

banc dessai

circuit vrifier

gnration de vecteurs de test et de rponses attendues

observation des rponses

comparaison aux rponses

attenduesvecteurs de test rponsesfichier de

stimuli et rponses

rponses attendues

fichier des rsultats

succs/chec


banc dessai

library ieee;use ieee.std_logic_1164.all;

entity add3bitsTB isend add3bitsTB;

architecture arch1 of add3bitsTB is

component add3bits -- dclaration du module vrifierport (Cin, X, Y : in std_logic; Cout, S : out std_logic);end component;

-- signaux pour les vecteurs de testssignal Cin : std_logic;signal X : std_logic;signal Y : std_logic;

-- signaux pour les rponsessignal Cout : std_logic;signal S : std_logic;

begin-- instanciation du module vrifierUUT : add3bits port map (Cin, X, Y, Cout, S);

-- on applique des vecteurs de testCin


Vecteurs de test encods dans un tableau de constantes

nouveau type: tableau de std_logic_vector de 3 lments

application de tous les vecteurs



-- signaux pour les vecteurs de testssignal Cin, X, Y : std_logic;-- signaux pour les rponsessignal 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 vrifierUUT : add3bits port map (Cin, X, Y, Cout, S);

process -- application des vecteurs de test emmagasins dans le tableau

beginfor k in vecteurs'low to vecteurs'high loop

(Cin, Y, X)


Vrification exhaustive laide dune boucle

Pour un circuit combinatoire, il est parfois possible de faire une vrification exhaustive. Au lieu dun tableau, on peut utiliser une boucle.

Retourne un unsigned, identique std_logic_vector.

library ieee;use ieee.numeric_std.all;



-- signaux pour les vecteurs de testssignal Cin, X, Y : std_logic;-- signaux pour les rponsessignal Cout, S : std_logic;

begin-- instanciation du module vrifierUUT : add3bits port map (Cin, X, Y, Cout, S);

process -- application exhaustive des vecteurs de testbegin

for k in 0 to 7 loop(Cin, Y, X)


Un test pseudo-alatoire peut venir complter un test plus dirig.library ieee;use ieee.numeric_std.all;use ieee.math_real.all;

architecture arch4 of add3bitstb is

-- comme prcdemment

begin

-- instanciation du module vrifierUUT : add3bits port map (Cin, X, Y, Cout, S);

process -- gnration alatoire de vecteurs de testvariable seed1 : positive := 1;variable seed2 : positive := 2;variable aleatoire : real;variable t : integer := -1;begin

uniform(seed1, seed2, aleatoire); -- 0.0 < aleatoire < 1.0aleatoire := floor(aleatoire * 8.0); -- 0.0


Vrification dun circuit squentiel

library ieee;use ieee.std_logic_1164.all;use std.textio.all;entity cctsequentielex1TB isend cctsequentielex1TB;architecture arch1a of cctsequentielex1TB issignal 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 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 consoleif compte = vecteurX'length then

report "simulation termine" severity failure;else

X


Plan



Concepts avancs:


laboration dun plan de test

Un plan de test est un document qui dtaille la stratgie employe pour effectuer la vrification dun systme.

La complexit et le niveau de dtail dun plan de test dpendent de la taille du module, circuit, sous-systme ou systme vrifier.

Un plan de test complet pourrait entre autres dtailler: la couverture du test: quels requis de la spcification doivent tre vrifis

par le test? les mthodes de test: comment le systme sera-t-il vrifi? quelles sont les

conditions de russite et dchec des cas de test? les responsabilits de test: qui est responsable de quels tests?

Un plan de test sommaire peut tre labor en trois tapes:1. Extraire les fonctionnalits requises du systme partir de ses

spcifications;2. Prioriser les fonctionnalits vrifier; et,3. Crer des vecteurs de test.


laboration dun plan de test1. Extraire les fonctionnalits requises du systme

La spcification architecturale dcrit linterface du systme avec le monde extrieur et ses relations dentres et sortie.

La spcification architecturale ne spcifie pas comment le comportement interne du systme doit tre ralis.

Il est difficile dextraire toutes les fonctionnalits requises partir de la spcification. Il est encore plus difficile dautomatiser cette extraction.

Certaines fonctionnalits sont implicites. Dautres fonctionnalits ou comportements ne doivent pas tre prsents.

Concevoir et dcrire une file d'attente en VHDL. Le nombre maximum d'lments dans la file et la largeur des donnes en bits doivent tre paramtrables. Un signal d'horloge synchronise toutes les activits de la file.Le signal reset permet de vider la file. Les ports din et dout sont respectivement l'entre 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 place sur le port din sera insre dans la file lors de la prochaine transition active du signal d'horloge clk. Quand le signalrd_en (read enable) est activ, la valeur qui est dans la file depuis le plus longtemps sera place 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 simultanment. Quand la file est pleine, le signal wr_en n'a aucuneffet - il n'est pas possible d'crire par dessus le contenu prsent 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 simultanment.


laboration dun plan de test1. Extraire les fonctionnalits requises du systme

Exemple pour une unit de file dattente (FIFO).

Quatre catgories de fonctionnalits vrifier Exemple de fonctionnalitIl est possible de placer le systme dans son tat de dpart valide partir de nimporte quel tat.

Retour ltat de dpart quand le signal reset est activ.

partir dun tat valide et tant donne une entre valide, le systme doit se placer dans le bon tat valide.

criture dans la file (quand la file nest pas pleine). partir dun tat valide et tant donne une entre valide,

le systme ne doit pas se placer dans un tat non valide ou un tat incorrect.

partir dun tat valide et tant donne une entre non valide, le systme ne doit pas se placer dans un tat non valide ou un tat incorrect.

criture dans la file (quand la file est pleine).


laboration dun plan de test2. Prioriser les fonctionnalits vrifier

Il y a souvent une trs grande quantit de fonctionnalits vrifier. Il peut tre utile de les placer en ordre de priorit.

1. Les fonctionnalits qui correspondent des contraintes de scurit devraient tre considres en premier.

2. Les fonctionnalits qui correspondent des besoins fondamentaux du systme identifis dans les spcifications devraient tre vrifies de faon prioritaire.

3. Les fonctionnalits qui faciliteraient lutilisation du systme peuvent avoir une priorit plus faible.

4. Enfin, les fonctionnalits facultatives ou futures du systme peuvent avoir une priorit encore plus faible.


laboration dun plan de test3. Crer un ensemble de vecteurs de test

On cre un ensemble de vecteurs de test pour chaque fonctionnalit vrifier. Il faut tablir comment vrifier la fonctionnalit et comment tablir quelle est

satisfaite ou non partir des signaux du systme. On dtermine les vecteurs de test spcifiques qui permettent de stimuler la

fonctionnalit dsire. Pour aider au processus de cration des vecteurs de test, il est ncessaire de

bien documenter chaque tape.


laboration dun plan de test3. Crer un ensemble de vecteurs de test

Par exemple, le plan de test peut comporter un tableau dans lequel on identifie les fonctionnalits vrifier ainsi que leur priorit, assigner une personne responsable et suivre leur statut dans le temps: en dveloppement, dbute, crite, applique, rvise, etc.

Fonctionnalit Priorit Responsable Statut de la tche

1. Rinitialisation 1 Mehdi Assigne

2. crire dans la pile 2 Mehdi crite

3. Lire de la pile 2 Asma crite

4. criture et lecture simultanes 2 Alexis En dv.

5. Pile pleinea. Fonctionnement du signal fullb. criture impossible

2 Alexis En dv.

6. Pile videa. Fonctionnement du signal emptyb. Lecture impossible

2 Armand Assigne

7. Signaux overflow et underflow 4 Armand Assigne


Plan



Concepts avancs:


Tests de bote noire (ou tests fonctionnels)

Le terme test de bote noire fait rfrence un test qui ne suppose aucune connaissance de limplmentation du systme.

En anglais: black box, opaque box, closed box, functional test. Les tests de bote noire sappuient uniquement sur les spcifications du systme. Plus le systme est complexe, et plus il faut utiliser ce genre de test. Il est difficile de dterminer quel point le systme a t vrifi par ce genre de

test. Les tests de bote noire ne permettent pas en gnral de dcouvrir des

comportements non spcifis du systme.


Tests de bote noire (ou tests fonctionnels)

Par exemple, pour un module de chronomtre qui doit calculer la date du lendemain la fin de la journe, on peut identifier les classes de donnes dentre suivantes:

Pour les mois : mois de 30 jours, mois de 31 jours, mois de fvrier. Pour les jours : jour est entre 1 et 28, jour est 29, jour est 30, jour est 31. Pour les annes : anne divisible par 4, anne centenaire, autres annes.

Pour un test fort, on devrait choisir au moins un vecteur de test pour chacune des combinaisons de classes. Par exemple, l'ensemble de vecteurs de test devrait inclure le cas du mois de 31 jours avec les quatre classes de jour et les trois classes dannes.


Tests de bote blanche (ou tests structurels)

Le terme test de bote blanche fait rfrence un test qui ncessite de connatre le fonctionnement interne du systme.

En anglais: white box, glass box, clear box, structural test. En sappuyant sur des principes de couverture, on peut calculer des mtriques

permettant de dterminer quel point le test a vrifi le systme. Les tests de bote blanche ne permettent pas en gnral de dcouvrir les

fonctionnalits manquantes du systme.


Couverture de code(test de bote blanche)

Dans la couverture de code, on choisit des vecteurs de test pour exercer un lment particulier du design ou de sa description. Il y en a plusieurs:

Couverture dnoncs: pourcentage des noncs du code excuts. Couverture de blocs: pourcentage de blocs dnoncs dlimits par des

structures de contrle qui ont t excuts. Cette mtrique a lavantage dtre plus reprsentative que la couverture dnoncs, parce que les blocs comportant plusieurs noncs nont pas un poids plus important que les autres.

Couverture de branchements: pourcentage des choix de branchement excuts.

Couverture dexpressions: pourcentage des composantes des expressions boolennes qui ont affect la valeur de ces expressions.

Couverture dtats : pourcentage du nombre dtats visits. Couverture de transitions: pourcentage des transitions de chaque tat ayant

t prises. Couverture de changements de signaux: pourcentage de signaux binaires


Plan



Concepts avancs:


Concepts avancs de vrificationAnalyse statique du code

La meilleure faon de rduire le nombre de bogues dans un design est de rduire les chances de leur introduction dans celui-ci.

En adoptant des pratiques de codage favorisant la vrification, on augmente les chances datteindre ce but.

Guides de codage: dvelopps avec le temps en se basant sur lexprience des concepteurs; restreignent lutilisation dun langage un sous-ensemble robuste et

scuritaire. Il existe des outils de vrification 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.


Concepts avancs de vrificationAnalyse statique du code

En VHDL et dans les autres HDL, une analyse statique peut dtecter des erreurs potentielles et augmenter la qualit du code. Ces erreurs potentielles peuvent se situer plusieurs niveaux, et la liste suivante donne quelques exemples:

Oprandes de largeurs diffrentes dans une expression; noncs conditionnels dont tous les cas ne sont pas couverts et qui crent

des tats implicites; noncs conditionnels qui se recoupent; Nom dentit diffrent du nom du fichier; Insertion de signaux de contrle dans le chemin dune horloge; Signaux ou variables qui ne sont pas initialiss avant dtre utiliss; Signaux ou variables auxquels on nassigne jamais de valeur ou qui ne sont

jamais utiliss; et, Expression constante dans une structure de condition.


Concepts avancs de vrificationVrification hirarchique

Une approche hirarchique simplifie leffort de vrification. Cette approche devrait correspondre la hirarchie naturelle du systme. Trois niveaux:

Modules (p. ex. additionneur ou dcodeur): comportement simple, pleine visibilit, test exhaustif {gnie logiciel: test unitaire}

Units (p. ex. une UAL): choisir des vecteurs de test partir des spcifications, bonne bonne visibilit de linterface entre les modules, vrification des interactions entre les modules {gnie logiciel: test dintgration}

Systme: vrifier les fonctionnalits de haut niveau, vrifier que les interconnexions entre les units sont correctes {gnie logiciel: test de systme}


Concepts avancs de vrificationDtection, identification et suivi des bogues

Le but de la slection des vecteurs de test et leur application au circuit en simulation est de dcouvrir 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 dfaillance, paramtres de simulation.

2. Dterminer la source du bogue: une stratgie consiste rduire la porte du circuit ou de lensemble de vecteurs de test.

3. Documenter le bogue dans un systme de suivi: enregistrer le bogue, les conditions pour le produire, son statut, sa priorit, les actions prises pour le rsoudre.

Un graphique de la frquence dapparence de nouveaux bogues dans un systme donne une indication gnrale de la fiabilit de celui-ci.


Banc dessai et entres et sorties par fichiers en VHDL

On sest concentrs jusqu'ici la gnration algorithmique de vecteurs de test lintrieur dun banc dessai cod en VHDL.

Lors de cette modlisation, on gnre souvent une grande quantit de cas de test et de rponses attendues qui sont entreposs dans un fichier.

Le banc dessai peut lire ces cas de test et les rponses associes. Le banc dessai peut aussi crire ses rsultats dans un fichier. Utilits:

si la simulation dure plusieurs heures; si on dsire obtenir des rsultats progressifs; si on doit effectuer un traitement plus complexe des rsultats dans un autre

environnement que le simulateur VHDL. Par exemple, on pourrait vouloir afficher une image gnre sous la forme dun flux de pixels par un module.


Banc dessai et entres et sorties par fichiers en VHDL

Les entres et sorties de fichier en VHDL se font laide dobjets de la catgorie file.

Comme on traite du texte lors de ces oprations, on utilise aussi les types et les fonctions dfinis dans le package textio qui fait partie du langage

Automatiser l'observation et L' valuation des rponses assert et report: [assert expression_logique] report message severity [note, warning, error, ou failure]; Exemple: assert (estPremier(k) = (F = '1')) report "erreur pour l'entre " & integer'image(k) severity error; assert k < kmax report "simulation termine" severity failure;

Suspend la simulation


Banc dessai et entres et sorties par fichiers en VHDLExemple

Module vrifier et fichier de stimuli et rponseslibrary 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 isbegin

with to_integer(I) selectF



Banc dessai

library ieee;use ieee.std_logic_1164.all;use ieee.numeric_std.all;use std.textio.all;use ieee.std_logic_textio.all; -- pour l'affichage sur console

entity detecteurPremierTB isend detecteurPremierTB;architecture arch2 of detecteurPremierTB is

component detecteurPremier -- dclaration du module vrifierport (I : in unsigned(5 downto 0); F : out std_logic);end component;

signal I : unsigned(5 downto 0); -- signal pour les vecteurs de testssignal F : std_logic; -- signal pour les rponses

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 vrifierUUT : detecteurPremier port map (I, F);



Banc dessai

processvariable tampon : line; -- pointeur vers un objet de type stringvariable n : integer;variable c : character;begin

while not endfile(vecteurs) loopreadline(vecteurs, tampon);if tampon(1 to 2) /= "--" then -- passer les lignes de commentaires

read(tampon, n); -- lecture de l'entierread(tampon, c); -- lecture du sparateurread(tampon, c); -- lecture de l'indication: premier ('P') ou non ('N')I


Banc dessai et entres et sorties par fichiers en VHDLExemple: criture dans un fichier

Banc dessaiprocess

variable tampon : line; -- pointeur vers objet de type stringvariable tampon2 : line;

begin -- La procdure writeline libre 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 chane de caractreswriteline(resultats, tampon); -- criture dans le fichierwriteline(output, tampon2); -- criture la console

for k in 0 to 63 loop -- application exhaustive des vecteurs de testI

07 verification (vhdl)

Documents