É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.
Choisir le bon type de stimulus
Les tests dirigés donnent un diagnostic rapide : ils prouvent le reset, un transfert nominal et les bornes avec peu de bruit. La randomisation contrainte explore ensuite les interactions que l'on n'aurait pas toutes énumérées.
Il est plus utile de faire varier le contrôle que de changer seulement les données : configuration du DUT, type et longueur de transaction, délais légaux, concurrence entre interfaces, réponses et erreurs injectées. Chaque lancement doit enregistrer sa graine, son test, sa configuration et la version du simulateur. Une graine n'est reproductible que dans un environnement et un ordre d'appels comparables.