Conception des systèmes réactifs par l’approche Synchrone
II.4 Compilation d’Esterel vs Light Esterel
4.2 Compilation Light Esterel
Le langage Light Esterel a été crée principalement dans le but de permettre la compilation modulaire. En effet, l’intérêt majeur de la compilation modulaire est de pouvoir compiler sépa-rément chaque sous système (parallèle et dépendant) et permettre ainsi de modifier ou d’ajouter un module sans recompiler le système complet. Cela permettra également dans l’avenir de réa-liser une simulation modulaire. Le compilateur du langage Light Esterel (LE) appelé "CLEM" s’appuie bien entendu sur la sémantique équationnelle du langage LE. Il met en œuvre les principales règles sémantiques afin de compiler chaque programme en un système d’équations correspondant. Le principe de cette compilation est similaire à celui du langage Esterel par la mise en œuvre d’une sémantique constructive basée sur les circuits. Par contre, cette sémantique permet une interprétation en un circuit séquentiel quadri-valué en Light Esterel plutôt qu’un circuit tri-valué dans le cas d’Esterel. Ceci permet un calcul plus simple des valeurs des signaux dans LE car l’algèbre quadri-valué choisie est bien adaptée pour gérer les sur-spécifications tel que le cas où un signal est vrai et faux au même temps. La figure II.9 montre la réécriture de l’instruction "await" en LE.
La figure II.10 montre la réécriture du programme ABO en Light Esterel. Cette réécriture, contrairement à Esterel, garantit une partie synchronisation fixe qui ne dépend pas du nombre
II.4 Compilation d’Esterel vs Light Esterel
Figure II.9 – Réécriture de l’instruction "await" en Light Esterel.
de préemptions imbriquées. Le prix à payer est par contre l’ajout d’un registre de plus par branche parallèle pour conserver l’état présent. Ce choix est justifié par la volonté de conserver le caractère incrémental de la compilation Light Esterel. A l’encontre de la compilation Este-rel, aucune retouche n’est nécessaire par la suite et les différents blocs peuvent être compilés séparément.
Figure II.10 – Compilation du programme ABO en Light Esterel
Assurer une compilation séparée d’un langage synchrone nécessite absolument l’utilisation d’un ordre d’évaluation valable pour tous les instants. Généralement, cet ordre est statique dans la plupart des langages synchrones populaires, évitant toute compilation séparée. Ce problème a été résolu par la mise au point d’un ordre partiel incrémentiel afin de rompre la liaison entre deux signaux indépendants. A cet effet, deux principales variables entières ont été définies pour chaque équation, à savoir (CanDate , MustDate) pour enregistrer la date de l’évaluation d’une équation. La "CanDate" caractérise la première date à laquelle l’équation peut être évaluée. Tandis que, La "MustDate" caractérise la dernière date à laquelle l’équation doit être évaluée. Ces dates varient dans une échelle de temps discrets appelés niveaux. Le niveau 0 caractérise les premières équations à évaluer puisqu’elles dépendent de variables libres, alors que le niveau
n +1 caractérise les équations qui nécessitent l’évaluation des variables de niveaux inférieurs (de n à 0). Les équations de même niveau sont indépendantes et donc peuvent être évaluées quel que soit l’ordre choisi. En effet, un couple de niveaux est associé à chacune des équations. Cette méthode est inspirée de la méthode PERT [KC66] qui permet de traiter les ordres partiels dans des systèmes d’équations au lieu de s’aligner avec un ordre arbitraire total. La figureII.11
[RG11] montre le graphe de dépendance des variables correspondant aux équations II.1et II.2
dans lesquelles chaque variable X est reliée à toute variable X’ dont elle dépend pour être évaluée. Ce graphe montre les deux dépendances can(X) et must(X) de chaque variable X, où les nombres 0, 1, 2 et 3 présentent les dates logiques. Par exemple, en dépendance MustDate, l’action "t" ne peut se faire qu’à l’instant 2 car elle dépend de l’action "c" qui se fait à l’instant 1. Tandis qu’en dépendance CanDate, les dates sont inversées et "t" peut se faire plus "tard".
must(can(a)) = a, t, c (II.1)
can(must(a)) = a, b (II.2)
Figure II.11 – CanDate et MustDate
La figure II.12 [RG11] montre la chaine de compilation CLEM. A partir du code en Light Esterel, CLEM génère un format d’enregistrement appelé format "LEC" pour enregistrer le système d’équations booléennes sous forme de BDD généré à partir du programme Light Esterel ainsi que leurs dates d’évaluation des variables (CanDate et MustDate). Dans la pratique, le compilateur CLEM génère le format LEC dans le but de pouvoir réutiliser d’une manière plus efficace le code déjà compilé grâce à la méthode PERT citée précédemment. Dans la phase finale de compilation, le format "LEC" peut être traduit vers différentes cibles logicielles et
II.4 Compilation d’Esterel vs Light Esterel
matérielles(code C, code Vhdl, synthétiseurs FPGA, Blif). Le format BLIF "Berkeley Logic Interchange [Uni98] est un format bien adapté pour l’application des d’outils de vérification par la suite. C’est un format très compact pour représenter les netLists (citcuits logiques) auxquels CLEM a ajouté des moyens syntaxiques pour pouvoir enregistrer la "CanDate" et "MustDate" de chaque variable.
Figure II.12 – Chaîne de compilation Light Esterel .
Pour conclure, la compilation Light Esterel offre deux principaux avantages :
- Elle garantit la modularité en assurant une liaison efficace de deux ordres partiels, sans avoir besoin de s’engager dans un re-calcul de l’ordre partiel global. En effet, il suffit de relier le module principal du système d’équations avec un sous-module déjà compilé (appelé à partir d’une instruction d’exécution), dans ce cas l’opération de liaison est assurée avec le simple ajustement des dates de leurs variables communes.
- Elle offre également la possibilité de vérifier le comportement d’un système étudié. Comme il a été décrit dans le début de ce chapitre, vérifier formellement la correction d’un système consiste à s’assurer que la modélisation de sa structure satisfait la formule décrivant le
compor-tement attendu. Cette formule est généralement écrite en se basant sur une logique temporelle dans la plupart des techniques existantes de vérification de modèle. Dans ce contexte, la sé-mantique équationnelle du langage Light Esterel "LE" offre un système d’équations qui encode l’ensemble des comportements du programme. Par la suite, une translation est réalisée du pro-gramme LE compilé en un format SMV [CCGR00] qui est l’entrée du model checker "NuSMV" [CCGR00] assurant ainsi la vérification des propriétés du langage LE. En effet, il existe peu d’approches qui considèrent la compilation modulaire à cause d’un désaccord profond entre la causalité et la modularité. La causalité signifie que pour chaque évènement généré dans une réaction, il existe une chaîne causale d’évènements amenant à cette génération. La plupart des langages synchrones s’intéressent attentivement à la vérification de la causalité de leurs pro-grammes. Ainsi, s’appuyer sur une sémantique pour compiler un langage assure une approche modulaire, mais nécessite de compléter le processus de compilation avec une vérification glo-bale de causalité. L’originalité de la compilation Light Esterel repose sur la façon de vérifier la causalité à partir des sous-programmes déjà vérifiés et sur l’approche modulaire adaptée.