Driver, monitor, modèle de référence et scoreboard

Séparer l'application des commandes, l'observation du DUT, la prédiction et la comparaison des résultats.

Une chaîne de responsabilités

Un environnement en couches sépare les rôles afin qu'une erreur soit plus facile à localiser :

1. le générateur crée une transaction ;
2. le driver la convertit en changements de signaux ;
3. le monitor reconstruit les transactions réellement vues sur l'interface ;
4. le modèle de référence prédit le résultat ;
5. le scoreboard compare attendu et observé.

Le driver ne devrait pas décider si le résultat est correct. Le monitor ne devrait pas piloter le DUT. Ces frontières empêchent un même code de cacher sa propre erreur.

Le driver applique un protocole

task automatic drive(input request_t req);
  bus.valid <= 1'b1;
  bus.addr  <= req.address;
  bus.data  <= req.data;
 
  do @(posedge bus.clk); while (!bus.ready);
 
  bus.valid <= 1'b0;
endtask

Le driver reçoit une transaction abstraite et respecte le handshake cycle par cycle. Il ne doit pas consulter un signal interne du DUT pour aller plus vite.

Le monitor observe la réalité

task automatic monitor();
  forever begin
    @(posedge bus.clk);
    if (bus.valid && bus.ready) begin
      observed_t tr = new();
      tr.address = bus.addr;
      tr.data    = bus.data;
      observed_mb.put(tr);
    end
  end
endtask

Le monitor reconstruit ce qui a réellement été transféré. Il doit être passif. Un monitor sur l'entrée alimente le modèle de référence, tandis qu'un monitor sur la sortie alimente la comparaison.

Référence et scoreboard

Le modèle de référence doit être plus simple que le RTL. Il peut utiliser des types logiciels, une fonction claire ou un modèle externe, tant qu'il suit exactement les règles du cahier des charges.

Le scoreboard stocke les résultats attendus et les compare aux résultats observés. Une queue suffit pour des réponses dans l'ordre. Un tableau associatif indexé par identifiant convient aux réponses réordonnées.

Un bon message d'écart contient :

• la transaction ou l'identifiant ;
• la valeur attendue ;
• la valeur observée ;
• le temps et, si possible, le numéro de cycle ;
• le contexte utile sans noyer le journal.

Ne pas faire confiance à l'environnement trop vite

Le testbench mérite ses propres tests. On peut injecter volontairement une mauvaise réponse et vérifier que le scoreboard la détecte. On peut aussi couper une réponse pour vérifier le timeout et laisser un élément attendu afin de contrôler le bilan de fin.

Une couverture élevée ne compense pas un scoreboard incapable de détecter une erreur.

À retenir

• Le driver transforme une transaction en signaux selon le protocole.
• Le monitor reste passif et reconstruit ce qui a vraiment eu lieu.
• Le modèle de référence vient des exigences, pas d'une copie du RTL.
• Le scoreboard choisit son stockage selon l'ordre des réponses.
• L'environnement doit être testé avec des erreurs volontairement injectées.

📝 Tester mes connaissances - Quiz du chapitre