Introduction à UVM

Comprendre les composants d'un environnement UVM et savoir quand la méthode apporte plus qu'un testbench SystemVerilog simple.

Une méthode construite sur SystemVerilog

UVM, pour Universal Verification Methodology, est une bibliothèque de classes et une méthode d'organisation des testbenches SystemVerilog. Elle standardise les rôles déjà rencontrés : séquences, driver, monitor, agent, scoreboard, environnement et test.

UVM ne remplace pas la connaissance du protocole ni le modèle de référence. Il fournit une structure commune, des phases, un système de rapports, une fabrique d'objets et des mécanismes de configuration et de communication.

Les composants principaux

Un environnement courant contient :

• un sequence_item qui représente une transaction ;
• une sequence qui produit une suite d'items ;
• un sequencer qui arbitre les séquences ;
• un driver qui applique les items à l'interface ;
• un monitor qui observe les transferts ;
• un agent qui regroupe sequencer, driver et monitor ;
• un scoreboard et, parfois, un modèle de référence ;
• un env qui relie les composants ;
• un test qui choisit la configuration et lance le scénario.

Le driver et le sequencer échangent par un protocole transactionnel défini par UVM. Le monitor publie généralement ses transactions par un port d'analyse vers la couverture ou le scoreboard.

Phases de construction et d'exécution

Les composants sont créés et configurés pendant des phases de fonction comme build_phase et connect_phase. Les activités qui consomment du temps vivent dans run_phase.

class stream_monitor extends uvm_monitor;
  `uvm_component_utils(stream_monitor)
 
  uvm_analysis_port #(stream_item) observed;
  virtual stream_if vif;
 
  function new(string name, uvm_component parent);
    super.new(name, parent);
    observed = new("observed", this);
  endfunction
 
  task run_phase(uvm_phase phase);
    forever begin
      @(posedge vif.clk);
      if (vif.valid && vif.ready) begin
        stream_item item = stream_item::type_id::create("item");
        item.data = vif.data;
        observed.write(item);
      end
    end
  endtask
endclass

Ce code illustre la structure, mais un vrai monitor doit aussi récupérer l'interface virtuelle par la configuration, contrôler le reset et reconstruire tous les champs du protocole.

Factory et configuration

La factory permet de remplacer un type par une variante sans modifier chaque point de création. C'est utile pour injecter une transaction spéciale ou un composant enrichi, à condition que les objets soient créés par type_id::create.

uvm_config_db transmet des configurations comme une interface virtuelle. Une portée trop large ou une clé mal orthographiée peut échouer tard. Il faut vérifier chaque get et garder les chemins aussi locaux que possible.

Quand utiliser UVM

UVM devient intéressant pour plusieurs interfaces, des variantes de configuration, la réutilisation au niveau sous-système ou une équipe qui partage la même méthode. Pour un petit bloc avec dix cas dirigés, un testbench SystemVerilog simple est souvent plus rapide et plus lisible.

Le bon point de départ est de maîtriser un environnement en couches sans UVM. Les mêmes responsabilités se retrouvent ensuite dans les classes UVM.

À retenir

• UVM organise un testbench SystemVerilog avec une bibliothèque standard.
• Sequence, driver, monitor, scoreboard et environnement gardent des rôles séparés.
• Les fonctions construisent et connectent, run_phase fait avancer le temps.
• La factory et la configuration apportent de la souplesse, mais doivent être contrôlées.
• UVM est utile pour la réutilisation et les grands environnements, pas automatiquement pour chaque bloc.

📝 Tester mes connaissances - Quiz du chapitre