Je suis confronté à des doutes concernant le non-déterminisme dans Verilog Scheduling Semantics mentionné dans le Verilog LRM. Ci-dessous l'extrait que je n'arrive pas à comprendre :

"Une autre source de non-déterminisme est que les déclarations sans constructions de contrôle du temps dans les blocs comportementaux n'ont pas à être exécuté comme un seul événement. Les instructions de contrôle du temps sont l'expression # et les constructions d'expression @ (voir 9.7). A tout moment lors de l'évaluation d'un déclaration de comportement, le simulateur peut suspendre l'exécution et placer l'événement partiellement terminé en tant qu'événement actif en attente sur l'événement file d'attente. Ceci a pour effet de permettre l'entrelacement des processus exécution. Notez que l'ordre d'exécution entrelacé est non déterministe et non sous le contrôle de l'utilisateur."

La seule inférence que je pouvais faire était que les instructions d'un bloc comportemental peuvent être suspendues pour l'exécution d'autres blocs comportementaux (qui sont actifs dans le même pas de temps) afin d'entrelacer l'exécution du processus bien que je ne sois pas sûr.

De plus, je ne comprends pas la ligne "les déclarations sans constructions de contrôle temporel dans les blocs comportementaux ne doivent pas être exécutées comme un seul événement". Que signifie le LRM en disant qu'il ne s'exécute pas comme un seul événement et que se passerait-il si un bloc comportemental contenait toutes les instructions contrôlées par le temps ?

Quelqu'un peut-il expliquer cela à l'aide de quelques exemples? Merci d'avance.

2
Raksh23 17 févr. 2020 à 12:59

1 réponse

Meilleure réponse

La seule chose que la simulation garantit est que toutes les instructions des blocs always seront exécutées séquentiellement. Dites, comme dans le bloc suivant :

always @(b,c,e,f) begin
   a = b | c;
   d = e & f;
   g = a ^ d ^ x;
   ...
end

Cependant, le simulateur peut décider d'exécuter les 2 premières instructions d'affilée, mais ensuite arrêter l'exécution de ce bloc avant la dernière instruction et laisser les autres blocs continuer. Ensuite, il reviendra à la dernière instruction. En ce sens, vous disposez d'un ordre non déterministe d'exécution des instructions.

Devinez quoi?! La valeur de x peut définitivement changer pendant l'attente. a et d peuvent également changer pendant que d'autres instructions sont exécutées. Ainsi, le résultat de g pourrait être non déterministe. Une bonne programmation permettra de lever ce type de non-déterminisme : lister tous les événements dans la liste de sensibilité, ne pas multiplier les signaux de pilotage, ... Le simulateur fera alors au mieux pour éviter ces situations.

La nécessité de cette simulation d'entrelacement est de permettre aux simulateurs de faire une meilleure optimisation pour des raisons de performances et de permettre à d'autres blocs de progresser en cas d'instructions très longues et bouclées.

Répondre au commentaire sur les contrôles de l'heure et des événements

Dans le bloc ci-dessus, un simulateur peut décider quand interrompre l'exécution. Du point de vue du programmeur, il est non déterministe. Vous ne savez pas quand cela peut arriver. La seule chose que l'on sache, c'est que cela se produirait dans la même simulation (temps) tick. Un bon simulateur fera de son mieux pour éviter tout effet secondaire de cela.

Les contrôles de synchronisation et de retard fournissent des arrêts déterministes. Par exemple,

always @(b,c,e,f) begin
   a = b | c;
   d = e & f;
   #1 g = a ^ d ^ x;
   ...
end

Dans l'instruction ci-dessus avec #1, vous dites en fait au simulateur d'arrêter l'exécution des instructions et d'attendre la prochaine coche.

always @(b,c,e,f) begin
   a = b | c;
   d = e & f;
   @(posedge clk)
   g = a ^ d ^ x;
   ...
end

Ici, il arrêtera l'exécution et attendra l'événement posedge clk.

Notez que les exemples ci-dessus ne sont pas synthétisables et doivent être utilisés dans le code comportemental (banc de test) uniquement. Pour la synthèse, vous devez vous en tenir au tout premier exemple et vous assurer que votre code est écrit conformément aux bonnes pratiques de codage Verilog.

2
Serge 17 févr. 2020 à 14:34