Écrire un plan de vérification simple
Transformer un cahier des charges en fonctions à contrôler, cas limites, moyens de vérification et critères de fin.
Vérifier autre chose que le code
Un plan de vérification part du cahier des charges, pas de l'implémentation RTL. Si le même détail est mal compris dans le design et dans le testbench, comparer les deux ne révélera pas l'erreur.
Il faut donc relire les besoins indépendamment et noter les zones floues avant d'écrire les tests. Une phrase comme « le résultat est valide après le calcul » doit être précisée : combien de cycles, que se passe-t-il si la sortie n'est pas prête, et le résultat reste-t-il stable ?
Une ligne par fonction vérifiable
Un plan simple peut prendre la forme d'un tableau :
| Fonction | Scénarios | Contrôle | Couverture | Priorité |
|---|---|---|---|---|
| Reset | démarrage, reset en activité | sorties et état interne attendus | chaque point d'interruption utile | haute |
| Transfert | nominal, attente, rafales | scoreboard du protocole | longueurs et attentes croisées | haute |
| Erreur | dépassement, commande illégale | code d'erreur et absence d'effet interdit | chaque erreur | moyenne |
Chaque ligne doit pouvoir être reliée à un test dirigé, une contrainte aléatoire, une assertion ou un point de couverture. Si une exigence n'a aucun moyen de contrôle, elle n'est pas réellement vérifiée.
Les cinq tâches du testbench
Un environnement complet doit :
- générer des transactions ;
- les appliquer au DUT ;
- observer entrées et sorties ;
- comparer le comportement à une référence ;
- mesurer ce qui a été exercé.
Ces rôles peuvent être tenus par quelques tâches dans un petit projet ou par des composants séparés dans un environnement plus grand. Le plan reste le même.
Cas nominaux, limites et erreurs
Pour chaque fonction, prévoir :
- un cas normal facile à diagnostiquer ;
- les valeurs minimales et maximales ;
- des opérations consécutives sans pause ;
- les combinaisons de commandes simultanées ;
- les interruptions par reset ;
- les entrées interdites et la réponse attendue.
L'aléatoire aide à croiser ces situations, mais ne remplace pas les cas dirigés qui prouvent rapidement les fonctions de base.
Un critère de fin concret
« Lancer beaucoup de cycles » n'est pas un critère de fin. On peut arrêter lorsque :
- tous les tests obligatoires passent ;
- les assertions ne signalent plus d'erreur ;
- les points de couverture prévus sont atteints ou justifiés ;
- les bugs connus ont une décision documentée ;
- aucune exigence importante ne reste sans contrôle.
La couverture indique ce qui a été stimulé, pas que le résultat était juste. Il faut la lire avec les contrôles fonctionnels.
À retenir
- Le plan vient des exigences et doit rester indépendant du RTL.
- Chaque fonction a besoin de scénarios, d'un contrôle et d'une mesure.
- Les cas limites et le reset doivent être prévus dès le début.
- L'aléatoire complète les tests dirigés.
- La fin de vérification repose sur des critères mesurables et des écarts expliqués.
📝 Tester mes connaissances - Quiz du chapitre