Sécuritédanslesréseauxdecapteurssansl Implémentation&Conception
INF3500 : Conception et implémentation de systèmes numériques Pierre Langlois Cours #7...
-
Upload
alison-pottier -
Category
Documents
-
view
107 -
download
1
Transcript of INF3500 : Conception et implémentation de systèmes numériques Pierre Langlois Cours #7...
INF3500 : Conception et implémentation de systèmes numériques
http://creativecommons.org/licenses/by-nc-sa/2.5/ca/
Pierre Langlois
Cours #7Vérification d’un modèle VHDL
INF3500 : Conception et implémentation de systèmes numériques
Plan pour aujourd’hui
• Introduction: retour sur la vérification avec un banc d’essai: sections 7.1 à 7.10• Élaboration d’un plan de test: section 7.11• Composition d’un ensemble de vecteurs de test: section 7.12
– tests de boîte noire– tests de boîte blanche
• Concepts avancés: section 7.13
2
+ Des parenthèses sur VHDL, des précisions sur
les notes de cours, des trucs pour utiliser
Active-HDL, et des exemples!
INF3500 : Conception et implémentation de systèmes numériques
Flot de conception de circuits numériques
3
code HDL
schéma
diagramme d’états
génération de code
HDL
synthèse implémentationgénération du
fichier de configuration
vérification par simulationannotationdes délais
Extraction statique des métriques d’implémentation(ressources, délai, puissance)
contraintes (temps et espace)
vérification de la puce
puce
(notes, section 4.2)
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 qu’un design rencontre bien ses spécifications.
• La vérification complète d’un circuit est normalement un problème très difficile.• Dans l’industrie de la conception numérique, on considère en général que le
processus de vérification nécessite autant d’efforts que le processus de conception lui-même.
• La vérification d’un 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,– l’observation des sorties, des signaux internes et de l’état du circuit à vérifier.
4
(notes, section 7.1)
INF3500 : Conception et implémentation de systèmes numériques
Vérification par banc d’essai
• Un banc d’essai permet d’appliquer des vecteurs de test à un circuit et d’observer sa sortie dans le but de vérifier qu’il rencontre ses spécifications.
• Un banc d’essai doit effectuer les tâches suivantes :– instancier le circuit à vérifier;– générer des vecteurs de test et les appliquer aux ports d’entré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 d’erreur.– (pour circuit séquentiel): générer un signal d’horloge et un signal de réinitialisation
5
banc d’essai
circuit à vérifier
génération de vecteurs de test et de réponses attendues
observation des réponses
comparaison aux réponses
attendues
vecteurs de test réponsesfichier de stimuli et réponses
réponses attendues
fichier des résultats
succès/échec
(notes, section 7.2 et 7.10)
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érifierport (Cin, X, Y : in std_logic; Cout, S : out std_logic);end component;
-- signaux pour les vecteurs de testssignal Cin, X, Y : std_logic;-- signaux pour les réponsessignal 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érifierUUT : add3bits port map (Cin, X, Y, Cout, S);
process -- application des vecteurs de test emmagasinés dans le tableaubegin
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 d’une 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)
INF3500 : Conception et implémentation de systèmes numériques
Vérification exhaustive à l’aide d’une boucle
• Pour un circuit combinatoire, il est parfois possible de faire une vérification exhaustive. Au lieu d’un 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érifierport (Cin, X, Y : in std_logic; Cout, S : out std_logic);end component;
-- signaux pour les vecteurs de testssignal Cin, X, Y : std_logic;-- signaux pour les réponsessignal Cout, S : std_logic;
begin
-- instanciation du module à vérifierUUT : 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) <= to_unsigned(k, 3);wait for 10 ns;
end loop;end process;
end arch3;
(notes, section 7.5.1)
La vérification exhaustive n’est pas toujours possible.
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érifierUUT : add3bits port map (Cin, X, Y, Cout, S);
process -- génération aléatoire 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 <= aleatoire <= 7.0t := 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é.
INF3500 : Conception et implémentation de systèmes numériques
Vérification d’un circuit séquentiel
9
(notes, section 7.10)
library ieee;use ieee.std_logic_1164.all;use std.textio.all;entity cctsequentielex1TB isend 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 := "00001010010011000111";variable compte : natural range 0 to vecteurX'length := 0;variable tampon : line; -- pointeur vers objet de type stringbegin
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 consoleif compte = vecteurX'length then
report "simulation terminée" severity failure;else
X <= vecteurX(compte);compte := compte + 1;
end if;end if;
end process;
end arch1a;
D
CLK
Q'
Q
Z
XD
CLK
Q'
Q
CLK
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 d’autres critères à vérifier?
Pour un circuit séquentiel, « vérification exhaustive » veut dire: pour chaque état, appliquer chaque entrée possible.
INF3500 : Conception et implémentation de systèmes numériques
Plan pour aujourd’hui
• Introduction: retour sur la vérification avec un banc d’essai: sections 7.1 à 7.10• Élaboration d’un plan de test: section 7.11• Composition d’un ensemble de vecteurs de test: section 7.12
– tests de boîte noire– tests de boîte blanche
• Concepts avancés: section 7.13
10
+ Des parenthèses sur VHDL, des précisions sur
les notes de cours, des trucs pour utiliser
Active-HDL, et des exemples!
INF3500 : Conception et implémentation de systèmes numériques
Élaboration d’un plan de test
• Un plan de test est un document qui détaille la stratégie employée pour effectuer la vérification d’un système.
• La complexité et le niveau de détail d’un 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)
INF3500 : Conception et implémentation de systèmes numériques
Élaboration d’un plan de test1. Extraire les fonctionnalités requises du système
• La spécification architecturale décrit l’interface du système avec le monde extérieur et ses relations d’entré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 d’extraire toutes les fonctionnalités requises à partir de la spécification. Il est encore plus difficile d’automatiser cette extraction.
• Certaines fonctionnalités sont implicites. D’autres 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.
INF3500 : Conception et implémentation de systèmes numériques
Élaboration d’un plan de test1. Extraire les fonctionnalités requises du système
• Exemple pour une unité de file d’attente (FIFO).
13
(notes, section 7.11)
Quatre catégories de fonctionnalités à vérifier Exemple de fonctionnalité
Il est possible de placer le système dans son état de départ valide à partir de n’importe quel état.
Retour à l’état de départ quand le signal reset est activé.
À partir d’un é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 n’est pas pleine).À partir d’un é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 d’un é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).
INF3500 : Conception et implémentation de systèmes numériques
Élaboration d’un plan de test2. 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 l’utilisation 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)
INF3500 : Conception et implémentation de systèmes numériques
Élaboration d’un plan de test3. 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 qu’elle 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)
INF3500 : Conception et implémentation de systèmes numériques
Élaboration d’un plan de test3. 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é Responsable Statut de la tâche
1. Réinitialisation 1 Armand Assignée
2. Écrire dans la pile 2 Armand Écrite
3. Lire de la pile 2 Asma Écrite
4. Écriture et lecture simultanées 2 Alexis En dév.
5. Pile pleinea. Fonctionnement du signal ‘full’b. Écriture impossible
2 Alexis En dév.
6. Pile videa. Fonctionnement du signal ‘empty’b. Lecture impossible
2 Armand Assignée
7. Signaux ‘overflow’ et ‘underflow’ 4 Armand Assignée
INF3500 : Conception et implémentation de systèmes numériques
Plan pour aujourd’hui
• Introduction: retour sur la vérification avec un banc d’essai: sections 7.1 à 7.10• Élaboration d’un plan de test: section 7.11• Composition d’un ensemble de vecteurs de test: section 7.12
– tests de boîte noire– tests de boîte blanche
• Concepts avancés: section 7.13
17
+ Des parenthèses sur VHDL, des précisions sur
les notes de cours, des trucs pour utiliser
Active-HDL, et des exemples!
INF3500 : Conception et implémentation de systèmes numériques
Cinq qualités d’un bon ensemble de vecteurs de test
• Le problème de la création d’un ensemble de vecteurs de test n’est pas simple.• Les vecteurs de test choisis doivent permettre de vérifier que le circuit rencontre
ses spécifications.• Les cinq qualités principales d’un bon ensemble de vecteurs de test sont:
– Efficace pour découvrir des bogues, c’est-à-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é à l’aide d’un banc d’essai.– Exécutable dans un temps raisonnable.
• dépend de la taille et de la complexité du circuit et de l’ampleur du projet
18
(notes, section 7.12.2)
Laboratoire de 3 heures: quelques minutesProjet intégrateur: de plusieurs minutes à quelques heuresSystème de grande envergure: de plusieurs heures à quelques jours
INF3500 : Conception et implémentation de systèmes numériques
Le test exhaustif
• Les tests exhaustifs permettent d’observer le comportement du circuit pour toutes les conditions possibles d’entrée.
• En pratique il est impossible d’effectuer un test exhaustif dans un temps raisonnable.
• Pour un circuit combinatoire avec M entrées, il faut 2M vecteurs de test.• Pour un circuit combinatoire avec:
– N bascules, S = 2N états, et– M entrées, R = 2M transitions possibles à partir de chaque état,
il faudrait prévoir 2N + M vecteurs de test différents juste pour effectuer toutes les
transitions possibles du système au moins une fois.
19
(notes, section 7.12.1)
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?
>= 240?
>= 180?
>= 120?
>= 60?
enco
deur
à p
riorit
é
>= 0?
secondes (0 à 255)/8
minutes(0 à 4, sur 3 bits)
/3
0
60
120
180
240
/8
secondes(0 à 59, sur 6 bits)
/6
0
1
2
3
4
0
1
2
3
4
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;
INF3500 : Conception et implémentation de systèmes numériques
Exemple: conversion de couleurs de RGB à CMYK
• Les images sont habituellement encodées dans l’espace à trois dimensions RGB.• Une imprimante utilise plutôt l’espace 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
21A. Stodghill, Tip o’day: ask for a a refill, Green Options, 2007/06/18. Consulté le 4 septembre 2009, tiré de http://greenoptions.com/tag/ink-cartridge
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 isport ( rouge, vert, bleu : in unsigned(7 downto 0);cyan, magenta, jaune, noir : out unsigned(7
downto 0));end convRGB2CMYK;
Minimum
R
G
B
Ct
Mt
Yt
255
C
M
Y
K
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 isport (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…
S2Sortie <= 0
S4Sortie <= 1
S3Sortie <= 0
S1Sortie <= 1
x=00
x=01
x=10
x=10
reset
x=11
x=11
INF3500 : Conception et implémentation de systèmes numériques
Exemple: joueur de blackjackDescription du jeu de base
• Le jeu oppose des joueurs à un croupier qui joue pour le compte de la banque.• Le but du jeu est d’accumuler 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,– l’as 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)
INF3500 : Conception et implémentation de systèmes numériques
Exemple: joueur de blackjack
25
(notes, section 6.7)
ajoutesomme <= somme + valeurCarte
valeurCarte = 11 : n_asfacile++
tiretirer <= ‘1’
carteValide = ‘1’
2: somme > 16
reset
1: somme > 21 ET n_asfacile > 0
departsomme <= 0
n_asfacile <= 0
corrigesomme <= somme – 10
n_asfacile--
fini
3: sinon
vérifie
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;
…
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
INF3500 : Conception et implémentation de systèmes numériques
Plan pour aujourd’hui
• Introduction: retour sur la vérification avec un banc d’essai: sections 7.1 à 7.10• Élaboration d’un plan de test: section 7.11• Composition d’un ensemble de vecteurs de test: section 7.12
– tests de boîte noire– tests de boîte blanche
• Concepts avancés: section 7.13
27
+ Des parenthèses sur VHDL, des précisions sur
les notes de cours, des trucs pour utiliser
Active-HDL, et des exemples!
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 l’implémentation du système.
• En anglais: black box, opaque box, closed box, functional test.• Les tests de boîte noire s’appuient 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 7.12.3)
INF3500 : Conception et implémentation de systèmes numériques
Vecteurs de test choisis par partitionnement en classes(test de boîte noire)
29
Circuit à vérifier
Entrée1
Entrée2
Entrée3
classe 1-1
classe 1-2
classe 1-3
classe 2-1
classe 2-2
classe 3-1 classe 3-2
classe 3-3 classe 3-4
Sortie
(notes, section 7.12.4)
INF3500 : Conception et implémentation de systèmes numériques
Vecteurs de test choisis par partitionnement en classes(test de boîte noire)
• L’ensemble des valeurs d’entrée du système est partitionné en classes séparées.• Le principe du partitionnement en classes s’appuie sur la supposition suivante:
– deux données d’une 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 7.12.4)
Circuit à vérifier
Entrée1
Entrée2
Entrée3
classe 1-1
classe 1-2
classe 1-3
classe 2-1
classe 2-2
classe 3-1 classe 3-2
classe 3-3 classe 3-4
Sortie
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 d’un chronomètre doit calculer la date du lendemain à la fin de la journée. On peut identifier les classes de données d’entré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 d’années.– cas du mois de février, le jour 31, l’année centenaire (pas valide).– etc.
• Il n’est 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 7.12.4)
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 7.12.4)
Circuit à vérifier
Entrée1
Entrée2
Entrée3
classe 1-1
classe 1-2
classe 1-3
classe 2-1
classe 2-2
classe 3-1 classe 3-2
classe 3-3 classe 3-4
Sortie
{classe i-j} : un élément de la classe i-jpar exemple:{classe année-divisible par 4}: 1904{classe mois-mois de 30 jours}: 4 (avril)
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 l’observation que les erreurs se produisent souvent aux valeurs limites des données (exemple: débordement d’une addition).
• On devrait inclure dans les vecteurs de test, pour chaque donnée, jusqu’à sept valeurs différentes:
33
(notes, section 7.12.5)
Valeur Exemple pour le jour,mois de janvier
Une valeur juste inférieure à la valeur minimale 0
La valeur minimale 1
Une valeur juste supérieure à la valeur minimale 2
Une valeur nominale 15
Une valeur juste inférieure à la valeur maximale 30
La valeur maximale 31
Une valeur juste supérieure à la valeur maximale 32
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: 7n 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 5n 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 7.12.5)
y
Espace des entrées possibles
x
Exemple pour deux variables x et y.
INF3500 : Conception et implémentation de systèmes numériques
Exemple: conversion de couleurs de RGB à CMYK
35
Quels vecteurs de test choisir selon l’analyse 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 isport ( rouge, vert, bleu : in unsigned(7 downto 0);cyan, magenta, jaune, noir : out unsigned(7
downto 0));end convRGB2CMYK;
Minimum
R
G
B
Ct
Mt
Yt
255
C
M
Y
K
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 l’avantage 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 s’assurer 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 l’horloge) 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 d’opération du système.
36
(notes, section 7.12.6)
INF3500 : Conception et implémentation de systèmes numériques
Plan pour aujourd’hui
• Introduction: retour sur la vérification avec un banc d’essai: sections 7.1 à 7.10• Élaboration d’un plan de test: section 7.11• Composition d’un ensemble de vecteurs de test: section 7.12
– tests de boîte noire– tests de boîte blanche
• Concepts avancés: section 7.13
37
+ Des parenthèses sur VHDL, des précisions sur
les notes de cours, des trucs pour utiliser
Active-HDL, et des exemples!
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 s’appuyant 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 7.12.3)
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 l’avantage d’être plus représentative que la couverture d’énoncés, parce que les blocs comportant plusieurs énoncés n’ont pas un poids plus important que les autres.
– Couverture de branchements : pourcentage des choix de branchement exécutés.– Couverture d’expressions : 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 à 0.
39
(notes, section 7.12.7)
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 n’est qu’à 90%, cela signifie qu’il faut stimuler le circuit avec d’autres vecteurs de test.
• Le code doit être instrumenté pour obtenir les métriques (par un outil).• Un outil peur présenter l’information 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 7.12.7)
INF3500 : Conception et implémentation de systèmes numériques
Parenthèse: outils d’Active-HDL pour la couverture de code
• Configuration de l’environnement:– 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 d’essai 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)
INF3500 : Conception et implémentation de systèmes numériques
Parenthèse: outils d’Active-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 d’exécutions de la ligne• BC: branch coverage, nombre d’exé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)
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 d’entrées non valides– des énoncés pour ramener le système dans un état valide à partir d’un état non
valide
Ces deux cas nécessitent des vecteurs de test spéciaux.
43
(notes, section 7.12.8)
INF3500 : Conception et implémentation de systèmes numériques
Couverture de paramètres d’opération(test de boîte blanche)
• La couverture de code n’indique 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 d’opération du système et à vérifier la couverture des valeurs possibles de ceux-ci.
• Par exemple, pour une file d’attente, un paramètre serait le nombre d’éléments dans la file. Il est important de vérifier l’opération de la file quand celle-ci est vide, presque vide, pleine et presque pleine, ainsi qu’en situations mitoyennes.
• Pour obtenir la couverture des paramètres d’opération, les étapes suivantes peuvent être suivies :– Énumérer les paramètres d’opé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 l’ont été.
44
(notes, section 7.12.9)
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 d’un registre vers un autre.
• On doit donc choisir des vecteurs de test qui exercent chacune des fonctions de la spécification.
45
(notes, section 7.12.10)
INF3500 : Conception et implémentation de systèmes numériques
Plan pour aujourd’hui
• Introduction: retour sur la vérification avec un banc d’essai: sections 7.1 à 7.10• Élaboration d’un plan de test: section 7.11• Composition d’un ensemble de vecteurs de test: section 7.12
– tests de boîte noire– tests de boîte blanche
• Concepts avancés: section 7.13
46
+ Des parenthèses sur VHDL, des précisions sur
les notes de cours, des trucs pour utiliser
Active-HDL, et des exemples!
INF3500 : Conception et implémentation de systèmes numériques
Concepts avancés de vérificationAnalyse 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 d’atteindre ce but.
• Guides de codage:– développés avec le temps en se basant sur l’expérience des concepteurs;– restreignent l’utilisation d’un 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 s’appelait ‘lint’, et ce terme est souvent appliqué aux outils comme au processus.
47
(notes, section 7.13.1)
INF3500 : Conception et implémentation de systèmes numériques
Parenthèse: outils pour l’analyse statique du code
• Outils ALINT d’Aldec – voir le site web
48
(pas dans les notes)
INF3500 : Conception et implémentation de systèmes numériques
Concepts avancés de vérificationAnalyse 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 d’entité différent du nom du fichier;– Insertion de signaux de contrôle dans le chemin d’une horloge;– Signaux ou variables qui ne sont pas initialisés avant d’être utilisés;– Signaux ou variables auxquels on n’assigne jamais de valeur ou qui ne sont jamais
utilisés; et,– Expression constante dans une structure de condition.
49
(notes, section 7.13.1)
INF3500 : Conception et implémentation de systèmes numériques
Concepts avancés de vérificationVérification hiérarchique
• Une approche hiérarchique simplifie l’effort 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 l’interface entre les modules, vérification des interactions entre les modules {génie logiciel: test d’inté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 7.13.2)
INF3500 : Conception et implémentation de systèmes numériques
Concepts avancés de vérificationDé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 l’ensemble 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 d’apparence de nouveaux bogues dans un système donne une indication générale de la fiabilité de celui-ci.
51
(notes, section 7.13.3)
INF3500 : Conception et implémentation de systèmes numériques
Banc d’essai et entrées et sorties par fichiers en VHDL
• On s’est concentrés à date sur la génération algorithmique de vecteurs de test à l’intérieur d’un banc d’essai codé en VHDL.
• Dans le processus de conception d’un 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 d’essai peut lire ces cas de test et les réponses associées.• Le banc d’essai 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 d’un flux de pixels par un module.
52
(notes, section 7.7)
INF3500 : Conception et implémentation de systèmes numériques
Banc d’essai et entrées et sorties par fichiers en VHDL
• Les entrées et sorties de fichier en VHDL se font à l’aide d’objets 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)
INF3500 : Conception et implémentation de systèmes numériques
Banc d’essai et entrées et sorties par fichiers en VHDLExemple
• 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 isbegin
with to_integer(I) selectF <= '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 premier0 N1 N2 P3 P4 N5 P...
INF3500 : Conception et implémentation de systèmes numériques
Banc d’essai et entrées et sorties par fichiers en VHDLExemple
• Banc d’essai
55
(notes, section 7.7)
library ieee;use ieee.std_logic_1164.all;use ieee.numeric_std.all;use std.textio.all;
entity detecteurPremierTB isend detecteurPremierTB; architecture arch2 of detecteurPremierTB is
component detecteurPremier -- déclaration du module à vérifierport (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 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érifierUUT : detecteurPremier port map (I, F);
INF3500 : Conception et implémentation de systèmes numériques
Banc d’essai et entrées et sorties par fichiers en VHDLExemple
• Banc d’essai
56
(notes, section 7.7)
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 séparateurread(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 tamponreport "simulation terminée" severity failure;
end process;
end arch2;
INF3500 : Conception et implémentation de systèmes numériques
Banc d’essai et entrées et sorties par fichiers en VHDLExemple: écriture dans un fichier
• Banc d’essai
57
(notes, section 7.7)
process
variable tampon : line; -- pointeur vers objet de type stringvariable 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èreswriteline(resultats, tampon); -- écriture dans le fichierwriteline(output, tampon2); -- écriture à la console
for k in 0 to 63 loop -- application exhaustive des vecteurs de testI <= 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èreswriteline(resultats, tampon); -- écriture dans le fichierwriteline(output, tampon2); -- écriture à la console
end loop;
report "simulation terminée" severity failure;
end process;
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 à suivre 102. Évaluer la complexité d’un test exhaustif pour des circuits combinatoires et séquentiels 103. Énumérer les cinq qualités d’un bon ensemble de vecteurs de test 104. Tests de boîte noirea. Décrire le principe généralb. Le partitionnement en classe: décrire et utiliserc. Analyse des valeurs limites: décrire et utiliserd. Tests pseudo-aléatoire: décrire les principes à respecter, utiliser ce test
30
5. Tests de boîte blanchea. Décrire le principe généralb. La couverture de code: décrire et utiliserc. Couverture de paramètres d’opération et couverture fonctionnelle: décrire
30
10. Analyse statique du code, vérification hiérarchique, et suivi des bogues: décrire 511. Banc d’essai et entrées-sorties par fichier: analyser, comprendre et expliquer le code 5
Total 100
Résumé: vérification
58