Comprendre la Sémantique d'Ordonnancement Verilog : Timing, Événements et Ordre d'Exécution

La conception et le banc de test Verilog ont typiquement de nombreuses lignes de code comprenant des blocs always ou initial, des affectations continues et d'autres instructions procédurales qui deviennent actives à différents moments au cours d'une simulation.

Chaque changement de valeur d'un signal dans le modèle Verilog est considéré comme un événement de mise à jour. Et les processus tels que les blocs always et assign qui sont sensibles à ces événements de mise à jour sont évalués dans un ordre arbitraire et c'est ce qu'on appelle un événement d'évaluation. Puisque ces événements peuvent se produire à différents moments, ils sont mieux gérés et assurés de leur ordre correct d'exécution en les planifiant dans des files d'événements qui sont arrangées par temps de simulation.

module tb;
  reg a, b, c;
  wire d;
  // 'always' est un processus qui est évalué quand soit 'a' ou 'b' est mis à jour.
  // Quand 'a' ou 'b' change de valeur, c'est appelé un 'événement de mise à jour'.
  // Quand le bloc 'always' est déclenché à cause d'un changement dans 'a' ou 'b', c'est appelé un événement d'évaluation
  always @ (a or b) begin
    c = a & b;
  end
  // Ici 'assign' est un processus qui est évalué quand soit 'a' ou 'b' ou 'c'
  // est mis à jour
  assign d = a | b ^ c;
endmodule

File d'Événements

Une étape de simulation peut être segmentée en quatre régions différentes. Une file d'événements active est juste un ensemble de processus qui doivent s'exécuter au temps courant ce qui peut résulter en plus de processus à planifier dans la file active ou d'autres files d'événements. Les événements peuvent être ajoutés à n'importe quelle région, mais toujours retirés de la région active.

• Active : Les événements se produisent au temps de simulation courant et peuvent être traités dans n'importe quel ordre.
• Inactive : Les événements se produisent au temps de simulation courant, mais sont traités après que tous les événements actifs sont traités.
• Assignation non-bloquante : Les événements qui ont été évalués précédemment seront assignés après que tous les événements actifs et inactifs sont traités.
• Monitor : Les événements sont traités après que tous les événements actifs, inactifs et assignations non-bloquantes sont faits.

Quand tous les événements dans la file active pour le pas de temps courant ont été exécutés, le simulateur avance le temps au pas de temps suivant et exécute sa file active.

module tb;
  reg x, y, z;
  initial begin
    #1 x = 1; y = 1;
    #1 z = 0;
  end
endmodule

La simulation commence au temps 0, et la première instruction est planifiée pour être exécutée quand le temps de simulation atteint 1 unité de temps auquel elle assigne x et y à 1. C'est la file active pour le temps courant qui est 1 unité de temps. Le simulateur planifie ensuite la prochaine instruction après 1 unité de temps de plus auquel z est assigné 0.

Qu'est-ce qui rend la simulation non-déterministe ?

Il peut y avoir des conditions de course pendant la simulation qui finissent par donner des sorties différentes pour la même conception et banc de test. Une des raisons du comportement non-déterministe est parce que les événements actifs peuvent être retirés de la file et traités dans n'importe quel ordre.