07 Verification (VHDL)

Cours #7
Vrification dun modle VHDL
Conception et implmentation des systmes numriques
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

vrification de la puce
annotation
des dlais
vrification par simulation
code HDL
schma
diagramme
dtats
gnration
de code
HDL
synthse
implmentation
contraintes
(temps et
espace)
Extraction statique des mtriques dimplmentation
(ressources, dlai, puissance)
gnration du
fichier de
configuration
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
rponses attendues
observation
des rponses
gnration de
vecteurs de
test et de
rponses
attendues
fichier de
stimuli et
rponses
succs/chec
comparaison
aux rponses
attendues
vecteurs de test
circuit vrifier
rponses
fichier des
rsultats
banc dessai
pas de ports dentre
ni de sortie
library ieee;
use ieee.std_logic_1164.all;
le module vrifier
qui est add3bits
entity add3bitsTB is
end add3bitsTB;
architecture arch1 of add3bitsTB is
component add3bits -- dclaration du module vrifier
port (Cin, X, Y : in std_logic; Cout, S : out std_logic);
end component;
-- signaux
signal Cin
signal X :
signal Y :
signaux internes du
banc dessai
stimulation laide
de trois noncs
concurrents utilisant
la clause after
pour les vecteurs de tests

: std_logic;
std_logic;
std_logic;
Il faut vrifier manuellement si la

spcification est rencontre.
-- signaux pour les rponses

signal Cout : std_logic;
signal S : std_logic;
begin
-- instanciation du module vrifier
UUT : add3bits port map (Cin, X, Y, Cout, S);
le module vrifier est ici

UUT : pour Unit Under Test
-- on applique des vecteurs de test

Cin <= '0' after 0 ns, '1' after 40 ns;
Y <= '0' after 0 ns, '1' after 20 ns, '0' after 40 ns, '1' after 60 ns;
X <= '0' after 0 ns, '1' after 10 ns, '0' after 20 ns, '1' after 30 ns,
'0' after 40 ns, '1' after 50 ns, '0' after 60 ns, '1' after 70 ns;
end arch1;
Vecteurs de test encods dans un tableau de constantes

end component;
nouveau type: tableau de

std_logic_vector de 3
lments
dclaration dune constante
contenant les vecteurs de test
application de tous
les vecteurs
-- signaux pour les vecteurs de tests

signal Cin, X, Y : std_logic;
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
Ici on peut faire un test exhaustif,

mais quelles valeurs placer dans
le tableau des constantes en
gnral?
process -- application des vecteurs de test emmagasins

dans le tableau
begin
for k in vecteurs'low to vecteurs'high loop
(Cin, Y, X) <= vecteurs(k);
wait for 10 ns;
end loop;
stabiliser les sorties
end process;
pendant 10ns
end arch2;
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.
library ieee;
use ieee.numeric_std.all;
end component;
-- signaux pour les vecteurs de tests
signal Cin, X, Y : std_logic;
signal Cout, S : std_logic;
begin
process -- application exhaustive des vecteurs de test
begin
for k in 0 to 7 loop
La vrification exhaustive nest
nest
(Cin, Y, X) <= to_unsigned(k, 3);
wait for 10 ns;
pas toujours possible.
Retourne un unsigned, identique
end loop;
std_logic_vector.
end process;
end arch3;
Vrification pseudo-alatoire
Un test pseudo-alatoire peut venir complter un test plus dirig.

library ieee;
use ieee.math_real.all;
architecture arch4 of add3bitstb is
-- comme prcdemment
begin
process -- gnration alatoire de vecteurs de test
variable seed1 : positive := 1;
variable seed2 : positive := 2;
variable aleatoire : real;
variable t : integer := -1;
begin
Un test pseudo-alatoire peut tre

intressant, mais il ne permet pas
par lui-mme de savoir quel
point le circuit a t vrifi.
la procdure uniform, dfinie dans
le package math_real
uniform(seed1, seed2, aleatoire); -- 0.0 < aleatoire < 1.0

aleatoire := floor(aleatoire * 8.0); -- 0.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;
Vrification dun circuit squentiel

library ieee;
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';
X
constant periode : time := 10 ns;
begin
CLK
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 := "00001010010011000111";
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 diffrent 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 termine" severity failure;
else
X <= vecteurX(compte);
compte := compte + 1;
end if;
end if;
end process;
end arch1a;Conception et implmentation des systmes numriques
CLK
Q'
Z
CLK
Q'
Comment savoir si le circuit a t

adquatement vrifi?
Toutes les transitions possibles entre les
tats ont-elles t testes au moins une
fois? Y a-t-il dautres critres vrifier?
Pour un circuit squentiel, vrification
exhaustive veut dire: pour chaque tat,
appliquer chaque entre possible
on observe que le processus est synchronis sur un
front descendant dhorloge, alors que le circuit
vrifier est synchronis sur un front montant. .
Plan

tests de bote noire

Concepts avancs:
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.

1. 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.

1. Extraire les fonctionnalits requises du systme
Exemple pour une unit de file dattente (FIFO).

Quatre catgories de fonctionnalits vrifier
Exemple de fonctionnalit
Il 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.
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 nest

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

pleine).

2. 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.

3. 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.

3. 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
Mehdi
Assigne
2. crire dans la pile
Mehdi
crite
3. Lire de la pile
Asma
crite
4. criture et lecture simultanes
Alexis
En dv.
5. Pile pleine
a.
Fonctionnement du signal full
b.
criture impossible
Alexis
En dv.
6. Pile vide
a.
Fonctionnement du signal empty
b.
Lecture impossible
Armand
Assigne
7. Signaux overflow et underflow
Armand
Assigne
Plan

tests de bote noire

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

tests de bote noire

Concepts avancs:
Concepts avancs de vrification

Analyse 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.

Analyse 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.

Vrification 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}

Dtection, 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.
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
Suspend la simulation

Exemple
Module vrifier et fichier de stimuli et rponses

library ieee;
use ieee.std_logic_1164.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 63
-- colonne2: P pour premier, N pour pas premier
0N
1N
2P
3P
4N
5P
...

Exemple
Banc dessai
library ieee;
use std.textio.all;
use ieee.std_logic_textio.all; -- pour l'affichage sur console
entity detecteurPremierTB is
end detecteurPremierTB;
architecture arch2 of detecteurPremierTB is

component detecteurPremier -- dclaration du module vrifier
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 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
UUT : detecteurPremier port map (I, F);

Exemple
Banc dessai
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 sparateur
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'entre " & integer'image(n) severity error;
end if;
end loop;
deallocate(tampon); -- relcher la mmoire du tampon
end process;
end arch2;

Exemple: criture dans un fichier
Banc dessai
process
variable tampon : line; -- pointeur vers objet de type string
variable 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 caractres
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 chane de caractres
writeline(resultats, tampon); -- criture dans le fichier
writeline(output, tampon2); -- criture la console
end loop;
end process;

07 Verification (VHDL)

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

07 Verification (VHDL)

Transféré par

Droits d'auteur :

Formats disponibles

Cours #7

Vrification dun modle VHDL

Conception et implmentation des systmes numriques

Introduction: retour sur la vrification avec un banc dessai

tests de bote noire

tests de bote blanche

Conception et implmentation des systmes numriques

Flot de conception de circuits numriques

vrification par simulation

Conception et implmentation des systmes numriques

Vrification: concepts fondamentaux

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

le contrle des entres et de signaux internes du circuit vrifier; et,

lobservation des sorties, des signaux internes et de ltat du circuit vrifier.

Conception et implmentation des systmes numriques

Vrification par banc dessai

Un banc dessai permet dappliquer des vecteurs de test un circuit et dobserver sa

instancier le circuit vrifier;

[utile]: gnrer automatiquement des rponses attendues aux vecteurs de test;

(pour circuit squentiel): gnrer un signal dhorloge et un signal de rinitialisation

Conception et implmentation des systmes numriques

pour les vecteurs de tests

Il faut vrifier manuellement si la

-- signaux pour les rponses

le module vrifier est ici

-- on applique des vecteurs de test

Conception et implmentation des systmes numriques

Vecteurs de test encods dans un tableau de constantes

nouveau type: tableau de

-- signaux pour les vecteurs de tests

Ici on peut faire un test exhaustif,

process -- application des vecteurs de test emmagasins

Vrification exhaustive laide dune boucle

Pour un circuit combinatoire, il est parfois possible de faire une vrification

Un test pseudo-alatoire peut venir complter un test plus dirig.

Un test pseudo-alatoire peut tre

uniform(seed1, seed2, aleatoire); -- 0.0 < aleatoire < 1.0

Vrification dun circuit squentiel

Comment savoir si le circuit a t

Introduction: retour sur la vrification avec un banc dessai

tests de bote noire

tests de bote blanche

Conception et implmentation des systmes numriques

laboration dun plan de test

Un plan de test est un document qui dtaille la stratgie employe pour

la couverture du test: quels requis de la spcification doivent tre vrifis

les responsabilits de test: qui est responsable de quels tests?

laboration dun plan de test

La spcification architecturale dcrit linterface du systme avec le monde

Conception et implmentation des systmes numriques

laboration dun plan de test

Exemple pour une unit de file dattente (FIFO).

Il est possible de placer le systme dans son tat de dpart

Retour ltat de dpart quand le

partir dun tat valide et tant donne une entre valide,

Conception et implmentation des systmes numriques

criture dans la file (quand la file nest

criture dans la file (quand la file est

laboration dun plan de test

Il y a souvent une trs grande quantit de fonctionnalits vrifier.

Conception et implmentation des systmes numriques

laboration dun plan de test

On cre un ensemble de vecteurs de test pour chaque fonctionnalit vrifier.

Conception et implmentation des systmes numriques