Formellement, dans un simulateur évènementiel, le système est modélisé par des signaux et des tâches1. Les signaux renferment les données du système tandis que
les tâches encapsulent les algorithmes qui en modélisent le comportement. On associe à chaque tâche une liste dite de sensibilité qui est constituée de l'ensemble des signaux que la tâche doit surveiller. Lorsqu'un évènement2, tel qu'un
changement d'état, se produit sur l'un de ces signaux, la tâche est activée en vue de son exécution. Toutes les tâches activées à une date donnée sont ensuite exécutées au cours d'un cycle de simulation. On reproduit ainsi une apparente simultanéité d'exécution. Chaque cycle produit à son tour de nouveaux évènements qui modifient l'état des signaux du système, évènements qui activeront à leur tour de nouvelles tâches, donnant naissance à un nouveau cycle, et ainsi de suite.
L'action des tâches sur les signaux est régie par deux postulats simples : seul le passé peut être consulté ; seul l'avenir peut être modifié. Chaque opération effectuée au cour d'un cycle s'inscrit sur une ligne temporelle globale où l'on distingue clairement ce qui est passé de ce qui constitue l'avenir [59]. Au cours d'un cycle, toutes les tâches actives du système puisent leurs données dans un état stable et connu appelé « état présent », et inscrivent leur production dans un nouvel état, appelé « état futur »3. Ce nouvel état ne sera accessible en lecture
qu'au prochain cycle, lorsque le temps propre du simulateur aura atteint la date du dit état, conférant à celui-ci le statut d'état présent. Conformément aux deux postulats énoncés plus haut, d'une part, l'état présent du système, ainsi que tous les états antérieurs, ne peuvent pas être modifiés et, d'autre part, il est impossible d'avoir la moindre information sur l'état futur du système ainsi que sur les
1 Dans la littérature, on parle plutôt de processus. Nous préférons réserver le mot processus pour désigner ceux du système d'exploitation.
2 La notion d'évènement varie un peu selon les auteurs. Pour certains, il s'agit de l'exécution d'une tâche, pour d'autres, il s'agit des changements d'état opérés sur les signaux. Cela n'a guère d'importance en définitive : le changement d'état d'un signal à une certaine date est le résultat de l'exécution d'une tâche au même instant ; les deux « évènements » existent et sont irrémédiablement liés l'un à l'autre.
3 A moins que soit explicitement spécifié un délai lors de l'affectation, auquel cas l'état affecté se situe plus loin sur la ligne temporelle.
24 - Chapitre 1
éventuels états postérieurs à celui-ci. Ces deux derniers points garantissent la causalité du système.
En pratique, l'ordonnancement des tâches est non préemptif. Au cours d'un cycle, les tâches actives sont donc exécutées les unes après les autres. La distinction nette entre l'état présent et l'état futur permet alors de traduire l'apparente simultanéité d'exécution des tâches. Sous certaines conditions1, elle rend en effet
le résultat produit par un cycle indépendant de l'ordre effectif d'ordonnancement des tâches, ce qui garantit le déterminisme comportemental du système. Ce résultat se comprend aisément. Les données produites par un cycle de simulation dépendent uniquement des algorithmes exécutés et des données qu'ils exploitent. Or, les données exploitées par les tâches actives au cours d'un cycle proviennent exclusivement de l'état présent du système qui, par définition, n'est pas modifiable dans le cycle courant.
Le module ci-dessous, écrit en SystemVerilog, illustre ce point :
module exemple1; logic a = 1, b;
always begin // Une tache a <= !a;
b <= a; #5; end endmodule
A la lecture du code, on est tenté de croire que les signaux a et b prennent les mêmes valeurs aux mêmes instants. Il n'en est rien. La tâche désignée par le mot clé always détermine les états futurs de a et de b en exploitant la valeur de a relative à l'état présent du système. Les signaux a et b sont donc compléments l'un de l'autre et l'ordre des affectations n'a aucune influence sur ce résultat.
Le même comportement peut être obtenu avec deux tâches simultanées :
module exemple2; logic a = 1, b;
always #5 a <= !a; // Une première tache always #5 b <= a; // Une seconde tache endmodule
Là encore, les affectations de a et de b sont opérées à partir du même état présent. Là encore, l'ordre dans lequel sont opérées les affectations n'a aucune importance. Pour obtenir le comportement souhaité, l'activation de la seconde tâche doit être la conséquence d'un évènement affectant le signal a. C'est ce que traduit, dans ce dernier exemple, la liste de sensibilité @(a) associée à la seconde tâche :
1 La condition nécessaire et suffisante est que toutes les modifications apportées à un signal au cours d'un cycle doivent avoir pour résultat la même valeur, quelque soit l'ordre dans lequel sont effectuées les affectations. Pour s'en assurer, VHDL et SystemVerilog adoptent deux stratégies selon les cas : soit ils interdisent à un signal déjà piloté par une tâche d'être modifié par une autre ; soit ils utilisent des fonctions de résolution qui arbitrent les conflits engendrés par les affectations multiples. Voir [58] à ce sujet.
L'ordonnancement évènementiel temps-réel - 25 module exemple3; logic a = 1, b; always #5 a <= !a; always @(a) b <= a; endmodule
On illustre ici clairement le rôle joué par la liste de sensibilité dans l'établissement des relations causales entre les tâches. Par rapport à l'exemple précédent, l'exécution de la seconde tâche sera effectuée un cycle de simulation plus tard, après que le signal a a été mis à jour.
Le temps d'un simulateur évènementiel ne partage pas beaucoup plus avec le sens commun que son irréversible évolution croissante. Il est de nature discrète et est en général représenté par un entier positif. Il permet d'établir un ordre total des états du système. Il s'agit donc plus de compter les cycles que de se raccrocher à une évolution temporelle réaliste. Afin de gérer convenablement les problèmes de relaxation des données engendrés par les interactions entre tâches, le temps est parfois défini selon plusieurs dimensions interdépendantes (en général deux, quelques fois trois). La dimension la plus fine est nommée delta (Δ). La dimension la plus grande est plus simplement appelée date.
Tant qu'il y a des tâches actives
T <- date de la prochaine tâche active Δ <- 0
Tant qu'il y a des tâches actives à T
Tant qu'il y a des tâches actives à (T, Δ) Exécuter une tâche active
Fin tant que Δ <- Δ + 1 Fin tant que
Fin tant que
La convergence à une date donnée est assurée par une boucle pour laquelle chaque itération correspond à un cycle Δ de simulation. Lorsque la relaxation est enfin atteinte, la date est avancée pour correspondre à l'état futur le plus proche et les cycles Δ reprennent leur course à partir de zéro.
Le type d'ordonnancement adopté repose finalement sur le maintien d'une liste des évènements à traiter dans l'ordre croissant de leur datation. A chaque itération de l'ordonnanceur, l'évènement en tête de cette liste en est retiré pour être traité. Le temps propre du simulateur correspond à la date de cet évènement, sans aucun rapport, ni avec l'évolution de l'horloge murale, ni avec le temps effectif mis par les tâches pour être exécutées.