Parcours de vérification¶
La vérification répond à une question plus forte que « le chronogramme semble-t-il correct ? » :
Pour chaque exigence testée, le comportement observé correspond-il à une attente indépendante, et l'expérience entière est-elle reproductible automatiquement ?
Niveaux de vérification¶
| Niveau | But | Mécanisme |
|---|---|---|
| Analyse | Syntaxe et types | xvhdl -2008 |
| Élaboration | Associations, génériques, hiérarchie | xelab |
| Test dirigé | Scénarios et limites connus | Procédures et assertions |
| Test exhaustif | Toutes les combinaisons d'un petit espace | Boucles imbriquées |
| Modèle de référence | Comparaison avec un algorithme indépendant | Fonction pure ou modèle externe |
| Test par fichier | Import de cas générés ailleurs | TextIO |
| Test aléatoire | Exploration de nombreuses séquences | Générateur reproductible |
| Couverture | Mesure des situations exercées | Compteurs ou framework |
| Régression | Relance cohérente de tous les tests | PowerShell, Python ou CI |
| Analyse statique | Timing, CDC et DRC | Rapports Vivado |
| Test matériel | Intégration physique | Test de cohérence sur carte |
Progression recommandée¶
- Apprendre les assertions VHDL simples.
- Écrire des tests dirigés auto-vérifiants.
- Ajouter boucles et fonctions de référence.
- Ajouter un timeout et une fin propre.
- Lancer par la ligne de commande XSim.
- Lire des vecteurs lorsqu'un autre outil produit les résultats attendus.
- Ajouter séquences aléatoires et couverture.
- Adopter VUnit ou OSVVM lorsque la suite le justifie.
Architecture d'un banc de test¶
contrôle du test
│
├── pilote ──────> entrées du DUT
├── moniteur <──── sorties du DUT
├── modèle de référence
├── scoreboard : attendu contre observé
└── couverture : quelles situations ont été vues ?
Dans un petit exercice, tout peut vivre dans un processus. Dans un système plus grand, séparez les responsabilités pour que le banc de test reste digne de confiance.
Plan de vérification¶
| Exigence | Stimulation | Résultat attendu | Vérification | Couverture |
|---|---|---|---|---|
| Reset du compteur | Reset pendant un front | count=0 | assertion | reset vu |
| Incrément validé | enable=1 pendant N fronts | précédent+1 | modèle | N incréments |
| Maintien | enable=0 | inchangé | assertion | maintien vu |
| Débordement | max puis enable | zéro | assertion | overflow vu |
Cette table relie chaque test à une exigence.
Indépendance du modèle¶
Si le banc calcule la valeur attendue avec exactement le même algorithme et la même erreur que le DUT, les deux peuvent être d'accord et faux.
Préférez :
- une expression mathématique plutôt qu'une copie du RTL ;
- une table issue de la spécification ;
- un modèle Python/NumPy pour un traitement scientifique ;
- un modèle transactionnel simple ;
- des vecteurs de référence produits indépendamment.
Signification d'une réussite¶
Un test réussit seulement si :
- analyse et élaboration ont réussi ;
- aucune assertion d'erreur n'a été déclenchée ;
- les contrôles prévus ont réellement été exécutés ;
- le timeout n'a pas arrêté l'essai ;
- le simulateur a renvoyé un succès ;
- le journal contient un résumé explicite.
Afficher « PASS » sans compter les cas ni atteindre la fin attendue ne suffit pas.