Brevet FR2712710A1 — publié le 19950524

PROCEDE DE DESCRIPTION DE CHRONOGRAMME ET DISPOSITIF PERMETTANT LA MISE EN OEUVRE DU PROCEDE. La présente invention concerne un procédé de description de chronogramme et le dispositif permettant la mise en oeuvre du procédé. Il est connu notamment dans le domaine des automates programmables de faire afficher à l'écran un chronogramme ou le circuit logique correspondant à un chronogramme en appuyant directement sur les touches d'un clavier permettant de faire apparaître des fonctions ET/OU et de relier ces fonctions par des noeuds. Toutefois, ce type de dispositif ne permet pas une grande flexibilité car il est limité aux chronogrammes de type logique et ne s'adapte pas quelque soit le chronogramme. En outre, il ne permet pas la construction d'un chronogramme en agissant directement de façon interactive entre l'affichage d'un curseur représentant le déplacement d'une souris et les actions exécutées au clavier ou sur le bouton de la souris pour modifier et faire évoluer le chronogramme. Le but de l'invention est de palier ces inconvénients. Un tel but peut être atteint par le fait que ces chronogrammes reposent sur un procédé de description original à l'aide d'un arbre syntaxique consistant à définir le chronogramme par des objets comportant des types et des attributs, et des objets de type différent étant reliés entre eux par une logique arborescente comportant des noeuds ET/OU entre les ramifications. Selon une autre particularité, il y a deux classes d'arborescence, primitives et évoluées. Selon une autre particularité, I'arborescence comporte à sa base la définition d'un objet de type "SCENE" qui se compose d'objets de type "terme"; d'objets de type "liste"; 35. d'objets de type "aire de synchronisation"; et d'objets de type "horloge". Selon une autre particularité la liste d'aire de synchronisation est dynamique. Selon une autre particularit la liste d'aire de synchronisation est statique. Selon une autre particularité la liste d'aire de synchronisation coporest statique. Selon une autre particularité la liste d'aire de synchronisation comporte un emplacement relatif et une configuration (pattern) qui est une liste non vide. Selon une autre particularité ladite configuration est formée d'une ligne de base qui comporte un terme, un objet de type terme et la configuration des intervalles de base. Selon une autre particularité, la configuration des intervalles de base comporte l'emplacement d'un segment dont le type est l'union d'un objet de type événement binaire, d'un objet de type valeur stable binaire et d'un objet statut dont le type est un segment. Selon une autre particularité, les objets de type segment ont des attributs qui permettent la définition de la longueur et la position du segment. Selon une autre particularité, les objets de type événement binaire (B event) définissent un filtre de configuration par rapport aux transitions possibles des articles (item) associés avec la ligne à laquelle l'intervalle appartient. Selon une autre particularité les objets de type valeur stable binaire (B stabel Val) définissent un filtre de configuration par rapport aux valeurs possibles des articles associés avec la ligne à laquelle l'intervalle appartient. Selon une autre particularité, le procédé permet la description de chronogramme simple ou de chronogramme évolué. Selon une autre particularité, un chronogramme de type simple comporte deux scènes dont une première constitue l'hypothèse et une deuxième la conclusion. Selon une autre particularité, un chronogramme évolué comporte une scène et autorise la création des liens logiques entre les différentes lignes de la scène et ou les différents intervalles d'une ligne. Un autre but est de proposer un dispositif permettant la mise en oeuvre du procédé. Ce but est atteint par le fait que le dispositif comporte un contrôleur d'édition d'une part autorisant exclusivement la création de préfixe d'arbre valide, et d'autre part associant à chaque objet composant l'écran une fonction contrôleur syntaxique qui filtre les actions réalisées par l'association, à chaque objet, d'une liste de méthodes correspondant aux différentes actions que l'utilisateur effectue à l'aide de la souris ou du clavier, cette liste de méthodes permettant pour chaque objet d'interpréter différemment les stimuli fournis par la souris et/ou le clavier Selon une autre particularité, une interface souris et clavier permet de reconnaître le stimulus appliqué et l'objet sur lequel est appliqué le stimulus pour éliminer le stimulus non acceptable pour un objet et pour les autres d'envoyer vers le contrôleur un message qui sera interprété suivant l'objet et le stimulus envoyés. Selon une autre particularité, le contrôleur d'édition traduit chaque unité graphique en une succession de noeuds selon le procédé et à chaque noeud est associé une table de méthode valide, le contrôleur comporte une fonction permettant d'une part d'associer à chaque objet sur lequel un stimulus est appliqué, un message destiné à un noeud unique de l'arbre syntaxique et d'autre part de vérifier que la méthode associée au stimulus correspond à une méthode valide pour le noeud puis à exécuter la méthode pour mettre à jour l'arbre syntaxique et effectuer la mise à jour de l'affichage. Selon une autre particularité, chaque message est un couple composé par une identification de l'objet graphique et par un type d'actions à exécuter. Selon une autre particularité, un préfixe est associé à chaque noeud de l'arbre, ledit préfixe permettant d'effectuer la mise à jour de l'image graphique en définissant l'état de l'édition. D'autres particularités et avantages de la présente invention apparaîtront plus clairement à la lecture de la description ci-après faite en référence aux dessins annexés, dans lesquels: La figure 1 représente de façon schématique la structure fonctionnelle de l'invention; La figure 2 représente de façon schématique la structure physique de l'invention; La figure 3 représente l'arborescence d'un cnronogramme développé, notamment dans le cas d'un chronogramme de type évolué; Les figures 3A à 3J représentent le détail de cette arborescence associée avec la représentation des éléments de scène correspondants; 0o La figure 4 représente l'organigramme d'un chronogramme de type primitif; Les figures 4A à 4D représentent les détails de l'organigramme d'un chronogramme primitif avec à chaque fois les scènes ou les éléments décrits associés La figure 5 représente la scène d'un chronogramme évolué correspondant à une application; La figure 6 représente de façon schématique les différentes actions possibles par l'utilisateur pour modifier le chronogramme; Les figures 7A et 7B représentent les conséquences de ces actions qui illustrent le mécanisme d'édition. La figure 8 représente les actions possibles sur les zones du chronogramme à l'aide de la souris selon le bouton actionné. La structure fonctionnelle de la figure 1 est constituée d'un système informatique comportant un dispositif d'affichage 5 sur lequel peuvent être affichés des chronogrammes au fur et à mesure de leur création et un clavier 3 associé à une souris 4 permettant des interactions avec le système informatique. Le système informatique comporte un disque dur 10 sur lequel les fichiers sont sauvegardés. Sur ce système informatique vont être exécutés des programmes qui permettront par l'utilisation d'une grammaire 13 et de données lexicographique de générer un arbre syntaxique 12 minimum et de faire croître cet arbre syntaxique au fur et à mesure de l'évolution du chronogramme 2 d'une application donnée qui est affiché dans la fenêtre du dispositif d'affichage 5. Ce chronogramme 2 évolue à la suite des actions effectuées par l'utilisateur soit au clavier, soit avec la souris 4. Pour ce faire, la structure fonctionnelle du dispositif de l'invention utilise un programme d'éditeur d'interface 14 qui coopérera avec un programme contrôleur 16 écrit dans un langage spécifique à la description de chronogrammes. Ce programme contrôleur 16 est interfacé avec le programme éditeur 14 à travers une interface 15 écrite en langage C. Le programme contrôleur 16 utilisera au cours de son exécution des tables 101 qui sont sauvegardées dans le disque dur 10. Comme on pourra le voir plus en détail dans la demande de brevet français déposée par la requérante le 22 juillet 1992 sous le numéro: 9209057 et intitulée "Utilisation d'un langage à interprète embarqué pour la réalisation d'un outil interactif de définition d'interface utilisateur", I'éditeur d'interface 14 reçoit les stimuli du clavier 3 ou de la souris 4. Ces stimuli précisent l'origine, c'est-à-dire la position de la flèche d'indication sur l'écran et ainsi que la touche d'émission qui peut être soit un bouton de la souris, soit une touche d'une clavier. Un interprèteur en langage objet tel que WOOL construit un message pour le contrôleur 16 qui en fonction de l'arbre syntaxique et du message modifie l'arbre syntaxique et envoie un message à l'éditeur d'interface 14 en langage WOOL pour permettre l'affichage de l'arbre modifié. L'outil de génération d'interface (14) couvre la couche présentation qui décrit de façon statique l'ensemble des objets constituant une interface c'est-à-dire leur hiérarchie, leur attribut et la couche dialogue qui décrit l'aspect dynamique de l'interface, c'est-à-dire son comportement. Cet outil générateur d'interface comporte un interpréteur du type "LISP" écrit en langage C et dénommé "WOOL" dans lequel la mémoire est gérée explicitement par compteur de références et qui comporte un typage interne permettant la vérification de type, le déclenchement de procédures par envoi de messages conformément à une approche orientée objet. L'interpréteur fournit un ensemble de type de données de base tel que "atome, liste, nombre entier, nombre réel, chaîne de caractères". Chaque objet dans le langage de l'interpréteur WOOL est formé d'une entête qui comporte un pointeur sur la classe qui est le type de l'objet et le compteur de référence, et enfin d'autres informations qui sont les attributs dépendants de l'objet. Le type de l'objet permet d'accéder dans le noyau de l'interpréteur à une classe qui contient une liste de méthodes, chaque méthode est une fonction telle que par exemple la fonction "Print" ou d'autres fonctions. La structure de l'outil de génération d'interface se caractérise par une boucle principale de lecture de l'entrée qui distribue les événements (clic souris, action clavier) reçus aux différents composants du programme. L'interprète WOOL du générateur d'interface ne contient pas la boucle principale de l'application qui reste contrôlée par l'application (16). Cette boucle est chargée d'appeler la fonction de "lecture motifs" puis de distribuer l'entrée reçue, cela signii;e qu'il existe un niveau de programmation o l'on peut décider pour chaque événement quelle entité est chargée de traiter l'événement: ce peut être le générateur d'interface (14) ou bien le contrôleur de l'application (16) qui permet de générer les chronogrammes. Le fonctionnement du dispositif repose donc sur un procédé de description d'un arbre syntaxique et d'autre part sur la construction incrémentale de l'arbre syntaxique et sa compilation au fur à mesure. La grammaire 13 décrit l'ensemble de tous les arbres possibles et par l'utilisation de cette grammaire, le contrôleur 16 sait le genre d'arbre qu'il peut construire et jusqu'o il peut le construire. A l'initialisation du système le contrôleur 16 fait apparaître un préfixe d'arbre syntaxique qui permet la représentation à l'écran d'un chronogramme minimum tel qu'on le verra ci-après. Un chronogramme permet la description d'une contrainte logique temporelle qu'un système doit respecter. Sa représentation à l'écran se fait dans le cas d'un chronogramme évolué représenté à la figure 5 par un affichage qui comporte au moins une scène ou deux scènes dans le cas de chronogrammes primitifs. Chaque scène est une liste d'aires, une aire 23 est une liste de lignes 24 à 27 et une ligne est une liste d'intervalles 271, 274. Un chronogramme évolué tel que celui représenté à la figure 5 est constitué d'éléments de type différent, les parties grises telles que les surfaces 20, 21, 22, 23 qui sont affichées par le gestionnaire de fenêtres hôte mais qui ne participent pas à la définition même du chronogramme, et de surfaces à fond blanc qui sont organisées en lignes. Le chronogramme de la figure 5 comporte une ligne d'horloge 24, et des lignes d'identificateurs ayant même statut et constituant par exemple deux lignes d'états 25A, 25B, une ligne d'entrée 26 et une ligne de sortie 27. La première ligne 24 qui constitue la ligne d'horloge est composée de quatre zones: une première dans laquelle est inscrite l'identificateur de la ligne, en l'occurrence "horloge"; et une deuxième zone 241 qui comporte des créneaux. Cette zone de créneau définit une bande verticale traversant le chronogramme dans toute sa hauteur. Une telle bande verticale 241 est appelée "aire statique" ou "multicolonnes statiques". Une autre aire statique 242 est définie par la zone de créneau à droite du chronogramme. La zone intermédiaire 243 définit également une aire de statut différent. Il s'agit d'une aire dynamique ou multicolonne dynamique. Les quatre lignes suivantes 25A, 25b, 26, 27 sont composées chacune de deux zones. Dans les zones de gauche 250, 260; 270, sont inscrits les noms des articles ou rubriques auxquels sont consacrées les lignes. Une rubrique est attribuée par ligne, mais plusieurs lignes telles que 25A, B peuvent être consacrées au même article. Les zones de droites longues 251, respectivement, 261, respectivement 271 sont remplies par des intervalles. Pour la ligne consacrée à la rubrique appelée "sortie" 27, nous pouvons distinguer deux intervalles, 271 274 "Val", large chacun d'un cycle d'horloge puis un intervalle 272 large de 4 cycles d'horloge et portant la mention "Vert". Enfin, entre les deux figurent quatre intervalles 273 portant la mention "H P (hors propos)" (irrelevant). Ces intervalles se répartissent en trois classes La première classe est composée des intervalles qui expriment des contraintes sur des valeurs. Ils indiquent que l'article (item) de la ligne qui porte l'intervalle doit avoir aux cycles d'horloge sur lesquels l'intervalle est posé, la valeur mentionnée par exemple "Vert" pour l'intervalle 272 de la ligne sortie ou jaune pour l'intervalle 260 de la ligne entrée. La deuxième classe est composée des intervalles 271 274 qui expriment des contraintes sur des valeurs symboliques. Cette valeur symbolique est figurée par le symbole "Val" et n'est jamais définie explicitement. La troisième classe est composée d'intervalles non significatifs et porte la mention "H P" pour indiquer que ces intervalles ne sont pas significatifs (irrelevant). Enfin il existe une dernière classe d'intervalles qui permet de définir des contraintes sur les changements de valeur, cette classe n'est pas représentée sur la figure 5 mais apparaît dans l'arbre syntaxique comme on le verra ultérieurement. Dans une scène définie par la matrice que l'on peut obtenir en alignant de la sorte des intervalles et des lignes, on pourra sélectionner toute partie de scène tenant dans un rectangle, par exemple, un intervalle en tronçon de ligne, plusieurs tronçons de lignes égales exactement superposées et appartenant à des lignes différentes, de façon h ce qu'il constitue un bloc et cet intervalle apparaîtra avec un cadre en trait gras tel que l'intervalle 262 de la ligne entrée 26. Chaque bloc ainsi constitué permet de définir à l'aide d'un ou plusieurs blocs 262 253 254 une propriété qui est obtenue en tirant une flèche 281 282 d'un ou plusieurs blocs vers un ou plusieurs blocs. Les blocs 262 253 du côté io sans chevrons de la flèche forment l'hypothèse et ceux 254 placés du côté avec chevrons forment la conclusion. Ainsi on peut voir que si en ENTREE on a la valeur "Jaune" représentée par l'intervalle 262 et en ETAT on a la valeur "Bleu" représentée par l'intervalle 253 la propriété définie par les flèches 280, 281 indique que dans cette hypothèse on aboutit à la valeur "Vert". La flèche 283 définit une autre propriété entre l'intervalle 251 de couleur "brun" et l'intervalle 252 de couleur "brun". Cette propriété dit "lorsque l'on est brun, à un moment donné, on reste brun". Un chronogramme évolué 200 (fig. 6) peut être scindé en au moins deux chronogrammes primitifs 201, 202, le premier 201 comportant au moins une ligne d'entrée et le second 202 comportant au moins une ligne de sortie 207, chaque chronogramme primitif comportant une ou plusieurs lignes d'état 205. Ainsi tous chronogramme évolué peut être expansé dans des chronogrammes primitifs, chaque chronogramme primitif représentant une propriété définie dans le programme chronogramme évolué. Ces chronogrammes primitifs sont développés dans le langage primitif qui lui est stable dans sa structure syntaxique minimale et aussi complet que possible dans sa puissance d'expression. Les chronogrammes primitifs sont construits à l'aide de deux scènes du même type que celles qui servent à la construction de chronogramme évolué. Quand ces scènes sont utilisées pour construire un chronogramme primitif, il n'est pas possible d'y sélectionner des intervalles pour en faire des blocs, et par conséquent, il n'est possible d'y définir des propriétés à l'aide de flèche. Le chronogramme primitif lui-même définit une et une seule propriété. Les deux scènes constituant un chronogramme primitif sont placées l'une au- dessus de l'autre. La scène du haut 201 définit l'hypothèse, alors que la scène du bas 202 définit la conclusion. Le positionnement relatif des scènes "hypothèse" et "conclusion" est fondamental. Il définit la synchronisation des événements décrits dans l'hypothèse et des événements décrits dans la conclusion. La largueur des scènes, c'est-à- dire le nombre de cycles d'horloge, qui sont dessinés est calculé en fonction de la propriété qui doit y être expansée. Ces chronogrammes primitifs ont été utilisés au départ pour réaliser un éditeur de chronogramme qui possède de bonnes propriétés de minimalité, de complétude compilable et à syntaxe stabilisée. Ceci à permis d'évoluer vers les chronogrammes évolués à forte ergonomie et flexibilité pour développer un éditeur de chronogramme évolué. Dans les deux cas la méthode a été la même à partir des objets graphiques disponibles dans l'éditeur d'interface WOOL permettant de définir les fenêtres, les ascenseurs verticaux et horizontaux et io des objets boutons qui sont associés à chaque ligne pour définir dans la ligne la rubrique, I'intervalle. Par l'utilisation de l'arbre syntaxique, dont le rôle sera étudié ultérieurement, est rajouté sur les objets correspondants aux boutons associés à une ligne une spécialisation selon la destination du bouton, intervalle, bloc, aire statique, aire dynamique, etc... et à cette spécialisation définie par un autre objet est associée une liste de méthodes qui sont les actions possibles par l'éditeur 14. L'arbre syntaxique d'un chronogramme peut être du type soit primitif, soit évolué et le chronogramme de l'arbre évolué est représenté à la figure 3. Le chronogramme d'un arbre primitif est représenté à la figure 4. A cet arbre syntaxique est associé une routine affichage lancée à l'initialisation du système qui permet par l'affichage de demander à l'utilisateur s'il souhaite appeler un chronogramme déjà enregistré ou un nouveau chronogramme, et dans le cas d'un nouveau chronogramme s'il choisit un chronogramme évolué ou primitif. Dans ce cas là, le contrôleur 16 construit un préfixe d'arbre syntaxique qui permet l'affichage par l'éditeur d'un début de chronogramme représenté dans une fenêtre et comportant les informations minimales que l'on a vu ci-dessus. Si le chronogramme est évolué, celui-ci est constitué de scènes comme représenté à la figure 3A, et selon le cas de listes de propriétés. Les scènes sont constituées, comme représenté à la figure 3B, de jeux de termes identificateurs par exemple X, Y, Z permettant de préciser les affectations des scènes. Dans l'exemple représenté, un terme identificateur "entrée, état, sortie" est affecté en vis à vis de chaque ligne et à chaque ligne est associée une liste soit d'aires statiquement synchronisées "StaSynA" soit d'aires dynamiquement synchronisées "DynSynA". Une scène est également constituée d'une ligne d'horloge. Une aire synchronisée dynamiquement est constituée d'un champ emplacement défini par une contrainte indiquant un rang et une contrainte indiquant une largeur de segment et d'autre part par un champ modèle (pattern) constitué d'une liste de lignes comme représenté à la figure 3C. On notera que la largeur pour d'autres applications peut être laissée libre dans un intervalle éventuellement non borné à droite. Une aire synchronisée statiquement est constituée également par l'emplacement et par le modèle. Une ligne est définie comme représenté à la figure 3G par un 0o terme et un modèle constitué d'une liste d'intervalles. Un intervalle est défini comme représenté à la figure 3F par un champ emplacement définissant une contrainte de type segment et une contrainte de type état qui peut être formée par l'un des objets suivants: événement; valeur stable; et H. P (hors propos). Un événement est constitué comme représenté à la figure 3H, d'une part par un champ définition dont l'expression définit une contrainte qui est la prise d'une couleur dans le cas d'un chronogramme décrivant les changements de couleur en fonction des étapes précédentes et d'autre part par champ signification qui est le moment de la transition. Le graphe qui définit le type événement représenté à la figure 3H comporte en outre un champ optionnel nommé "signe" qui vaut le complémentaire. Ce champ décrit le pendant en mémoire du tiret qui peut affecter la mention de certain intervalle. La signification de ce tiret est que le signal est contraint à porter une valeur appartenant au complémentaire de la valeur mentionnée dans l'intervalle. Le type de données "StableVal" est défini par le graphe de la figure 3G. Ce type décrit la forme sous laquelle la contrainte définie par l'intervalle est représentée en mémoire machine pendant une session d'édition de chronogramme. Ce type "StableVal" comporte un champ "signification" qui est la valeur stable pour signifier qu'il s'agit de contrainte sur valeur stable. Ce type admet également un champ optionnel nommé définition lorsqu'en mémoire ce champ reste vide, la contrainte est simplement la stabilité du signal lorsqu'il porte une valeur la contrainte est plus forte: la valeur haute signifie que la valeur portée doit être la valeur haute, bas signifie que la valeur portée doit être la valeur basse, B logic signifie que la valeur portée est définie par une expression booléenne associée à l'intervalle. Il Un segment est constitué comme représenté à la figure 31 par une limite supérieure, une limite inférieure, une valeur Z, et un état qui peut être ouvert ou fermé. Un chronogramme évolué comporte également une fois que l'on a construit la scène du chronogramme, une liste de propriétés binaires qui permettent de relier entre elles les différents intervalles des différentes lignes. Ces propriétés binaires comportent une hypothèse, une conclusion, une relation. La relation est 1o une opération binaire et l'hypothèse composée d'éléments formés d'une liste de bloc, un bloc étant un intervalle sélectionné par la souris pour constituer une hypothèse ou une conclusion. Les différents éléments d'une hypothèse sont composés avec des opérateurs qui sont soit des opérateurs OU, soit des opérateurs ET. La conclusion d'une propriété binaire est également constituée d'une liste de bloc comme représenté à la figure 3J. La figure 4 représente l'organigramme d'un chronogramme primitif et les figures 4A à 4D représentent la description des parties de chronogramme spécifiques à ces chronogrammes primitifs. Les autres éléments qui sont similaires aux éléments du chronogramme évolué ne seront pas décrits et représentés. Un chronogramme primitif comme représenté sur la figure 4 est d'abord une propriété binaire de base (Bas.bina PP) qui comporte un haut et un bas constitué chacun par une scène de base (basic scene). Chaque scène de base est constituée comme représentée à la figure 4A d'une horloge, d'une liste et d'un jeu de terme. La liste est constituée d'aires de base statique (StaBasA) et d'aires de base dynamique (DynBasA), comme représentée à la figure 4B. Les aires statiques de base comportent (Figure 4B) un modèle formé d'une liste de lignes de base et un emplacement constitué par l'indication du rang et de la largeur de I'aire. De même une aire dynamique de base est constituée de l'emplacement indiqué par son rang et sa largeur et d'un modèle formé d'une liste de lignes de base. Ces lignes de base sont constituées d'un modèle formé d'une liste d'intervalles de base, dont la place est indiquée par un segment, et l'état indiqué par une valeur stable de base ou un événement de base. La ligne de base est également constituée d'un article formé par le terme spécifiant la ligne de base. Le type de données valeur de base stable "Bstable val" est défini par le graphe de la figure 4C. Ce type décrit la forme sous laquelle la contrainte définie par l'intervalle est représentée en mémoire machine pendant une session d'édition de chronogramme. Le type "B stable val" comporte un champ "signification" qui est la valeur stable pour signifier qu'il s'agit de contrainte sur valeur stable. Ce type admet également un champ optionnel nommé définition. Lorsqu'en mémoire ce champ reste vide, la contrainte est simplement la stabilité du signal, lorsqu'il porte une valeur la contrainte est plus forte: la valeur "haute" signifie que la valeur portée doit être la valeur haute, "bas" signifie que la valeur portée doit être la valeur basse, B logic signifie que la valeur portée est définie par une expression booléenne associée à l'intervalle. La figure 4D représente le graphe qui définit pour le type événement de base "B event", la représentation mémoire des contraintes sur les changements de valeur. Ce type a deux champs, "signification" et "définition". Le champ "signification" qui a la valeur événement et signifie qu'il s'agit de contrainte sur changement de valeur. Le champ "définition" est obligatoire, contrairement au champ de même nom du type valeur stable de base "B stable Val". Ce champ par la valeur qu'il porte définit le type exact de la contrainte: à savoir transition (egde) signifie que le signal doit changer une et une seule fois de valeur; montant (rising) signifie que le signal doit avoir un et un seul front montant sans condition de contraintes sur les fronts descendants; descendant (falling) signifie que le signal doit avoir un et un seul front descendant sans conditions de contraintes sur les front montants. Le graphe qui définit le type événement est représenté à la figure 3E et comporte un champ optionnel nommé "signe" et dont la valeur est"complémentaire". Ce champ décrit le pendant en mémoire du tiret qui peut affecter la mention de certain intervalle. La signification de ce tiret est que le signal est contraint à porter une valeur appartenant au complémentaire de la valeur mentionnée dans l'intervalle. Il en résulte que la structure abstraite du langage chronogramme est constituée par la structure de donnée constituée par les contraintes imposables à chaque type d'objet du chronogramme auxquelles on associe une liste de méthodes utilisables par le programme d'édition. En mémoire centrale, seules des données conformes à cette structure peuvent être chargées pendant une session d'édition. Cette structure de donnée est une structure en arbre qui forme l'arbre syntaxique ou arbre de réduction. Le rôle de l'éditeur de chronogramme est de permettre la construction de ces arbres. Le contrôle de l'édition (16) interdit par construction la saisie de toutes données qui ne seraient pas conformes à la structure syntaxique, ce qui a pour conséquence que l'éditeur de chronogramme est dirigé par la syntaxe. Par cette structure d'arbre, l'éditeur (14) est paramétré lexicographiquement (par les articles, les états, etc...) et sémantiquement par l'échelle de temps, les propriétés et les liens. Les liens donnés au cours de la spécification de l'éditeur seront globaux à tous les scénarios, ils seront donc automatiquement ajoutés à la liste des contraintes des intervalles reconnus comme étant en instance de définition de l'intervalle et de l'article (item) contrainte. Ces liens permettront de réaliser dynamiquement un début d'analyse sémantique du scénario en empêchant l'utilisateur de base d'éditer des comportements erronés dans un scénario. Par exemple dans S1 l'éditeur de chronogramme, il est impossible de créer des intervalles ayant un statut de la classe événement (transition, montant, descendant) et de longueur inférieure à 2 unités de temps car cela n'a aucun sens (la transition devant se réaliser strictement à l'intérieur de l'intervalle). Dans ce cas là, on a donc une contrainte sur la distance séparant la borne inférieure et la borne supérieure de tout intervalle ayant un statut faisant partie de la classe des événements. Cette contrainte est que la distance séparant la borne inférieure de la borne supérieure de l'intervalle doit être supérieure ou égale à deux. Les figures 7A, 7B illustrent les étapes essentielles d'une action d'édition. Il s'agit en ce cas de modifier la contrainte définie pour un intervalle 254. Pour ce faire, il faut sélectionner l'action à effectuer, puis sélectionner l'intervalle concerné dans le chronogramme et induire l'action. En réaction l'éditeur (14) doit interpréter l'ordre d'agir, c'est-à-dire la méthode ou la procédure à appliquer, repérer ce sur quoi il faut l'appliquer et appliquer la méthode. Dans le cas de la modification de la contrainte définie pour un intervalle, la méthode consiste à positionner le curseur de l'écran sur le point de l'écran correspond au noeud de l'arbre syntaxique représentant en mémoire centrale, I'intervalle concerné. Pour ce faire, le programme WOOL transforme les stimuli émis par la souris en fonction de sa position et du bouton enfoncé en message destiné au contrôleur (16) d'édition qui va par les coordonnées du point sur l'écran permettre de repérer dans l'arbre syntaxique l'élément qui correspond à ce point. Les coordonnées permettent ainsi d'adresser en mémoire centrale l'intervalle concerné qui représente le noeud de l'arbre syntaxique. Ensuite il faut modifier comme il convient le sous-arbre issu de ce noeud et lancer la procédure de mise à jour de l'écran. Avec certains éditeurs, I'utilisateur devait sélectionner explicitement à l'aide d'un menu en marge d'écran l'action de modification, sélectionner sur l'image du chronogramme en construction l'intervalle à modifier, puis sélectionner à l'aide d'un menu déroulant la nouvelle contrainte à associer à cet intervalle. Les trois actions nécessitées par ces éditeurs exigeaient de mener le curseur de la souris successivement à hauteur du menu en marge, dans la fenêtre o se trouve l'image du chronogramme et à hauteur du menu déroulant o sont décrites les différentes contraintes. L'utilisation d'accélérateur pouvait simplifier la vie de l'utilisateur et éviter l'utilisation d'un menu déroulant pour réduire les manipulations de la souris. Cependant, la technique antérieure posait rapidement à l'utilisateur des problèmes de mémorisation des différents accélérateurs qui peuvent devenir très nombreux si la technique est systématisée. En outre, une telle approche n'apporte aucune aide d'apprentissage à l'utilisateur. En effet, pour les différents modes possibles, la modification, I'insertion, la destruction, etc... sélectionnable à priori, I'utilisateur doit apprendre à quoi chaque mode est applicable. Inversement, considérant un intervalle, une aire ou multicolonne, un créneau d'horloge, I'utilisateur devait dans les éditeurs antérieurs pouvoir s'enquérir de ce qu'il était possible de faire. Pouvait-on modifier la contrainte associée à un intervalle, pouvait-on déplacer un intervalle sur la gauche ou sur la droite, ou insérer une aire, ou détruire un créneau d'horloge. Dans le cadre de l'éditeur de l'invention, une utilisation systématique de la structure abstraite du chronogramme permet la mise au point d'un éditeur sans mode aux vertus pédagogiques et d'efficacité remarquable. A chaque classe de noeud de la structure syntaxique abstraite est associée I'ensemble des méthodes d'édition qui la concerne. Une des méthodes consiste à afficher une notice explicative concernant les noeuds de la classe. L'éditeur de l'invention est un éditeur à objet et à chaque classe de noeud est associé une classe de bouton au sens des boutons qui s'affichent sur l'écran dans les environnements multifenêtres X-WINDOWS par exemple. Les boutons peuvent avoir différentes formes, celle d'un intervalle pour les boutons appartenant à la classe des boutons associés à la classe du noeud intervalle, celle d'un créneau pour les boutons appartenant à la classe de bouton associé à la classe du noeud créneau d'horloge, etc... pour chaque bouton associé à la classe d'un objet de l'arbre syntaxique. L'image d'un chronogramme présentée à l'écran est une représentation exacte de l'arbre syntaxique chargé en mémoire centrale. Cette image correspond également à une palette de boutons pour l'éditeur WOOL. Chacun des boutons peut être excité de plusieurs façon dont une consiste à l'exciter par la méthode applicable au noeud associé. Pour exciter un bouton le curseur de la souris étant placé sur ce bouton, on peut appuyer sur une touche du clavier ou sur une des touches de la souris elle-même. Par exemple, la touche de la lettre h déclenche systématiquement l'affichage de la notice explicative concernant le noeud associé au bouton concerné. L'image écran du chronogramme est donc un menu. Les stimuli émis par la souris sont interprétés différemment selon le type de l'objet stimulé car pour chaque objet graphique deux filtrages sont réalisés 1S sur les différents stimuli possibles. Tout d'abord le contrôleur (16) élimine tous les stimuli qui ne doivent avoir aucun effet sur l'objet concerné, puis pour les autres, il envoie un message qui sera interprété suivant l'objet sur lequel l'utilisateur est en train de pointer et le type de stimulus que l'utilisateur a envoyé. La figure 6 représente quelques exemples d'excitation possibles des boutons du chronogramme. Sur cette figure, on peut voir par exemple que lorsque la souris pointe dans la zone (240) comportant le terme "horloge", I'action sur le bouton retour/chariot affecte à cette zone le signal "horloge". Sur cette même figure lorsque le curseur de la souris pointe sur un créneau (241) représentatif du signal d'horloge l'action sur le bouton 1 de la souris permet l'insertion d'une impulsion d'horloge et l'action sur le bouton 2 de la souris permet la suppression d'une impulsion d'horloge. De même si l'on amène le curseur de la souris dans une des zones (253, 263, 273) permettant d'insérer de nouveaux termes et de nouvelles lignes, I'action sur le bouton 1 de la souris permet d'insérer une nouvelle ligne représentative d'un nouveau signal et l'action sur le bouton 2 permettra la suppression de la ligne représentative d'un signal sur laquelle le curseur pointe. Lorsque le curseur de la souris est amené sur un intervalle représenté par un bloc (254), l'action sur le bouton 1 modifiera les bornes de l'intervalle, I'action sur le bouton 2 de la souris détruira cet intervalle, I'action sur la touche "Majuscule" et le bouton 1 sélectionnera un intervalle et l'action sur la touche "S" changera le statut de l'intervalle. Aux figures 7A et 7B, on a représenté la relation qu'il y a entre le fait d'amener le curseur sur un intervalle (254) et le message associé qui dépend de l'arbre syntaxique, ce message indiquant au contrôleur que l'on a sélectionné cet intervalle. Dans ce cas, comme on peut le voir à la figure 7A, les seules actions possibles peuvent être celles de type segment ou statut. A la figure 7B, on représente le fait que l'utilisateur a appuyé sur la touche du clavier "S" pour o0 provoquer un changement d'état de l'intervalle. Si l'utilisateur avait appuyé sur une touche quelconque du clavier qui n'était pas autorisée, le contrôle d'édition par le fait qu'il filtre les stimuli à l'aide de l'arbre syntaxique aurait refusé l'action. Ceci est dû au fait que la grammaire abstraite (13) possède une table de méthodes valides qui permet d'interpréter les différentes actions que l'utilisateur peut réaliser sur l'objet graphique en appliquant sur le noeud concerné de l'arbre syntaxique la méthode correspondant à l'action. Cette interprétation est réalisée grâce à une fonction, qui pour chaque objet graphique du chronogramme fait correspondre un noeud unique dans l'arbre syntaxique du chronogramme. L'éditeur créé ou supprime les noeuds de l'arbre syntaxique grâce à des actions qui font intervenir d'autres noeuds abstrait ou concret, c'est le cas par exemple du noeud "limite" (bound) ou du noeud "statut" (status) qui sont les fils ou petits-fils du noeud intervalle et qui sont créés automatiquement après la création de l'intervalle et qui ne sont manipulés qu'à travers l'intervalle. Cette fonction permet pour chaque stimulus valide envoyé à partir d'un objet graphique concret d'accéder directement au noeud de l'arbre syntaxique abstrait correspondant et de l'interpréter en modifiant l'arbre. Pour chaque stimulus un message est envoyé à l'arbre syntaxique. Ce message est un couple composé par l'identificateur de l'objet graphique et par le type d'action que l'on veut exécuter sur cet objet. Après chaque action l'arbre est mis à jour et un nouveau préfixe de chronogramme est créé. Dans un troisième temps il est nécessaire après chaque modification de l'arbre de remettre à jour l'image graphique. Le préfixe de l'arbre syntaxique du chronogramme caractérise toujours l'état de l'édition. Par exemple, si l'action de l'utilisateur a consisté à taper sur la lettre "J" alors que le curseur de la souris pointait sur une intervalle, ce qui correspond au changement de statut d'un intervalle dans la couleur "jaune". Cette action a été prévue dans la liste des actions et des méthodes associées à un intervalle. Le contrôleur (16) accède alors au noeud de l'arbre syntaxique correspondant à l'intervalle et applique le changement de valeur du champ "statut" à "jaune". Ce changement d'état étant réalisé dans l'arbre syntaxique, il est nécessaire alors de remettre à jour l'écran en accédant cette fois à l'image graphique correspondant à l'intervalle et en changeant par exemple la couleur du fond de l'intervalle. Cette mise à jour est effectuée au niveau de l'interpréteur WOOL. Dans le cadre de l'éditeur pour le langage graphique WOOL, la définition de la syntaxe abstraite du langage a été faite en créant pour chaque lettre de l'alphabet non terminale de la grammaire, c'est à dire pour chaque lettre qui apparaît en partie gauche de la grammaire, une classe qui possède comme champ les objets correspondants à la deuxième partie de la règle. Dans chacune de ces classes les différentes méthodes correspondent aux actions d'édition possibles sur l'ensemble des noeuds de ce type. Certaines de ces classes correspondent à des classes d' objets graphiques (ex: intervalle, créneau), sur ce type de classe il est nécessaire de posséder des attributs et des méthodes supplémentaires qui permettront de dialoguer avec l'image graphique du noeud. C'est le rôle de la classe de plus haut niveau qui est la classe Rgraphic-node". Cette classe possède une fonction d'affichage qui est en fait une fonction de création d'image graphique. Les arguments de cette fonction sont en premier lieu le type d'objet à dessiner, par exemple, intervalle, ligne ou scène et l'objet graphique dans lequel il va être dessiné. Cet objet est l'image de son plus proche ascendant qui est aussi un noeud graphique. Souvent c'est en fait l'image du père du noeud. Ce paramètre est très important car il est indispensable de garder dans la représentation graphique la hiérarchie qui existe dans l'arbre abstrait. Les autres paramètres sont relatifs au type d'objet à afficher. Ils permettront de le dessiner conformément à l'arbre syntaxique. Cette fonction va créer un nouvel objet à l'écran, cet objet est annoté par un identificateur, pour tout objet graphique créé l'identification sera différente et il sera récupéré par l'objet abstrait grâce à un attribut supplémentaire appelé (Identwidget). Ce champ permettra de connaître à tout moment le représentant dans la syntaxe concrète d'un noeud de l'arbre. Cela permet de le manipuler en le détruisant ou en modifiant certain de ces champs à partir de l'arbre abstrait. C'est le même identificateur qui servira à connaître quel noeud de l'arbre correspond à la partie de l'écran stimulée. Par exemple, les intervalles possèdent une image graphique dans la syntaxe concrète. La position et l'aspect de chacun d'entre eux sont calculés en fonction des feuilles des différents fils (la position grâce aux feuilles du champ de type segment et l'aspect intérieur grâce à son statut "status"). Ces différentes feuilles constitueront certains des paramètres de la fonction affichage. Sur cet objet plusieurs actions sont possibles; par exemple la génération, la destruction, la modification de la taille de l'intervalle, le changement de son statut, etc.... Toutes ces actions entraînent la création ou la modification des noeuds de l'arbre correspondant à l'intervalle et à ses fils. Il faut donc mettre à jour les objets concrets. Dans le cas d'une modification de feuille d'un noeud, cela peut être fait de deux façons, soit en détruisant l'image graphique correspondant à l'ancien noeud puis en créant une nouvelle image relative au nouvel objet, soit en modifiant directement l'image graphique. Cette deuxième méthode a été adoptée dans le cadre de l'éditeur de chronogramme, il est alors nécessaire d'associer à chaque fonction de modification du noeud abstrait une fonction de modification de l'image graphique. Nous avons donc présenté la manière dont la syntaxe abstraite a été définie, les actions d'édition et surtout le moyen de communiquer entre la syntaxe abstraite et la syntaxe concrète. Nous allons présenter dans un deuxième temps comment cette syntaxe concrète associée à chaque type a été définie et comment il est possible à partir d'une image graphique de connaître son représentant dans l'arbre abstrait. La représentation des différentes classes a été réalisée à l'aide d'un générateur d'interface graphique qui permet de créer intéractivement des objets graphiques sous X-WINDOWS/MOTIF puis d'en modifier les paramètres (couleur, position, action sur ces objets, etc...) dans un environnement multifenêtres très convivial. Dans l'art antérieur, les interfaces sont en général prédéfinies, c'està-dire que dès la conception on connaît exactement l'allure de l'ensemble des fenêtres utiles à la définition de chaque interface. Ces fenêtres possèdent en général les parties textuelles des menus et des boutons qui dès qu'ils sont activés font apparaître d'autres fenêtres ou d'autres boutons. Il suffit alors de les représenter une à une et une fois pour toute grâce à l'éditeur de ce générateur d'interface graphique et de programmer les différentes fonctions relatives à chaque action sur ces fenêtres. Elles sont alors sauvegardées sur fichier dans un langage appelé WOOL. Au chargement de ce fichier, I'image écran sera alors fidèlement restituée grâce à l'interprèteur WOOL de ce générateur d'interface graphique. Dans le cas de l'invention, nous n'avons pas utilisé ce générateur de manière standard. En effet, dans la définition d'un langage graphique, I'ensemble des mots valides est en général indéfini ou du moins très grand. On ne peut donc pas prédessiner l'ensemble des chronogrammes possibles et il est nécessaire d'utiliser l'aspect dynamique de ce type d'outil. En effet, la création d'un nouvel objet ne se fait plus par chargement de fichier mais par appel d'une fonction correctement paramétrée, il y aura alors une fonction pour chaque classe d'objet graphique. Cette fonction n'est pas automatiquement générée comme l'est le fichier associé à une fenêtre d'interface. En revanche, on peut récupérer ce fichier puis le modifier en rendant certains de ces paramètres variables. Toutes les fonctions de création seront en particulier paramétrées par l'identificateur du père de l'objet graphique qui est toujours connu dynamiquement. Seule la fonction de création de la racine de l'arbre ne possède pas ce paramètre; les autres paramètres seront en général relatifs aux différentes feuilles des sous- arbres (pour les intervalles ce sera les bornes "bound" et le statut "status"), ou à la position de l'objet nouvellement créé dans une liste d'objets de même type (pour les lignes). A chaque nouvel objet graphique créé lors d'une session, le générateur d'interface génère automatiquement un identificateur. Cet identificateur va servir de lien entre les deux représentations abstraite et concrète du même chronogramme. Le générateur d'interface permet aussi de filtrer et d'interpréter les stimuli que la souris ou le clavier envoie sur les différents objets graphiques et envoie un message correspondant à chaque stimulus à l'arbre abstrait. Ce message est composé de l'identificateur de l'objet graphique stimulé, du type d'action suivi des arguments nécessaires au déroulement de cette action. Une table "ENV" stockée dans le disque dur (10) contient les correspondances entre identificateur de l'objet graphique et le noeud de l'arbre abstrait. On va donc chercher dans cette table le représentant de l'arbre abstrait qui existe nécessairement car par construction à tout objet graphique excitable correspond un et un seul noeud de l'arbre apte à interpréter le message. Prenons par exemple l'ensemble des actions possibles lorsque le curseur de la souris est positionné sur un intervalle quelconque: : Modification des bornes. Majuscule : Destruction de l'intervalle. : Modification du champ statut à hors propos (IRRELEVANT) : Modification du champ statut à haut (HIGHT) : Modification du champ statut à bas (LOW) : Modification du champ statut à descendant (FALLING) : Modification du champ statut à montant (RISING) : Mode d'aide associé aux intervalles. Toutes ces actions, sauf l'apparition du mode d'aide, ont des conséquences sur l'intervalle. Tous les autres stimuli n'appartenant pas à cette table (même cliquer sur le bouton 3 de la souris sans appuyer sur la touche ), sont ignorés. On prend maintenant une de ces actions: Appuyer sur la touche "r" pour un intervalle qui porte comme statut le statut bas (LOW). On va donc envoyer l'ordre de changement aux noeuds de l'arbre syntaxique correspondant. Cet ordre sera interprété grâce à une fonction appelée "concret_à_abstraitfonction" qui est générale pour tout type d'actions et d'objets. Dans le cas présent, cette fonction sera appelée avec les paramètres suivants: concret_à_abstraitfonction ("@XXXXX@", "changestatut", "MONTANT") identificateurNom de la méthode Paramètre Cette fonction est divisée en trois parties hormis le problème de transformation de type WOOL en type C: 1. recherche dans la table appelée "env" de l'objet "obj" représentant le noeud abstrait correspondant à l'identification "@XXXXX@. 2. recherche du pointeur vers la fonction associée à "change statut" pour un objet de type intervalle de base (BASICINTERV) dans une deuxième table générée {LIST METHOD) par le compilateur et contenant pour chaque classe d'objet une liste de méthode correspondant par exemple à la liste des actions possibles de la page précédente. 3. application de cette fonction sur l'objet "obj" avec comme paramètre la table "env" puis les autres arguments de la fonction. Dans le cas présent il n'y aura que le nom du nouveau statut "MONTANT". Par exemple, toutes les classes possèdent une méthode génération, une méthode destruction, celles qui sont du type LISTE possèdent toutes des méthodes d'insertion ou de suppression d'un élément mais il n'y a aucun problème de conflit. Rajouter une action ou une méthode dans une table d'action, ou modifier la grammaire n'entraîne aucun changement dans cette fonction. Maintenant, nous allons montrer la structure de la classe intervalle de base (BASIC INTERVAL) correspondant aux intervalles: Sur le tableau de l'annexe 1 figure l'interface de la classe (BASICINTERV) et sur le tableau de l'annexe 2 figure les méthodes et attributs associés à cette classe. La méthode de destruction n'apparait pas sur le tableau de l'annexe 2 car elle est directement héritée de la classe GRAPHIC NODE. Toutes les actions d'édition, par exemple pour la classe BASIC INTERVAL, exporter emplacement, statut, génération, modification, changer statut, répéter GRAPHIC-MODE, hérite, possèdent donc dans leurs arguments représentés à l'annexe 2, la table appelée "env" de correspondance entre les objets concrets et les objets abstraits. Cette table va être automatiquement mise à jour à chaque création ou destruction d'un objet graphique. Sur le tableau de l'annexe 2 apparaissent deux méthodes qui ne peuvent pas être directement appelées par l'image graphique et qui sont communes à toutes les classes: 35. il s'agit de la méthode génération qui crée le sous arbre relatif à l'objet et remplit les feuilles de ce sous arbre avec les différents arguments. Cette fonction est en général appelée par le père de l'objet, qui demande la génération d'un de ses fils. il s'agit également de la méthode décompilation qui affiche l'image concrète du noeud, et applique récursivement la décompilation aux différents fils de ce noeud. Cette fonction peut être appelée après une modification d'un noeud abstrait ou au chargement d'un chronogramme existant, mais en aucun cas par l'image graphique car cette image est par construction toujours à jour, cela reviendrait à réafficher exactement la même image. Dans le cas du changement du statut d'un intervalle, on va donc descendre dans la feuille de l'arbre représentant le statut, puis on modifiera cette feuille si cela est possible. Pour un changement vers le statut "MONTANT" (RISING), il est nécessaire de vérifier auparavant que la différence entre les bornes inférieure et supérieure de l'intervalle est supérieure à 2. Ici, la modification de l'arbre est très simple. Dans le cas de l'insertion d'une ligne, ou d'une période de temps, les conséquences sur l'arbre ne sont pas localisées au sous arbre incriminé et obligent le contrôleur (16) à naviguer dans l'arbre entier pour modifier de nombreux noeuds. La modification de l'arbre étant réalisée, on va alors mettre à jour l'image graphique. Cette fonction a été optimisée dans le cas du changement de statut. En effet, on ne détruit pas l'image graphique de l'intervalle pour décompiler le nouveau noeud, mais on va appeler directement la fonction d'affichage de la classe GRAPHIC_NODE avec comme argument le champ "ident widget" de l'intervalle modifié, suivi du nom de la fonction d'édition graphique WOOL permettant ce changement d'attribut, suivi du nom du nouveau statut: affichage fonction ("@XXXXX@", "changestatutwool", "MONTANT (RISING)" identificateur de l'intervalle Norm de la fonction Paramétre Dans le cas d'une création d'un nouvel intervalle de statut MONTANT (RISING) dont la borne inférieure est "2" et la borne supérieure est "3", la fonction d'affichage est appelée avec les paramètres suivants affichagefonction ("@YYYYY@", "intervalle", "MONTANT(RISING)", "2", "3") identificateur de la ligneNorm de la fonctionPararnmètre Nous avons présenté comment et avec quel outil, l'éditeur de chronogrammes a été programmé. Ce qu'il est important de voir en premier lieu, c'est qu'il y a une totale indépendance dans la définition de la syntaxe concrète par rapport à la syntaxe abstraite. Cela donne un éditeur facilement modifiable au niveau de sa syntaxe concrète. En effet, le changement de syntaxe concrète peut même être paramétré grâce à un outil de génération d'interface. Il suffit d'ouvrir l'éditeur (14) de l'outil de génération d'interface, de modifier itérativement l'allure des différents objets, puis de sauvegarder les modifications. Cela peut se faire très rapidement, sans compilation de l'ensemble du logiciel, grâce au langage interprété WOOL de contrôle de l'outil de génération d'interface. Cela est très utile pour des langages graphiques o l'ergonomie est un problème important, et o la définition des objets graphiques est souvent relative aux habitudes des utilisateurs. Ce genre de modification est réalisée grâce à l'ouverture de l'éditeur de bitmap sur le fichier spécifiant le motif courant du statut puis le dessin du nouveau motif du statut puis la sauvegarde du nouveau fichier. Dès cette sauvegarde, le changement de motif est effectif, et tous les nouveaux intervalles seront affichés en prenant en compte la modification. En fait, il est très possible d'intégrer cette génération dans l'éditeur pour donner le moyen à l'utilisateur de personnaliser interactivement son chronogramme en paramétrant ses différents motifs. Cette technique est utilisable pour n'importe quel type de langage graphique. On s'aperçoit que grâce à cette méthode de programmation, on se retrouve avec un code malléable, évolutif et robuste aux changements. Une grande partie des actions d'édition pourrait être récupérée dans le cas de développement de langages graphiques possédant une structure analogue, en revanche pour le développement de langages graphiques apparentés aux blocs diagrammes ou au réseau de Petri la plupart des actions devront être réadaptées en profondeur. Indépendamment du code et de l'analyse syntaxique réalisée au fur et à mesure de l'édition, cette méthode d'édition présente pour l'utilisateur deux grands avantages. Elle permet de localiser toutes les actions sur les objets graphiques en supprimant en grande partie la méta-syntaxe, et permet de limiter le nombre d'actions à retenir. par exemple, si l'insertion d'un objet dans une liste s'obtient en cliquant sur le premierbouton de la souris, le geste pour insérer sera le même pour un signal dans la liste des signaux, pour un intervalle dans la liste des intervalles ou encore pour un cycle d'horloge. C'est la position du curseur de la souris sur la fenêtre définissant le chronogramme et donc le type du noeud de l'arbre syntaxique correspondant qui permet d'interpréter l'ordre comme insertion d'un intervalle sur une ligne si le curseur est positionné sur une ligne, ou insertion d'un signal après tel signal si le curseur est positionné sur un signal, ou insertion d'un cycle d'horloge si le curseur est positionné sur la partie graphique représentant l'horloge. Il en est de même pour toutes les actions de ce type, par exemple la sélection ou la suppression. Le mécanisme d'édition tel qu'il a été développé plus haut, a été systématiquement appliqué à tous les noeuds de l'arbre, et cela a eu pour 1o conséquence d'éliminer complètement tous les menus de l'éditeur. En effet, les menus qui permettaient à l'utilisateur de définir le mode courant de l'éditeur ne sont plus utiles car avec ce type de contrôle, l'information est répartie au niveau de chaque objet graphique. On n'a donc plus un éditeur à mode, mais un éditeur que l'on appellera à "objets" (en rapport avec la programmation orientée objet), car l'action qui va être réalisée est définie par l'objet que l'on stimule. En fait, le statut courant de l'édition correspond au statut courant de l'arbre syntaxique qui se confond complètement avec le dessin du chronogramme que l'utilisateur saisit. Cela donne un éditeur o la méta-syntaxe est limitée à des parties d'objets définies au niveau de langages de programmation graphique (par exemple des ascenseurs dans les différentes fenêtres). Cela donne aussi un éditeur avec un apprentissage facile car possédant une méthode d'aide liée elle aussi aux différents types d'objets, et qui, pour un utilisateur expérimenté, donne de très bonnes performances de saisie. D'autres modifications à la portée de l'homme de métier font partie de l'invention. Chapitre 1 Introduction 1.1 Les motivations industrielles Les contraintes de fabrication d'un circuit hardware sont de plus en plus fortes dans le contexte actuel du marché. En deffet, avec la concurrence effrénée que se livrent les constructeurs de machines, il est de plus en plus important de commercialiser la machine le plus rapidement possible et avec une marge d'erreur quasi nulle. Cette concurrence entraîne une surenchère entre les constructeurs et les oblige à être extrêmement sûrs d'eux vis-à-vis de leur machine car la gestion des erreurs représente un coût énorme, non seulement du point de vue matériel (changement des machines défectueuses...) mais aussi et surtout du point de vue de leur image auprès de leurs clients. Ces erreurs, même bénines peuvent s'avérer catastrophiques dans un marché de plus en plus serré. Avec le nivellement des performances, dû à l'accession de plus en plus facile à la technologie et à la normalisation des systèmes, la fiabilité des machines devient un critère d'achat prépondérant. Le droit à l'erreur n'est plus permis par les clients. C'est pourquoi BULL s'est lancé depuis plusieurs années dans la recherche de nou- veaux outils permettant une fiabilité renforcée de ses machines. Les premières méthodes de validation utilisant la simulation ont été renforcées et appliquées avec de gros moyens (des machines spécialement dédiées à la simulation sont employées pendant des mois pour valider une nouvelle machine). Mais avec la réduction du temps d'étude et de vérification et l'augmentation de la complexité des machines, BULL a tenté de diversifier ses méthodes de validation et a été l'un des pionniers dans le développement d'outils mettant en oeuvre des méthodes formelles d'aide à la validation de circuits [ABM+89]. Ces outils plus sûrs, plus rapides, mais aussi beaucoup plus coûteux en mémoire, permettent déjà de valider formellement des morceaux d'une machine. Mais le chemin est très long pour assurer une complète sécurité sur les machines de plus en plus complexes. En fait, la fabrication d'un circuit demande plusieurs étapes de vérification. La pre- mière est la validation du modèle du circuit qui est, dans la plupart des cas, réalisée en simulant le comportement du circuit, c'est à dire en lui faisant exécuter une série de pro- grammes de tests appelés OPELs (OPérations Élémentaires) qui sont thésaurisés depuis plusieurs générations d'ordinateurs compatibles. Malheureusement, les circuits très complexes ne peuvent pas être complètement validés par la simulation car il est impossible de créer l'ensemble exhaustif des tests (Voir [Cla90], préface). De nombreux travaux ont été réalisés pour générer automatiquement les tests et en minimiser le nombre. Depuis quelques années, des méthodes de calcul symbolique ont été développées afin de donner une alternative à la simulation. Des outils utilisant ces méthodes sont alors réalisés pour prouver l'équivalence entre deux représentations du circuit [MB88]. Dans ce cas là, le but est d'être sûr que la réalisation et la spécification de haut niveau sont fonctionnellement équivalentes. Mais cette méthode ne permet pas aux concepteurs d'être sûrs que la spécification de haut niveau réalise bien ce qu'ils espèrent. Cela est indispens- able pour les systèmes dont les fonctions sont très complexes, par exemple, des systèmes incluant un important aspect de contrôle (système mémoire et cache). Des travaux ont alors été réalisés pour créer des modèles permettant de définir les différents aspects com- portementaux d'un système et pour fournir des vérificateurs automatiques [CBM89] ou semi-automatiques. Mais l'apprentissage de ces formalismes par les concepteurs est diffi- cile car loin de leurs habitudes. Nous avons donc proposé d'utiliser un formalisme de haut niveau permettant de développer ces modèles tout en restant proche des concepteurs [Ant91b], [AL91]. Nous en avons donc pris un qui existait déjà: les chronogrammes, et nous en avons fait un langage avec une syntaxe et une sémantique formelle. 1.2 L'état de l'art 1.2.1 Les chronogrammes Les chronogrammes sont déjà utilisés dans le monde de la conception de circuits ou de systèmes. Au départ, ils représentent en fait les traces que les concepteurs ont l'habitude d'observer sur un oscilloscope lors des tests physiques d'un circuit. Ces traces d'oscilloscope sont devenues, en les schématisant, un moyen de représenter dans des doc- uments écrits les configurations les plus importantes des signaux du système [Mul88]. Cette première utilisation des chronogrammes est encore la plus importante. Mais ils sont en général représentés dans des formalismes très éloignés les uns des autres. Non seulement du point de vue syntaxique, mais aussi sémantique. En effet, la sémantique des chronogrammes dépend de l'interprétation que le concepteur en fait. Une personne con- naissant l'ensemble du système va, dans certains cas, généraliser certaines configurations qui ne sont pas formellement définies dans son chronogramme. Dans la figure suivante, nous allons présenter différents exemples de chronogrammes extraits de spécification de circuits. Leurs syntaxes sont très différentes les unes des autres et ils sont utilisés pour des sujets très différents. D'autres exemples seront donnés dans l'annexe G 1 liJ CLOTS - - - *111- _U__ Figure 1.1: Chronogramme de bus Figure 1.2: Chronograme de circuit SA Figure 1.3: Chronogramme de protocole Les chronogrammes sont aussi depuis quelques années assez souvent utilisés dans des outils de simulation. En effet, la plupart des compagnies proposant des outils de simulation incluent dans leur catalogue un outil permettant l'édition de chronogramnnes pour les tests [Dai9O0. Ces outils permettent de spécifier à l'aide de chronogrammes des configurations des signaux d'entrée du système ainsi que de visualiser les configurations des signaux de sortie. Là aussi les différents outils n'utilisent pas la même syntaxe, et la sémantique de ces chronogrammes n'est pas formellement définie. Depuis quelques années, des recherches ont été effectuées pour essayer de formaliser les chronogrammes. G.Boriello [Bor88] [Bor92] a été l'un des premiers à vouloir utiliser les chronogrammes comme langage de spécification avec l'apport des outils de syn- thèse. L'utilisation des chronogrammes dans la définition de propriétés temporelles avec une compilation dans la logique temporelle linéaire a aussi été une voie abordée dans l'article [FF90]. D'autres recherches ont été développées pour permettre d'utiliser les chronogrammes dans la création automatique de modèle VHDL d'interface- bus [LB921. La possibilité d'interfacer les chronogrammes avec le monde VHDL a aussi été dévelop- pée dans une optique soit de simulation [DKC91],[KDC91], soit de spécification [KCD92]. Dans cet ensemble de travaux, c'est en fait l'utilisation des chronogrammes qui est mise en avant et non leurs définitions syntaxiques et sémantiques. Dans cette thèse, nous allons développer ces deux différentes étapes indispensables dans la définition d'un lan- gage. Le langage a été défini en étudiant les différents chronogrammes existants, puis nous en avons extrait un sous ensemble le plus complet possible qui permettait de ne pas perdre l'ergonomie du langage en ayant une puissance d'expression maximale, en restant décibable et facilement compilable. Dans un deuxième temps nous développer- ons l'utilisation de ce formalisme surtout dans le domaine de la vérification de propriétés dynamiques. 1.2.2 Les différentes méthodes de validation Nous avons vu dans le début de l'introduction, comment le fait de formaliser les chronogrammes pouvait s'insérer dans une méthodologie de validation de plus en plus sûre des systèmes. C'est pourquoi, nous allons présenter rapidement, certaines méthodes de validation qui existent à cette heure. Le but de cette section n'est pas de donner la liste exhaustive de tous les travaux qui ont été réalisés dans ce domaine, une thèse entière ne suffirait pas, mais plutôt d'introduire certains, prenant appui le cas échéant sur l'exemple industriel de BULL [ABM+89]. Dans cette thèse, nous donnerons également des idées sur la manière d'utiliser astucieusement certains de ces outils dans le domaine plus spécifique de la vérification de propriétés de systèmes dynamiques. Dans le domaine de la validation de matériel, la validation d'un circuit revient tout d'abord à valider un modèle de ce circuit. Ce modèle peut être soit de très bas niveau, i.e une image de la réalisation du circuit que l'on a extrait du dessin du circuit [Mur88], soit de plus haut niveau et écrit dans un langage de spécification de matériel. Le problème est maintenant de trouver les moyens de prouver que ce modèle est bien ce que l'on espère: soit en le comparant au modèle de référence du système, s'il en existe une, soit en y vérifiant des propriétés de plus haut niveau. La validation à partir d'un modèle de référence Le modèle de référence d'un circuit qui est l'écriture de tous les aspects du circuit dans un langage de spécification de matériel et dont on est sûr qu'il correspond de manière complète à toutes les fonctionnalités espérées. Dans certain cas, il est possible et parfois même très facile d'avoir un modèle de référence du circuit. C'est le cas pour tous les circuits déjà testés dans lesquels on veut optimiser les performances, ainsi que pour des circuits simples o l'écriture du modèle de référence dans un langage de spécification de matériel est presque immédiate car utilisant des fonctions de haut niveau du langage. Par exemple, prenons le cas d'un additionneur, la réalisation d'un additionneur optimisé n'est pas évidente, en revanche sa spécification dans n'importe quel langage ne pose pas de difficulté particulière. Dans le domaine de la validation avec un modèle de référence, on peut envisager plusieurs méthodes. Tout d'abord, la simulation qui est en fait la vérification par exten- sion de l'ensemble des configurations de tests possibles. Cette méthode a été longuement utilisée et l'est toujours avec un certain succès. Les méthodes de simulation se sont affinées pour permettre la vérification de systèmes de plus en plus grands. Mais la simulation n'est toujours pas sûre pour de gros systèmes qui demanderaient, pour être vérifiés par elle, des années de calculs sur des machines très puissantes. Il y a aussi la preuve par équiva- lence (pour les circuits combinatoires PRIAM [Mad90], pour les circuits séquentiels SIAM [Cou9l]). Ici on est dans le cas de la comparaison exhaustive de deux machines. On va donc vérifier par compréhension que la définition fonctionnelle d'une machine est mathé- matiquement équivalente à celle de l'autre. Cette méthode a aussi fait ses preuves dans des environnements industriels pour la vérification de système. On peut aussi parler du démonstrateur de BOYER MOORE basé aussi sur la preuve par équivalence mais utilisant des algorithmes fondés sur le principe d'induction [BM88], [DLA90] Cette liste est loin d'être exhaustive et il y a plusieurs variantes de chaque méthode. La validation sans modèle de référence On a vu que beaucoup de travaux ont été réalisés autour de la validation de modèles. Mais dans de nombreux cas et particulièrement pour la réalisation d'un protocole de communication, il n'y a pas de spécification de référence. Les méthodes précédentes peuvent encore être utilisées mais avec une assurance beaucoup plus faible. En effet, on écrit alors une spécification du système dans un langage de description de matériel et on prouve l'équivalence fonctionnelle entre la réalisation et cette spécification. On réalisera alors une preuve partielle basée sur la non redondance des erreurs. Mais cette méthode n'est pas très satisfaisante dans le sens o si une erreur est détectée (i.e une différence entre le comportement du modèle et le comportement de la réalisation), on ne sait pas d'o elle vient de façon certaine. Même si les langages de spécification sont de haut niveau, l'écriture des modèles pour des systèmes complexes n'est pas très éloignée de la réalisation, et des erreurs logiques, parfois les mêmes que dans la réalisation, peuvent s'y infiltrer d'autant plus qu'en général les une dérivent des autres. Alors, il est nécessaire de trouver un moyen de fournir ce que l'on appellera des spéci- fications partielles du circuit qui, elles, sont fiables, soit parce qu'elles sont assez simples pour être totalement contrôlées par le concepteur, soit parce qu'elles ont déjà été vérifiées formellement. On vérifiera alors que le modèle global réalise bien au moins ces modèles partiels. Les intérêts de cette approche sont de trois ordres. 1. Elle est indispensable pour certains types de problèmes (protocoles). 2. Elle permet de hiérarchiser la vérification car il est alors possible de valider des parties du modèle pour les rendre de référence. 3. Elle permet de localiser les erreurs qui peuvent se glisser dans le modèle. Cette méthode peut servir dans des cas simples de méthode de spécification en utilisant une programmation par contraintes [Col82]. Mais pour des problèmes très complexes, il' semble impossible de donner la liste exhaustive des propriétés car peu de formalismes per- mettent de spécifier et surtout d'exploiter après compilation tous les types de propriétés. Dans cette thèse, nous nous sommes intéressés aux différentes méthodes de vérification de propriétés, car l'utilisation principale des chronogrammes de CHLOE est de pouvoir, au travers d'un langage graphique, spécifier l'ensemble des propriété,. de ce système et donc, a fortiori, de prouver que le modèle et la réalisation du système les vérifient bien. Il était donc indispensable de connaître l'ensemble des outils de preuve de propriétés pour en tirer le meilleur parti. Cela nous a permis d'imaginer et, en utilisant les bases de certains outils de preuve, de développer une méthode de vérification de propriétés basée sur la modification du modèle à vérifier par l'ajout dans le modèle de la propriété à prouver. Cette méthode est aussi utilisée dans la vérification de propriétés sur des programmes LUSTRE. La vérification de propriétés sur un système peut aussi être réalisée de plusieurs façons. La méthode la plus courante est encore la simulation; elle consiste à programmer ce qui est appelé le plus souvent des vérifieurs, contrôleurs ou analyseurs de traces qui vont à chaque instant vérifier si la configuration des signaux est valide ou non. La programmation de ces vérifieurs est assez délicate et elle peut demander des mois de programmation pour des circuits complexes. Dans ce domaine, il existe aussi des outils de preuve de propriétés. Plusieurs Model Checkers basés sur la logique temporelle et utilisant pour les plus récents des méthodes symboliques ont été réalisés pour des modèles à temps discret, [CE81, QS81, BM9Ob, CM9O]. Des techniques analogues ont aussi servies à l'élaboration de Model Checkers dans le cas de modèles à temps continu [HNSS92]. Dans ce domaine, il n'y a pas de modification du modèle mais seulement une l'analyse du modèle à vérifier en déterminant l'ensemble des états vériant une propriété écrite en logique temporelle. Il existe aussi la possibilité d'utiliser les compilateurs basé sur les langages déclaratifs à flot de données tel SIGNAL [GLIB87], [BL87], qui permettront de vérifier si la composition entre le modèle et la propriété n'engendre pas une contrainte différente de celle engendrée par le modèle seul [Le 89]. 1.3 Notre contribution 1.3.1 La place de CHLOE La fabrication d'un circuit ou d'un système commence par la spécification informelle du système qui permet de définir ses différentes propriétés dans un langage naturel o au travers de formules mathématiques. Ces propriétés sont en général des exemples de com- portements à travers le temps des différents signaux du système ainsi que les contraintes temporelles entre ces différents signaux. Pour les protocoles, l'extraction des différents comportements possibles est encore plus flagrante car c'est en fait le seul moyen de spécifier. En effet, dans la réalisation d'un protocole il n'y a pas de modèle de référence ou de haut niveau qui englobe l'ensemble des propriétés de ce protocole. La spécification consiste alors à imaginer toutes les con- figurations possibles du système (ce qui est vraiment très difficile pour des systèmes à plusieurs niveaux de mémoires cache par exemple). De là, se dessinent en général des pro- priétés de plus haut niveau sur les comportements des signaux composant le protocole à travers le temps. Les configurations les plus importantes sont alors spécifiées au travers de chronogrammes qui permettent aux concepteurs de les visualiser et de les stocker. Cette remarque pour les protocoles est peut être étendue à tous les systèmes dynamiques. En partant de cette observation, notre idée a été de fournir, pour spécifier ces propriétés et ces contraintes un formalisme additionnel pratique et beaucoup plus naturel pour les concepteurs que l'écriture dans une logique temporelle comme CTL [CG871, dans un langage de description de matériel (HDL) comme VHDL [IEE88] ou LDS [MJ91], ou bien dans des langages synchrones tel SIGNAL [GLIB87], LUSTRE [CPHP87], ou bien ESTEREL [BG88]. Tous ces formalismes, bien qu'ils soient de haut niveau entraînent une période d'adaptation assez importante pour les concepteurs d'architecture de machine. En re- vanche, les chronogrammes ont une syntaxe graphique bien connue de ces même concep- teurs. Ils sont déjà utilisés en appoint de la spécification préliminaire de la machine. En fait, ils les utilisent pour exprimer certains aspects du comportement de la machine sur laquelle ils sont en train de travailler, ainsi que comme entrée et sortie d'une simulation pour la visualisation des vecteurs de tests et des résultats de ces tests [Dai90]. Dans cette optique de simulation, le concepteur décrit les comportements possibles de sa machine sans se préoccuper des propriétés globales sousjacentes. Dans le cas d'aide à la spécification, il va justement utiliser ces chronogrammes, en faisant apparaître graphique- ment les relations entre les comportements des signaux. Ces relations définies en général par des flèches, représentent les propriétés globales de la machine. Ces propriétés ne sont pas seulement des propriétés de causalité, mais des correspondances d'observation entre les comportements. Par exemple, il est très intéressant de pouvoir décrire naturellement des propriétés faisant référence au passé, du type un événement ne peut se produire que si les signaux ont été observés dans telle configuration par le passé. Ce sont en général les propriétés de verrous: une porte ne peut s'ouvrir que si son verrou à été débloqué précédemment. Pour l'instant, il n'existe pas vraiment de standard pour les chronogrammes, chaque concepteur possède une syntaxe et une sémantique particulière souvent implicite. Seuls les simulateurs ont des règles assez précises mais suivant leurs fonctionnalités, l'écriture des propriétés devient difficile, et souvent impossible. Ces simulateurs ne sont pas en réalité faits pour pouvoir représenter des propriétés globales du système, mais seulement des exemples de comportements à travers le temps. Il est donc nécessaire de définir un langage d'édition de propriétés dynamiques basé sur les chronogrammes, avec une syntaxe et une sémantique formellement définies. Les chronogrammes ainsi dotés serviront dans un premier temps à la génération de vérifieurs ou analyseurs de traces pour la validation des propriétés, cf. figure 1.4. CONTRAD"! EbKHtLI rr__ R _ MODELE _ 1 I GDENPTION AtrroAQU Figure 1.4: La place de CHLOE 1.3.2 L'environnement CHLOE L'environnement logiciel d'utilisation de CHLOE déposé par BULL sous le nom de CROMLECH [ALP93] et développé pour la thèse, est composé de plusieurs parties. Celles-ci correspondent aux différentes étapes entre l'édition des propriétés sous forme de chrono- grammes et la preuve ou la simulation de ces propriétés sur un modèle existant en utilisant les outils réalisés à cette intention 1.5. Le logiciel CHLOE est composé de quatre parties: 1. L'éditeur du langage utilisateur des chronogrammes. 2. L'éditeur du langage primitif des chronogrammes. 3. L'expanseur du langage utilisateur vers le langage primitif. 4. Les compilateurs des chronogrammes primitifs vers les diffélrents lanngages cibles. -aa Figure 1.5: L'environnement CHLOE Nous allons maintenant développer ces différents axes en dormant la manière dont ils sont connectés l1 uns aux autres.cone L de langage prrimitiff vain FiLe langage prmtif des cronogrammes est l'axe principal e l'environnement CHLOE Nous allons maintenant développer ces différents axes en donnant la manière dont ils sont connectés les uns aux autres. Le langage primitif Le langage primitif des chronogrammres est l'axe principal de l'environnement. Il a été longuement étudié pour permettre de recouvrir dans sa structure une puissance d'expression maximum. C'est en fait un ensemble de primitives sffimment puissant pour que toute propriété du langage utilisateur puisse s'exprimer dans ces primitives. Le langage primitif servira de base à l'ensemble des compilateurs. Le choix de ces primitives a été réalisé en analysant les différents chronogrammes ex- istant pour en extraire l'ensemble des types de propriétés qu'un utilisateur espère éditer au travers d'un chronogramme. Puis, nous avons extrait de cet ensemble une structure commune qui sert de base au langage primitif. On ne peut pas dire que cette structure englobe toutes les classes de propriétés possibles sur une machine à états finis, mais il était important de réaliser un langage qui se rapproche des habitudes des concepteurs qui ne choisiront les chronogrammes que pour certains types de propriétés. La grammaire du langage CHLOE n'est pas non plus minimale, mais les différentes règles de cette grammaire ont été étudiées pour une compilation efficace dans les différents langages. Un éditeur a été réalisé autour de ce langage, mais en raison des contraintes de com- pilation, il n'est pas vraiment ergonomique. Il a donc été nécessaire de créer un autre langage de plus haut niveau que l'on appellera le langage utilisateur ou langage évolué de chronogrammes. Le langage utilisateur et l'expanseur La séparation des chronogrammnes dans ces deux catégories est devenue indispensable pour une utilisation pratique de l'outil. En effet, l'éditeur du langage des chronogrammes évolués possède des avantages ergonomiques qui le rendent plus attractif et plus convivial (édition de plusieurs propriétés dans un même chronogramme, possibilité de recouvrement des intervalles impossible dans le langage primitif...) et il est amené à se développer au fur et à mesure des demandes des utilisateurs autant du point de vue de la syntaxe concrète qu'abstraite. Cela entraînerait des mises à jour importantes des générateurs de code ainsi que de la sémantique formelle des chronogrammes. La formalisation d'un langage primitif a permis de pallier à ce problème en fixant une fois pour toutes la sémantique formelle des chronogrammes ainsi que les générateurs de code sur le langage primitif, et les mises à jour ne seront alors réalisées que sur l'expanseur des chronogrammes évolués vers les primitifs ce qui est beaucoup plus simple que la mise à jour des compilateurs. En effet, outre le fait que l'on ne fait ce travail qu'une seule fois, l'expansion est une traduction entre deux langages de même niveau: le langage primitif étant tout aussi déclaratif que le langage évolué. Les fonctionnalités supplémentaires indispensables pour les utilisateurs, n'augmentent pas la puissance sémantique du langage, dans le sens o toutes les propriétés spécifiées dans un chronogramme évolué doivent toujours avoir un sens et donc s'éditer sous forme primitive. En revanche, elles permettent de suivre au plus serré les habitudes des concep- teurs. Ce langage est en fait la première étape d'un langage paramétrable dans sa syntaxe concrète qui permettra de réaliser des chronogrammes personnalisés. Les générateurs de code La première étape de compilation a été de traduire un sous-ensemble des chronogrammes du langage primitif dans le langage synchrone SIGNAL [Ant91a]. Ce sous ensemble est en fait l'ensemble de ce que l'on appellera les chronogrammes statiques. Cette opération nous a permis de nous connecter à l'environnement de compilation et de preuve de SIGNAL en générant du SIGNAL pour la preuve et pour la simulation. Elle nous a aussi permis de positionner la puissance du langage CHLOE par rapport au monde synchrone. Nous développons cet axe dans la section 4 o nous expliquons les différents générateurs de code autour de CHLOE. Après cette première étape de spécification en SIGNAL, nous avons écrit un compi- lateur de CHLOE vers le langage SVHDL, puis utilisé les simulateurs. Un algorithme spécifique de preuve a été développé dans cette optique en utilisant les bases du prou- veur SVHDL[CLS92]. Le problème est là aussi dans la compilation des propriétés de vivacité. Ce problème nous a conduit à développer une méthode de vérification couplant l'algorithme de compilation avec les Model Checkers basés sur la logique CTL [CM9O]. D'autres générateurs de code peuvent être imaginés pour des langages de même type tel LUSTRE [CPHP87] avec le générateur SIGNAL comme base de compilation, ou LDS [MJ91] avec celui de SVHDL. Ils permettront la connection directe avec les outils de vérification compatibles. 1.4 Le plan Dans le chapitre suivant, nous allons donner la structure syntaxique du langage util- isateur puis du langage primitif des chronogrammes. Nous aborderons ce chapitre en développant un exemple simple d'utilisation des deux types de chronogrammes dans la spécification de propriétés d'un automate à états finis en montrant la syntaxe concrète de chaque chronogramme. Puis nous développerons règle par règle, l'ensemble de la gram- maire du langage sous la forme de TSD(Type-Structure Diagrams) [DL91]. Ce formalisme graphique est utilisé pour donner une définition des différents types de CHLOE dans le langage VDM(Vienna Development Method)[Daw92]. Cela nous a permis de spécifier formellement la grammaire de CHLOE. Nous donnerons en parallèle la représentation dans la syntaxe concrète de chaque règle de la grammaire en expliquant les raisons qui nous ont amenés à choisir les différents objets. Cela pour avoir le meilleur compromis entre la minimalité du langage primitif et les contraintes d'efficacité dans la compilation et la décompilation d'un arbre syntaxique. Dans le chapitre 3, nous définirons formellement la sémantique du langage des chronogrammes primitifs. Nous introduirons ce chapitre, en présentant rapidement les différents sens des chronogrammes, puis nous développerons sa sémantique en terme d'"intension" [Nef89] qui servira de base dans la génération de code vers SIGNAL. Dans un deuxième temps, nous donnerons sa sémantique en terme d'expressions rationnelles pour la connection au monde des automates et pour trouver la place du langage CHLOE dans la hiérarchie des langages rationnels [ALP92]. Dans le chapitre 4, nous développerons les aspects autour de la compilation des chronogrammes. Dans un premier temps, nous présenterons les principes de base des compilateurs des chronogrammes dits statiques en montrant comment la structure ab- straite du langage est importante dans ce type de compilation. Nous montrerons ensuite comment, grâce à un couplage entre cet algorithme et les algorithmes de vérification basés sur la logique CTL, on peut vérifier des propriétés qui ne sont pas compilables directe- ment dans aucun des deux formalismes. Puis, nous nous engagerons dans une explication détaillée du générateur de SIGNAL et introduirons celui de SVHDL dont un exemple sera présenté dans les annexes A et B. Dans le chapitre 5, nous aborderons les perspectives de ce type de langage dans des problèmes très différents de la validation de matériel. Nous mettrons en valeur la puis- sance de la structure abstraite de CHLOE dans ses aspects génériques, ainsi que la manière dont le contrôle de l'édition est réalisé dans le logiciel. Nous introduirons au travers d'un exemple comment la structure abstraite de CHLOE peut être la base d'un outil générique de tableur o les règles de gestion seront paramétrables. Puis nous préciserons les tech- niques d'édition et de programmation utilisées dans CHLOE en montrant en quoi elles sont originales et quels sont leurs avantages. Nous terminerons en présentant des idées sur les futures recherches qui pourraient graviter autour des chronogrammes. Chapitre 2 La syntaxe du langage Chloe 2.1 La syntaxe concrète par l'exemple La définition syntaxique et sémantique du langage de chronogrammes CHLOE se fera au travers d'un exemple d'automate qui servira de trame à ce chapitre. Cet exemple perme- ttra de découvrir simplement l'ensemble des primitives du langage CHLOE au travers de propriétés de plus en plus complexes, et de connaître les correspondances dans la syntaxe concrète de ces différentes primitives. Cela permettra aussi d'apercevoir la puissance du langage dans sa généralité et dans ces futurs développements. 2.1.1 L'automate des couleurs L'exemple que nous allons développer, correspond à la description d'un l'automate représentant une palette de couleurs et les possibilités de mélanger ces couleurs, cf. figure 2.1. Ici, nous plongerons cet automate dans un environnement synchrone. On supposera donc que l'animation de l'automate est cadencée par une horloge discrète que nous ap- pellerons "Clock". A chaque front montant de l'horloge, le message d'entrée envoie une valeur qui correspond à l'une des trois couleurs primaires (BLEU, JAUNE, ROUGE). Suiv- ant l'état courant de la machine représenté par le signal "Etat" et suivant la valeur de ce signal 'Entree, la transition est alors déclenchée, l'état au cycle suivant est alors calculée et la la valeur de sortie est envoyée sur le signal "Sortie". Les valeurs du signal "Etat" et du signal "Sortie" seront soit des couleurs primaires (BLEU, JAUNE, ROUGE), soit des couleurs résultant du mélange de couleurs (VIOLET, ORANGE, VERT, BRUN). Dans la figure 2.1, les pastilles représentent les différents états possibles de l'automate identifiés par le nom inscrit dedans. Les flèches représentent les transitions possibles en- tre deux états. Elles sont provoquées par la réception d'un message. Sur ces flèches, on a les valeurs possibles du signal d'entrée "Entree' précédées du "?"' qui représente l'ensemble des valeurs qui permettront la transition, et la valeur du signal de sortie "Sortie" précédées du "!". Automate des couleurs :hem.a hm-h tzj?% " _n. Figure 2.1: L'automate des couleurs Ici le principe du mélange des couleurs est simplifié. En particulier, les aspects quan- titatifs sont éliminés. 2.1.2 L'édition de propriétés de l'automate dans CHLOE Après avoir donné la représentation de l'automate des couleurs, nous allons maintenant énoncer un ensemble de propriétés à son sujet qui ne seront pas nécessairement vérifiés par l'automate de la figure 2.1. Nous nous limiterons dans un premier temps à des propriétés de sûreté. 1. Si on est BLEU, qu'on lit JAUNE, alors on écrit VERT et on est VERT au pas suivant. 2. Si on est BRUN, alors on le reste (BRUN est un puit). 3. Si on lit ce que l'on est, alors on le reste. 4. Si on change deux fois de couleur consécutivement, alors on est marron (BRUN) 5. On écrit toujours la couleur qu'on a au pas suivant. La propriété (1) spécifie un exemple de transition dans l'automate en donnant ex- plicitement le nom des valeurs de l'état, la propriété (2) caractérise la seule transition possible à partir d'un état donné, la propriété (3) spécifie un sousensemble des tran- sitions de l'automate grâce à des pronoms, la (4) spécifie un ensemble de chemins de l'automate et la (5) donne une relation entre les valeurs des signaux. En observant l'ensemble de ces propriétés, on s'aperçoit qu'elles ont en fait à peu près toutes la même structure. Les propriétés (1), (2), (3), (4) suivent le même schéma: Si on reconnaît tel comportement sur un ensemble de signaux alors on doit reconnaître tel autre comportement sur un autre ensemble. La propriété (5), si elle vient naturellement sous la forme donnée précédemment peut en fait se réécrire en utilisant une variable, de la façon suivante: * Si au temps t, le signal Etat porte la valeur VAL (VAL E { BLEU, JAUNE, ROUGE, ORANGE, VERT, VIOLET}) alors le signal Sortie porte aussi la valeur VAL au temps t-1. On va maintenant traduire toutes les propriétés en mathématique pour les introduire dans les chronogrammes; on posera que front(Clock) est égal à l'ensemble des instants valides pour l'horloge Clock. L'horloge est la même pour les trois signaux. Cet ensemble est en général 7Z muni de l'opérateur "+" En fait dans les chronogrammes, il n'y a pas de notion de temps initial, c'est pourquoi on choisit Z comme ensemble de référence. On définit alors une fonction associée à chaque signal: Entree: front(Clock), * {BLEU, JAUNE, ROUGE} Etat: front(Clock), b {BLEU, JAUNE, ROUGE, ORANGE, VERT, VIOLET} Sortie: front(Clock),, {BLEU, JAUNE, ROUGE, ORANGE, VERT, VIOLET} Les propriétés peuvent alors s'exprimer de la manière suivante: 1. VtE front(Clock), Etat(t)=BLEU et Entree(t)=JAUNE _ Sortie(t)=VERT et Etat(t+1)=VERT. 2. VtE front(Clock), Etat(t)=BRUN. Etat(t+1)=BRUN 3. étE front(Clock), Etat(t)=Entree(t) --, Etat(t+l)=Etat(t) 4. VtE front(Clock), Etat(t) q Etat(t+l) et Etat(t+2) # Etat(t+l) Etat(t+2)=BRUN 5. VtE front(Clock), Etat(t) = Sortie(t-1) Nous allons dans un premier temps donner deux exemples de chronogrammes de types différents. Le chronogramme de la figure 2.30 que l'on appellera évolue rassemble les pro- priétés (3), (5), (1), (2) représentées dans cet ordre. Elles sont définies grâce à des flèches reliant les hypothèses aux conclusions de chaque propriété. Le second chronogramme de la figure 2.4 présente la quatrième individuellement dans un chronogramme dit primitif qui servira de base aux générateurs de code. Nous rentrerons beaucoup plus dans les détails des différents objets syntaxiques dans la section suivante. 4ORI OGE Figure 2.2: Les propriétés (1), (2), (3), (5) dans un chronogramme de CHLOE Dans le chronogramme de la figure 2.30, peuvent être observées des zones de deux types: Les grises et les blanches. Les zones grises (normalement uniforme) correspondent à tout ce qui est affiché par le gestionnaire hôte. Elle ne participe pas à la définition du chronogramme. En revanche, les zones à fond blanc constituent le chronogramme proprement dit. Ces zones sont organisées en lignes. Dans le chronogramme 2.30 il y a quatre lignes. La première est composée de quatre zones. Dans la petite zone à gauche est inscrit l'identificateur de l'horloge de référence du chronogramme qui est l'horloge du modèle à valider. La zone immédiatement à droite porte des créneaux. Cette zone à créneau définit une bande verticale traversant le chronogramme dans toute sa hauteur. Une telle bande est appelée une "multi-colonne statiqu'e, une autre multi-colonne statique est définie par la dernière zone à droite du chronogramme. La zone intermédiaire toute blanche définit une multi-colonne de statut différent appelée mu/ti-colonne dynamique. Les trois lignes suivantes sont composées de deux zones. La première o sont écrits les nom des signaux qui sont observés. Il n'existe qu'un seul signal par ligne en revanche plusieurs lignes peuvent faire référence au même signal. L'ordre de ces lignes n'a pas de sémantique, il est souvent motivé par la coplanéarité du graphe. Les longues zones de droite sont remplis d'intervalles. La première faisant référence au signal de sortie Sortie est composée de de deux intervalle de statut BLEU, suivi d'un intervalle dont le statut est un symbole "Val' qui n'est pas définie explicitement mais qui prend sa valeur dans l'ensemble des valeurs possibles du signal (dans le cas du signal Sortie, VAL E {BLEU, JAUNE, ROUGE, ORANGE, VERT, VIOLET}). Ces trois intervalles sont larges d'un cycle d'horloge. Le quatrième intervalle appartenant toujours à la première multi-colonne statique porte le statut IRRELEVANT c'est à dire que le comportement de ce signal pendant ce cycle d'horloge n'est pas significatif. Le reste de la ligne est défini de la même façon. La première étape est donc de définir cette matrice ou scène que l'on peut dessiner en alignant de la sorte les intervalles. Sur cette scène, certains intervalles sont sélectionnés et constituent des blocks entourés d'un cadre en trait gras. Ces blocks sont reliés par des flèches. Les blocks situés du côté sans chevron de la flèche forment l'hypothèse, et ceux placés du côté avec chevron forment la conclusion. On aura donc toujours cette structure binaire hypothèse-conclusion. Ici la position d'une propriété par rapport aux autres définies sur le même chronogramme n'a pas de signification. Figure 2.3: La propriété (5). Dans la figure 2.4 ci-dessus, nous ne sommes plus dans la même classe de chronogrammes. Dans ce type de chronogramme appelés primitif, on ne peut éditer qu'une seule propriété à la fois. La structure binaire est ici clairement définie. Il existe donc deux scènes ayant la même structure que celle utilisée dans le chronogramme évolué (horloge, zones, lignes, intervalles...). La scène du haut représente l'hypothèse de la pro- priété, celle du bas la conclusion. Les deux scènes sont de même largeur, et comprennent une multi-colonne statique large de trois cycles d'horloge. Ici on remarque que la mention de deux intervalles de l'hypothèse comporte un tiret. Ce tiret signifie le passage au com- plémentaire. Ainsi '-BLEU' signifie n'importe qu'eUe valeur différente de BLEU(JAUNE, ROUGE, ORANGE, VERT, VIOLET) et ici le tiret affecte une valeur symbolique 'Val' alors si Val est égal à z, alors -Val définit l'ensemble de toutes les valeurs admises par le signal mais différente de z. Après avoir donné des exemples de propriétés de sûreté sur des chemins de longueur fixe, il est aussi intéressant de spécifier ce type de propriétés sur des chemins de longueur variable. C'est la cas par exemple de la propriété suivante: À Si on change deux fois de couleur, alors on est BRUN Cette propriété ressemble à la propriété (4), mais ici on ne dit pas que les transitions doivent se produire consécutivement mais dans un temps fini. Elle se traduit dans une structure Hypothèse- Conclusion sous la forme suivante: VVAL E {BLEU, JAUNE, ROUGE, ORANGE, VERT, VIOLET}, VtI, t2, t3, t4 E front(Clock) tel que t1 On remarque dans ce chronogramme l'apparition de colonne o l'horloge est entière- ment blanche et qui sont appelées des DynSyn-rea. Elles permettront de définir des zones de temps indéfini o le nombre de cycles d'horloges n'est plus explicitement défini. L'autre avantage de ces zones est qu'elles permettent de représenter des propriétés de vivacité du système. Par exemple, 1. Si on est "BLEU", alors on sera nécessairement 'BRUN' dans le futur. Cette propriété n'est pas vérifiée par l'automate des couleurs tel quel. Il est néces- saire de rajouter une hypothèse supplémentaire sur l'automate; on ne peut pas transiter infiniment sur les états "BLEU", uVIOLET", "VERT" et donc on est obligé de passer par l'état "BRUN". Elle se traduit dans une structure Hypothèse-Conclusion sous la forme suivante: Vt E front(Clock), 3t' E front(Clock), t'> t et Etat(t) = BLEU==> Etat(t') = BRUN On l'illustrera dans le chronograimme suivant 2.5 o la partie supérieure représente l'hypothèse de la propriété (Vt tel que Etat(t) = BLEU) et la partie inférieure représente la conclusion (3t', t' > t tel que Etat(t') = BRUN), On remarque là aussi les colonnes o l'horloge est entièrement blanche (DynSynArea) qui grâce à l'absence de contrainte dans la dernière colonne de l'hypothèse permettent dans le cas présent de représenter la vivacité: Figure 2.5: Un exemple de propriété de vivacité On peut ainsi en utilisant les DynSynirea spécifier des propriétés de récurrences [MP92J. Si l'on pose comme hypothèse supplémentaire sur l'automate que l'on ne peut pas transiter infiniment sur tous les états différents de "BRUN", on a alors la propriété suivante: On passe une infinité de fois par l'état "BRUN" ". Ceci se traduit dans une structure Hypothèse-Conclusion sous la forme suivante: Vt 3 t', t' > t tel que true=*: Etat(t') = BRUN Elle se représentera alors par le chronogramme suivant: Figure 2.6: Un exemple de propriété de récurrence infnie Les trois dernières propriétés sont représentées par des chronogrammes primitifs, et on touche déjà aux limites ergonomiques de ce type de langage graphique. Bien sur, il est aussi possible de les intégrer dans un chronogramme évolué de même type que la figure 2.30 avec des formes graphiques spécifiques, mais dans les cas les plus complexes, les formes textuelles ou liant du texte et des chronogrammes semblent plus appropriées. 2.2 La syntaxe abstraite Nous allons dans un premier temps définir l'ensemble de la grammaire du langage des chronogrammes sous la forme de TSD(Type-Structure Diagrams) [DL91]. Ce formalisme graphique permet de donner une définition des différents types de CHLOE dans le langage VDM Vienna Development Method [Daw92]. Il a été utilisé pour spécifier formelle- ment la grammaire du langage CHLOE. Ce langage graphique et tout l'environnement logiciel regroupé sous le nom VTP (VDM through Pictures) [Lou9l] développés au centre de recherche de BULL permettent au nonspécialiste de spécifier en VDM. Une introduction rapide de ce formalisme est donnée dans l'annexe F Dans un deuxième temps, nous donnerons la représentation dans la syntaxe concrète de chaque règle de la grammaire. Nous expliquerons ensuite les raisons qui nous ont amenés à choisir les différents objets en essayant d'avoir le meilleur compromis entre la minimalité du langage primitif et les contraintes d'efficacité dans la décompilation d'un arbre syntaxique dans les différents langages. 2.2.1 Le langage sous la forme TSD Dans cette section nous allons donner l'ensemble du langage CHLOE sous la forme TSD. Nous développerons dans un deuxième temps chaque noeud des différents arbres, en don- nant leur définition en VDM, puis leur représentation sous la forme TSD avec la corre- spondance dans la syntaxe concrète, puis leur rôle pratique dans l'édition des propriétés. ---. ... ----- I à------1 I à ijt * Primitive Evo e Figure 2.7: Les ch. ronogram.mes de CHLOE Cette première figure, montre la séparation dès la racine des deux langages de chronogrammnes, primitif et évolué. Dans la figure 2.8 nous développerons en premier lieu le langage évolué des chronogrammnes. On remarquera la structure de ce langage. Avec à gauche la description des Scenedont nous avons rapidement décrit l'aspect concret dans la section 2.1, et à droite la description des propriétés que l'on veut exprimer dans cette Scene. Ces propriétés sont composées de blocks dont la définition est recursive (yN8.81. Ceci pour faciliter l'expansion vers les chronogrammnes primitifs et pour permettre des développements futurs vers une hiérarchisation des chronogrammnes. Dans la figure 2.9 nous développerons le langage primitif des chronogrames. On remarquera alors une forte similitude entre la structure de Scene d'un chronogramme évolué et les BasicScene d'un chronogramme primitif Cette similitude corrobore la forte ressemblance des aspects concrets de chaque scène. Mais dans les BasicScene chaque noeud possède un champ optionnel supplémentaire "signe" très important dont on développera l'intérêt dans la section suivante. i". KATEB_Om-m Ij.-- Tm mmmmw -.,,,,,w,., ,.- ---- LT-- - Figure 2.8: Les chronogrammes évolués de CHLOE B."---- top dona Piat wr&" DeD locadom -ifl : - t é ____ -----T '* &== f -* | T I I ' Figure 2.9: Les chronogrammes primitifs de CHLOE 2.2.2 Le langage CHLOE En entête de chaque point du langage nous donnerons la définition en VDM textuel du type à définir. Des copies d'écran sont associées à certains nceuds et correspondent à leur aspect concret dans l'éditeur existant. Chronograma = Primitive | Evolutedj La première règle de la grammaire définit l'ensemble des chronogrammes qui peuvent être édités grâce à l'environnement logiciel autour du langage CHLOE. Les chronograrnmes de CHLOE sont donc divisés en deux catégories: 1. Les chronogrammes évolués (Evoluted) qui composent le langage utilisateur. 2. Les chronogrammnes primitifs (Primitive) qui serviront de base aux générateurs de code vers les outils de preuve ou de spécification. AI...... -1- 9---- ----w e. .... 1...... - mû_ w Figure 2.10: Les chronogrammes de CHLOE La séparation des chronograxnmes dans ces deux catégories est devenue indispensable avec une utilisation pratique de l'outil. En effet, l'éditeur du langage des chronogrammes évolués possède des avantages ergonomiques qui le rendent plus attractif et plus convivial que l'éditeur de propriétés dans le langage primitif, édition de plusieurs propriétés dans un même chronogramme, possibilité de recouvrement des intervalles qui est impossible dans le langage primitif. . Et, il est amené à se développer au fur et à mesure des demandes des utilisateurs autant du point de vue de la syntaxe concrète qu'abstraite. Cela entraînerait des mises à jour importantes des générateurs de code ainsi que de la sémantique formelle..DTD: des chronogrammes. La formalisation d'un langage primitif a permis de pallier à ce problème en fixant une fois pour toutes la sémantique formelle des chronogrammes ainsi que les générateurs de code sur le langage primitif, et les mises à jour ne seront alors réalisées que sur l'expanseur des chronogrammes évolués vers les chronogrammes primitifs. Les fonctionalités supplémentaires indispensables pour les utilisateurs, n'augmenteront pas la puissance sémantique du langage, dans le sens o toutes les propriétés spécifiées dans un chronogrammne évolué doivent toujours pouvoir avoir un sens et donc s'éditer sous la forme primitive, moyennant un algorithme d'expansion. En revanche, elles permettent de suivre au plus serré les habitudes des concepteurs en donnant entre autres, la possibilité de spécifier plusieurs propriétés dans un même graphique de base. Nous allons maintenant développer les différents objets qui définissent chacun des ces deux sous-langages en commençant par le langage utilisateur. Le langage utilisateur 1. Evoluted:: properties: BinaryProporties+ backgrournd: scène Un chronogramme évolué est composé de deux champs. Le champ backgrournd est une scmne o l'utilisateur définit un exemple de comportements des signaux à travers le temps. Sur cette Scene qui correspond au support du chronogramme mais qui n'a pas de sémantique du point de vue de la vérification ou de la spécification d'un circuit, l'utilisateur pourra extraire les différentes propriétés qui lui paraissent importantes à spécifier. Elle seront alors introduites au fur et à mesure dans la liste des propriétés BinaryProperties. riJ T1J i-u- I-J - _N' I m-i Figure 2.11: Les chronogrammes évolué 2. Scono= (TermI-set x (Dynsyn rea 1 stasynirea)+ La Sclne correspond donc à un exemple de comportement du système à vérifier ou à spécifier. Cet exemple peut par ailleurs ne pas avoir de sens globalement. Elle est tout d'abord composée d'une horloge Clock. Pour le moment, les chronogrammes..DTD: que CHLOE peut éditer et surtout compiler, sont des chronogrammes synchrones. Ils possèdent donc une horloge qui synchronise les evenements sur les fronts de cette horloge. L'extension aux chronogrammes asynchrones peut être réalisée en suppri- mant cette horloge, mais aucune sémantique n'a pour l'instant été définie. La Scene possède aussi l'ensemble des signaux qui interviennent dans le chrono- gramme, ces signaux peuvent être soit des entrées, soit des sorties, soit des sig- naux internes du système. Mais il n'est pas nécessaire de le spécifier, car dans les chronogra.mmes de CHLOE, tous les signaux ont le même statut, on ne définit pas des propriétés de causalité entre les entrées et les sorties d'un système mais des con- * traintes temporelles entre deux ensembles de signaux qui appartiennent au système, que ce soit des entrées, des sorties ou des signaux internes. Du point de vue des chronograrnmmes de CHLOE, ils participent tous et au même niveau à la définition de la contrainte. Après avoir spécifié l'horloge et les différents noms des signaux, l'information sur le comportement des signaux à travers le temps sera définie par une suite de zones statiques StaSynArea ou dynamiques DynSynkrea. .4 ---...... l I I Sce 7.., - 3. Clock:: name: Torma L'horloge, lorsqu'elle existe, cadence les événements sur ses fronts montants ou de- scendants. Dans ce cas là, aucun événement ne peut apparaître entre deux fronts de même type. Pour l'instant, il n'existe qu'une seule horloge pour une Scene, on peut imaginer l'extension du langage pour donner la possibilité à certains signaux d'être synchronisés sur les fronts d'une autre horloge plus ou moins déphasée ou suréchantillonée. 4. StaSyn- rea:: DynSynArea pattern: Line+ pattern: Line+ location: RelativeLocation location: RelativeLocation RelativeLocation:: RelativeLocation:: width:IN rank:IN rank:IN idth: M..Segment T!'i............l. g......*t.................. ..............llieHefle ile e)e W lMT RelatveLoaliau AU rank width..DTD: /' r-- ----- I "'"* ',------------ L- Figure 2.13: Les zones statiques dans une scène On a donc deux types de zones que l'on appellera des multi-colonnes, qui se suivent pour créer une Scene. La structure interne de ces zones est très proche. En effet, les StaSynAtrea (pour Static Synchronous Area) comme les Dynsynàrea (pour Dynamic Synclironous Area) sont composées d'une liste de lignes Lino représentant la liste des signaux présents dans la scene. Cette liste ne sera jamais vide car il existe toujours au moins un signal dans une scene. Il y aura le même nombre de lignes dans toutes les multi-colonnes appartenant à une même Scene. L'autre point commun entre les staSynrea et les DynSynArea, est l'obligation de spécifier leur place dans la liste des multi-colonnes. Cela est indispensable pour recalculer les coordonnées globales des intervalles par rapport à la Scene entière. L'ordre des multi-colonnes est donc très important. C'est dans la composition des différentes multi-colonnes faite grâce à ce champ que l'ordre temporel dans lequel on souhaite que les comportements spécifiés dans chaque multi-colonne se réalise est défini. La différence fondamentale que l'on a entre les deux types de multi-colonnes, est ce que l'on appelle leur largeur temporelle, celle-ci est spécifiée par le champ width: (a) Pour les StaSynArea, la largeur de la multi-colonne est fixe, définie statiquement lors de la création d'un chronogramme. Elle correspond à un entier positif qui est égal au nombre de périodes que l'horloge réalise pendant cette StaSynArea. Dans les StasynArea, toutes les périodes de l'horloge sont représentées une à une dans la syntaxe concrète et c'est le placement par rapport à ces périodes qui va permettre de calculer les bornes des intervalles. (b) Pour les DynSynArea, la largeur n'est plus un entier positif mais un segment dans IN(uwidthest de type MSegment), cela permet de définir des largeurs variables de multi-colonnes, elle sera donc définie dynamiquementlors de la vérification des chronogrammes. Ici les créneaux de l'horloge ne sont plus représentés dans la syntaxe concrète, la zone spécifiant le type de l'horloge est alors entièrement blanche. Deux cas sont possibles en fonction de la borne supérieure du segment définissant cette largeur: M.Segment:: lowerbound: Bound upperbound: Bound[Inf inteBound Bound:: value: IN status: CLOSED I OPEN InfinteBound:: value: INFINTE status: OPEN voue \ vMaboad AnMs Figure 2. 14: Les segments des multi-colonnes dynamiques Dans le cas o le champ upperbound du champ idth, correspondant à la borne supérieure du segment, est fini, les DynSynrea permettent de réaliser dans un même chronogramme, la disjonction finie de StaSynArea. Cette possibilité, même pour les cas finis est très intéressante, car on comprend bien que si la différence entre les deux bornes du Segment est par exemple de 50 périodes, il est très fastidieux pour l'utilisateur de réaliser les 50 cas un par un. De plus, seul la composition de chronogrammes par conjonction est définie dans le langage. Dans le cas o le champ upperbound du champ width est infini (INFINTE), les DynSynArea permettent de spécifier des conjonctions infinies de propriétés de sûreté ce qui augmente considérablement la puissance du langage: ces conjonctions infinies de propriétés de sûreté peuvent définir des propriétés de vivacité. On pourra alors définir des propriétés spécifiant l'arrivée inévitable d'un événement dans le futur, cf. figure 2.34. Nous développerons ces différents cas dans la définition de la sémantique des chronogrammes. Par défaut, on aura le champ lowerbound égal à O, et le champ upperbound infini. 5. Linoe:: pattern:Interval+ term: Terns Nous avons vu que les StaSynhrea comme les DynSynArea sont composées d'une liste d'objets de type Lino. Il existe pour chaque ligne un identificateur de signal Term appartenant à Terns-set de la Scene qui correspond au nom du signal qui est référencé. Dans les chronogrammes de CHLOE, plusieurs lignes peuvent faire référence au même Teras donc au même signal car il est important de pouvoir composer aux mêmes instants plusieurs contraintes sur un même signal. Une ligne est aussi et surtout composée d'une liste d'objets de type Interval. Ces objets donnent le comportement souhaité du signal dans un intervalle temps donné par rapport à l'horloge de base et par rapport au début de la multi-colonne. _ _ term pattern !------ -!- - - -I - lcat EventR Les intervalles sont les objlignes dansrmi les pluzones imporstatiquents ou dynamge. 'informationques 6. Interval:: location:Segment st atu: Eveont |IRRELEVANT | StableVal Les intervalles sont les objets parmi les plus importants du langage. L'information concernant le comportement du signal à travers le temps est concentrée dans les différentes feuilles de l'objet Interval. La structure d'un intervalle est composé de deux champs. Tout d'abord le champ location, c'est-à-dire la position relative des bornes de l'intervalle par rapport à la StaSynirea ou à la DynSynArea à laquelle appartient sa Line. Le calcul de ces positions relatives est très différent dans les deux cas, cf. figure 2.16): (a) Dans une StaSynxrea, le calcul des bornes est réalisé par rapport à l'horloge de base du chronogramme. En fait, chaque période de l'horloge définit un numéro de colonne auquel les bornes de l'intervalle vont faire référence. (b) Dans une DynSynkrea, l'horloge de base n'étant plus spécifiée, la longueur de l'intervalle par rapport à l'horloge de base est par définition variable. On définit alors les différentes colonnes, graphiquement en fonction de tous les intervalles de la DynSyn rea. Une colonne correspond à une période o aucun signal ne change d'intervalle. A partir du moment o un signal quitte un intervalle il y a création d'une nouvelle colonne. Nous donnons dans la figure suivante, un exemple de calcul de bornes d'un intervalle appartenant à une StaSynArea puis à une DynSynàrea. STASYNAREA Borne Inferleure ega/e 3 Borne aupeerure ega/e a 5 DYNSYNAREEA !'_- Borne nfereure ega/e 2 Borne aupeture 0/e a 3 Figure 2.16: Calcul des bornes d'un intervalle Le placement dans le temps étant défini, il est nécessaire de définir le statua de cet Interval, c'est-à-dire le type de comportement souhaité du signal pendant le temps défini par le champ location Il existe deux classes de statuts possibles (les Event et les StableVal), plus un statut particulier (IRRELEVANT) qui permet de spécifier la complète indifférence au comportement du signal pendant cet intervalle de temps. Un intervalle dont le status est IRRELEVANT est équivalent dans un chronogramme, aux parties d'une ligne qui n'appartiennent à aucun intervalle. Ce statut est utile car il permet à un utilisateur de contrôler qu'il a bien rempli toutes les lignes, sans oublier de spécifier explicitement à certains endroits le comportement des signaux. La séparation des autres statuts en deux classes est nécessaire, car nous verrons que le schéma sémantique est bien différent pour chacune d'entre elles. (a) Stable Val correspond à la classe des statuts spécifiant une stabilité de la valeur du signal tout au long de l'intervalle. (b) Event correspond à la classe des statuts spécifiant l'occurrence d'un événement particulier dans l'intervalle, c'est-à-dire d'un changement de valeur. Intervai / \ locaton au Segment I - --------- * Event I IREEVN Stable Val I_________*- I_________,- Figure 2.17: Les intervalles dans les lignes d'un chronogramme évolué 7. Segment:: lowerbound: Bound upperbound: Bound Bound:: value: 1N statua: CLOSED OPEN Les Segment définissent positionnement relatif des différents intervalles. Ils sont différents des MSegment des multi-colonnes car leurs bornes sont toujours finies. Les intervalles de la classe des StableVal sont toujours des intervalles ouverts. En revanche, pour les intervalles de la classe des Event, il est intéressant d'avoir des intervalles fermés ou semi-fermés. Cela permettra de spécifier que l'occurrence de l'événement peut se produire sur ces bornes. Cela est très important, surtout dans les DynSynArea. Par exemple, si la borne inférieure de l'intervalle est fermée et est synchronisée sur un événement arrivant sur un autre signal, on définit alors que l'événement va se produire en même temps que l'autre ou après lui. Sans les intervalles fermés, cela est impossible. I.ibnd uppnbed aaun V Figure 2.18: Les segments dans IN Nous arrivons maintenant aux objets qui sont paramétrables suivant le type de chronogrammes que l'on veut éditer grâce à CHLOE. Les différents statuts que nous allons voir, sont des exemples de valeurs possibles de statuts de la classe Event ou de la classe StableVal pour l'automate des couleurs. La sémantique de ces statuts sera définie comme une contrainte résultant de la composition des contraintes des statuts BEvent et BStableVal dont la sémantique est formellement définie dans le langage primitif. Cela est indispensable pour permettre la génération de code en vue de la vérification ou de la spécification de circuits. 8. StableVal:: définition: [Expression] meaning: STABLE Expression:: signe: [COMPLEMENTARY ezpression: (JAUNE | VERT | ORANGE | ROUGE | BLEU | VIOLET | BRUN) | Variable La définition de la classe des statuts stables se fait en deux parties. C'est d'abord la spécification de la stabilité grâce au champ meaning, puis si nécessaire la définition de la valeur de stabilité grâce au champ optionnel définition. Si rien n'est défini sur la valeur du signal, c'est-à-dire s'il n'existe pas de champ definition, alors la seule contrainte que l'on a sur le signal, est qu'il ne doit jamais changer de valeur dans l'intervalle. Si le champ définition n'est pas vide, il définit alors une contrainte supplémentaire sur la valeur que le signal porte. Elle appartiendra alors à l'ensemble des valeurs définies dans le champ expression Elle sera soit un symbole correspondant à un comportement précis du signal (JAUNE, VERT,..., BRUN) soit ce que l'on appelle une valeur symbolique spécifiée par un symbole Variable. Ce symbole (par ex- emple "Val" dans l'exemple de l'automate des couleurs) correspond à n'importe quelle autre valeur (toujours stable) appartenant à l'ensemble précédent. Utilisé par plusieurs intervalles, il représentera alors la même valeur, et cela permettra de définir des relations entre les valeurs portées par différents signaux sans les donner explicitement. Les relations que l'on peut donner pour l'instant entre ces différentes valeurs seront soit l'égalité, soit le complémentaire qui revient à ajouter le champ optionnel signe à la définition. Ce champ permettra de spécifier des relations d'exclusion entre des valeurs des signaux. Ce champ pourra aussi être utilisé pour l'ensemble des valeurs fixes (JAUNE, VERT,..,BRUN) pour spécifier l'ensemble des comportements stables du signal mais qui ne porte pas cette valeur. Par exemple, complémenter l'expression BLEU correspond à la disjonction des expressions ROUGE, ORANGE, JAUNE, VERT, VIOLET, BRUN. Dans un deuxième temps on pourra imaginer com- piéter ces relations, en donnant la possibilité d'introduire des expressions logiques, que ce soit des valeurs symboliques ou des valeurs fixes. a, i.. Figure 2.19: Les valeurs stables dans l'exemple de l'automate des couleurs 9. Event:: definition: [Expression] meaning: EDGE Expression:: signe: [COMPLEMENTARY ezpression: BLEUVIOLET | ROUGEVIOLET IROUGEORANGE JAUNEORANGE I BLEUVERT | JAUNEVERT VERTBRUN I ORANGEBRUN I VIOLETBRUN : a. Figure 2.20: Les événements dans l'exemple de l'automate des couleurs La structure de la classe des Event suit de près celle des statuts stables. Le champ meaning définit qu'il existe une et une seule transition sans préciser son type, cela correspond donc à un et un seul changement de valeur durant l'intervalle. Le champ definition lorsqu'il existe définit le type de transition qui est contraint. Par exemple, S'il est égal à "BLEUVERT" cela correspond alors à une et une seule transition de BLEU vers VERT, il peut donc exister d'autre type de transition durant cet intervalle. Dans cet exemple, seul un sous-ensemble des transitions possibles a été spécifié car pour l'automate des couleurs il est impossible d'avoir par exemple une transition du type BRUNVIOLET (cf figure 2.30 BRUN est un puit). Dans cet exemple, toutes les transitions possibles n'ont pas été données. Par rapport à l'automate des couleurs défini ??, les autres transitions ne peuvent pas se produire. Le champ signe a ici le même comportement que celui de la classe StableVal. Par exemple, complémenter l'expression BLEUVIOLET correspond à la disjonction des expressions RoUGEVIOLET, ROUGEORANGE, JAUNEORANGE, BLEUVERT, JAUNEVERT, VERTBRUN, ORANGEBRUN, VIOLETBRUN. 10. BinaryProperies:: hypo: Hypothesis conc: Conclusion Hypothesis:: composition: Operator element: Bloc+ Conclusion = Block+ Operator = OR [ AND Block = Evoluted Uo -, Figure 2.21: Les propriétés dans un chronogramme évolué Après avoir défini la Scene, il est maintenant important de spécifier l'ensemble des propriétés que l'on veut définir sur cette Scene. Ces propriétés sont binaires dans le sens o elles ont toujours deux composantes qui spécifient l'hypothèse, Hypothesis, et la conclusion, Conclusion, de la propriété. Pour l'instant, cette structure suit de près la structure des BasicBinaryPp car ces BinaryProperties devront être expansées sous forme primitive pour leur étude ultérieure. On pourra imaginer des structures qui ne seront pas binaires pour définir des propriétés de récurrences [MP92], des comportements périodiques, ou des signaux invariants o l'algorithme d'expansion sera à chaque fois très spécifique. Les champs Hypothesis et Conclusion sont composés d'une liste d'objets de type Block qui ont la même structure que le type Evoluted. Dans la syntaxe concrète il n'y a pas de duplication d'information: les intervalles appartenant aux Block et à la Scene sont représentés par le même objet graphique. Mais dans la syntaxe abstraite, on réinjecte toutes les informations utiles à la création d'un nouvel Evoluted pour permettre une expansion facile, ainsi qu'une hiérarchie dans les Evoluted. Cela sera très utile dans l'optique de récupération de blocks entiers comprenant aussi leurs propriétés pour une utilisation dans d'autres chronogrammes. Cette particularité des noeuds Block fait de la grammaire de CHLOE une grammaire récursive. On remarque que seuls les Block de l'Hypothesis possèdent un opérateur de compo- sition. Pour des raisons essentiellement ergonomiques la possibilité de réaliser des disjonctions de Block de la Conclusion n'est pas encore permise. L'opérateur de composition pour les Block de la Conclusion sera donc par défaut le 'AND' ce qui correspond au regroupement de tous les Block dans une même BasicScene. Pour l'Hypothesis, si l'Operator est égal à "OR", cela correspond à la conjonction des propriétés pour chaque Block de l'Hypothesis vers tous les Block de la Conclusion. Le langage primitif 1. Primitive:: BasicProp: BasicBinaryPp signe: [NOT] BasicBinaryPp:: down: BasicScene top: BasicScene Nous avons ici la définition syntaxique d'un chronogramme dans le langage primitif qui servira de base à la définition sémantique des chronogrammes. Les chronogramrnes primitifs définissent pour l'instant des propriétés binaires, com- posées de deux BasicScene, le dowm et le top qui représentent respectivement l'hypothèse et la conclusion de la propriété. La sémantique que l'on donne à ce type de propriété est: Chaque fois que l'on reconnaît le comportement défini par le top de la propriété on doit alors reconnaître le comportement défini par le down. topdo n 1-- Figure 2.22: Le langage primitif Nous voyons ici apparaitre le champ signe qui permet d'augmenter considérablement la puissance du langage CHLOE. Ce champ, placé au niveau d'une propriété, permet de nier la propriété, ce qui revient à poser l'existence d'une configuration et donc nous pouvons dire: Il existe une configuration des signaux o l'on a reconnu le comportement défini par le top de la propriété mais o l'on n'a pas reconnu le comportement défini par le donm. 2. BasicScene:: background: (Terms-set x ( DynBasirea | StaBasArea)+ x Clock) signe: [NOT] La BasicScene possède une structure proche de la Scene d'un chronogramme évolué mais sera composée de DynBasArea ou de StaBasàrea à la place des DynSynàrea et de StaSynArea. Elle possède le champ Clock qui est exactement le même que celui défini dans une Scene. En revanche, elle possède aussi un champ optionnel supplémentaire qui n'existe pas dans les Scene et qui va permettre de nier une BasicScene ce qui correspond à accepter tous les comportements des signaux à travers le temps qui ne satisfont pas le background. Le NOT de la BasicScene permet donc aussi d'augmenter la puissance d'expression du langage en donnant la possibilité de définir des exclusions de comportement. Par exemple, la sémantique d'une propriété o l'on a nié la conclusion est Chaque fois que l'on reconnaît le comportement défini par le top de la propriété alors on ne doit pas reconnaître le comporte- ment défini par le background du down. L'ensemble des signaux se définit de la même façon, mais les signaux qui apparti- ennent à cette liste ne sont pour l'instant que booléens. Cette limitation est due au fait que les outils de preuve qui sont connectés à l'environnement CHLOE ne manipulent bien que des signaux booléens. L'extension au type alpha-numérique ne change pas la structure du langage, mais ne peut pas être intégrée pour l'instant à cause des niveaux de complexité que cela entraîneraient dans leur utilisation: risque de perte de décidabilité. La structure de l'horloge est la même et correspondra à l'horloge du système à vérifier ou à spécifier. Les extensions définies sur les chronogrammes évolués tel le multi-horloges ou les chronogrammes asynchrones, ne sont pas encore définies formellement. A-"'G Figure 2. 23: Les scènes dans un chronogramme primitif 3. StaBaszArea:: DynBasArea: pattern: BasicLine+ pattern: BasicLine+ location: RelativeLocation location: RelativeLocation signe: [NOT] signe: [NOT] RelativeLocation:: RelativeLocation: width: IN rank:IN rank: IN width: Segment ( ?.__._ ha/...,B U,..... ______________________ _----_ G F i-----------' Figure 2.24: Les zones statiques dans Figure 2.25: Les zones dynamiques dans une BasicScene une BasicScene Les structures des StaBasArea et des DynBasArea sont très proches de celles des StaSynArea ou des DynSynArea des chronogrammes évolués. Leur champ pattern ne sera composé que de BasicLine. mais la structure et les propriétés du champ loca- tion restent les mêmes. En revanche, elles possèdent aussi le champ optionnel signe qui permettra ici de nier le comportement des signaux défini dans la StaBasArea ou la DynBasAreaentière. En fait si le champ signe est égal à NOT, l'ensemble des comportements des signaux vérifiant la multi-colonne, est l'ensemble des comporte- ments possibles des signaux à travers le temps moins ce qui validerait effectivement la multi-colonne sans le signe. 4. BasicLine:: pattern:BasicInter+ term: Terms signe: [NOT] La structure des BasicLine possède elle aussi le champ supplémentaire signe (tou- jours optionnel) permettant ici de nier une ligne, c'est à dire de prendre tous les comportements du signal Terms qui ne vérifient pas au moins un des BasicInter de la liste. l-- ---- pan __Têai__ i I_ _ I Figure 2.26: Les lignes dans les zones statiques ou dynamiques 5. BasicInter:: location: Segment statu: BEvent [ BStableVal signe [NOT] " "--"-- - Figure 2.27: Les intervalles dans les lignes d'un chronogrammne primitif La structure des BasicInter est proche de celle des Interval. Elle possède le champ location qui est calculé de la même façon. La séparation dans les classes BEvent et BStableValet le statut particulier IRRELEVANT reste la même. Le BaaicInter possède aussi le champ signe qui permet de nier un intervalle, c'est à dire de valider tous les comportements qui ne vérifient pas la contrainte définie par le status. Ce champ est très important car il permet d'augmenter le nombre de comportements exprimables dans un chronogramme. Par exemple, définir le statut décrivant l'existence d'au moins une transition revient à nier un intervalle STABLE, définir le statut décrivant l'existence d'au moins une transition de type front mon- tant, qui spécifie le changement de valeur du signal de Low à HIGH, revient à une double contrainte: la négation de la stabilité de l'intervalle plus la négation du statut FALLING, c'est à dire il existe une et une seule transition de HIGH à Low). Dans les définitions suivantes des différentes classes, nous remarquons que leurs structures sont quasi équivalentes à celles qui ont été données pour les chronogrammes évolués. Les champs definition, meaning et signe ont ici le même sens. Il faut bien remarquer que le champ signe est différent du champ signe d'un BasicInter car, par exemple dans le cas d'un intervalle stable, il correspond à valider tous les comportements stables possibles qui ne portent pas cette valeur, alors que nier un intervalle stable grâce au champ signe correspond à valider tous les com- portements qui ne vérifient pas la stabilité du signal à la valeur donnée dans le champ e=pression donc, par conséquent, tous les comportements possédant au moins une transition. 6. BStableVal:: definition:[BExpression] meaning:STABLE BExpression:: signe [COMPLEMENTARY] expression:(HIGH I Low) I Variable I -*r I Figure 2.28: La structure des statuts stables dans le langage primitif Ici nous donnons les différentes valeurs qui permettront de définir sémantiquement les chronogrammes. Les deux seules valeurs que nous avons retenues pour la descrip- tion de signaux booléens sont HIGH(true) et Low(false). La liste de ces valeurs peut être modifiée suivant le type d'utilisation que l'on veut en faire. Par exemple, pour le générateur de code vers VHDL il est très intéressant d'ajouter à cette liste les valeurs "Z" qui correspond à haute impédance dans le matériel, '1+" ou "0+" qui sont définies dans la standardisation de VHDL[IEE88]. 7. BEvent:: definition:[BLogical] meaning: EDGE BLogical:: signe:[COMPLEMENTARY] expression: FALLING | RISING Dans la classe des Event, la sémantique intuitive que l'on peut donner à ces différents événements: * Si le champ definition est vide, alors il existe une et une seule transition durant l'intervalle, cette transition peut être une transition descendante (changement de valeur de true à false) ou montante (changement de valeur de false à true). * Si le champ ezpression est égal à FALLING, alors il existe un et seul front descendant (changement de valeur de true à false), on ne dit rien sur le front montant. * Si le champ expression est égal à RISING, alors il existe un et seul front montant (changement de valeur de false à true), on ne dit rien sur le front descendant. Avec le type d'ezpression des BEvent le champ signe, n'est pas vraiment utile car complémenter le statut FALLING est équivalent au statut RISING, et inversement, mais il sera utile si l'on augmente le nombre de statuts de base. q > Figure 2.29: Les événements dans le langage primitif 2.3 Expansion du langage utilisateur vers le langage primitif Comme nous l'avons vu, le langage CHLOE est composé de deux sous langages: * le langage Primitive * le langage Evoluted Seul le langage Primitive est utilisé pour les compilateurs (SIGNAL et VHDL). En ef- fet, le langage Evoluted permet dans un environnement ergonomique de spécifier plusieurs propriétés dans un même chronogramme, mais ne possède pas plus de puissance sur l'expression de ces propriétés prises individuellement. Axiom 2.1 Toute propriété spécifiée dans le langage Evoluted doit se réécrire dans le langage Primitif. Nous allons commencer par donner l'exemple d'expansion des quatre propriétés qui appartiennent au chronogramnme évolué de l'exemple de l'automate des couleurs. Plusieurs étapes dans l'expansions sont possibles, cela dépend en fait des statuts BEvent et BStableVal qui appartiennent au langage primitif. Deux cas d'expansion sont possibles: * l'ensemble des statuts du langage primitif est égal à l'ensemble des statuts utilisés dans le langage évolué, ou * il existe un algorithme de réencodage des signaux et des statuts des intervalles du langage évolué dans le langage primitif. 2.3.1 Exemples d'expansion Nous allons maintenant utiliser l'exemple des propriétés définies dans la section 2.1 sur l'automate des couleurs. Pour plus de compréhension, nous allons donner l'expansion des propriétés 1), 2), 3) et ) dans un langage primitif possédant les mêmes statuts que ceux utilisés dans le langage évolué. La traduction dans un langage Primitive n'acceptant que les booléens demande un algorithme de réencodage des signaux et des statuts dans un système booléen. __F 2 L chronogam'e.éolué _ FTiI 2 le lu Figure 2. 30: Le chronogramme évolué __ __g -, Figure 2.31: La propriéte 1): Si on lit Figure 2.32: La propriété 2): Si on est BLEU et que l'on est JAUNE, alors on est BRUN, alors on le reste VERT au pas suivant Figure 2.33: La propriété 3): Si on lit ce Figure 2.34: La propriété 5): On écrit que l'on est, alors on le reste toujours la couleur que l'on a au pas Vsuivant 2. 3.2 L'algorithme d'expansion Voici la structure abstraite écrite en VDM des propriétés dans un chronogrammeevolué ainsi que les propriétés du langage primitif, nous allons nous baser sur ces structures pour décrire l'algorithme d'expansion: ____ BinaryPp: hypo: Hypothesis conc: Conclusion Hypothesis:: BasicBinarPp:: composition: [Operator] element: Block+ down BasicScene Conclusion = Block+ top BasicScene Operator = OR AND Block = Evoluted Evoluted:: properties: BinarylPp+ background: Scene Soit H, H2., H,H l'ensemble des blocks constituant l'hypothèse, et C1, C2,...., Ci l'ensemble des blocks constituant la conclusion, dans le cas général, nous aurions pu avoir quatre cas de compositions entre ces diffeérents blocks. * Hl AND H2 AND....AND H,, C1 AND C2AND....ANDCm, * Hl OR H2 OR....OR Ha, Ci AND C2 AND....AND Cm, * H1 AND H2 AND....AND Hn, Cl OR C2 OR.... OR C,,m * Hl OR H2 OR....OR H,) C1 OR C2 OR....OR Cm En fait dans le cas des chronogrammnes primitifs les deux derniers cas ne peuvent pas être pris en compte. En effet, il est difficile de réaliser le disjonction de conclusion pour des raisons essentiellement ergonomiques, aussi nous avons préférer ne pas le faire. Maintenant reprenons les deux premiers cas, on va essayer de simplifier ces cas pour se ramener à un cas de base. Ici représente l'implication temporelle entre l'hypothèse et la conclusion. Cet opérateur bien que différent sémantiquement à l'opérateur " =" de la logique booléenne, en possède néanmoins les mêmes propriétés de distributivité avec les opérateurs AND et OR. En effet, on a bien: * Hi AND H2 AND....AND Hn, C1 AND C2AND....ANDCm 4- - (Hi AND H2AND....AND H,, CI) A (H AND H2 AND....AND H, - C2) A....A (Hi AND H2 AND....AND Hn, Cm) * H10R H2OR....OR Hn, C1AND C2AND....AND Cm - - (H1 C1 AND C2 AND....AND Cm,) A (H2 Ci AND C2 AND....AND Cm) A.... A (H,1 Cl AND C2 AND....AND C,) et en appliquant la règle définie ci- dessus on a alors: Hi OR H2 OR....OR Hn, Ci AND C2AND....AND Cm: - (H Cl) A (H1 i C2) A....A (Hi C,) A (H2 C1) A (H2 C2) A...A(2)A.... (H) A.... (n., CI) A (Hn, C2) A.... A (Hn. Cm) On peut donc se ramener à un seul cas o il existe un ou plusieurs blocks dans l'hypothèse reliés par l'opérateur AND, et un seul dans la conclusion. Après cette première transformation, et à partir des structures abstraites définies précédemment, l'algorithme d'expansion d'une BinaryPp du langage évolué dans une Ba- sicBinaryPp du langage primitif peut être décomposé en six points: 1.1 Renumérotation des différentes zones 1.2 Renumérotation des bornes des intervalles. 1.3 Création de la BasicScene top du chronogrammeprimitif. 1.4 Création de la BasicScene dowun du chronogrammeprimitif. 1.5 Remplissage des parties non définies. Si besoin 1.6 Réencodage des différents signaux et différents statuts pour des signaux booléens. Nous allons développer un peu plus les différentes étapes de l'algorithme. Les deux étapes 1.1 et 1.2 sont très importantes. Elles permettent de resynchroniser les BinaryPp non pas au début de la Scene du chronogrammeévolué de départ, mais sur le début de BinaryPp. 1. Renumérotation des multi-colonnes: * Calcul du minimum du champs rank de toutes les multi-colonnes appartenant au différents blocks de l'Hypothesis et de la Conclusion de la BinaryPp. Soit Min(rank) ce nombre. * Changement du champs rank de toutes les multi-colonnes. Min(rank) va nous servir dans cette opération, on va alors "oublier toutes les zones précédant le début de la propriété. On aura alors pour toutes les multicolonnes appartenant au différents blocks de l'Hypothesis et de la Conclusion rank:= rank - Min(rank) 2. Renumérotation des bornes des intervalles: * Regroupement de tout les intervalles appartenant auxmulti-colonnes de l'Hypotheais ou de la Conclusion dont le nouveau rank est égale à O. * Calcul du minimum du champs lowerbound et upperbounddu champs location des intervalles appartenant à l'ensemble défini ci-dessus (Min(looerbound)). * Changement du champs lowerbound du champs location de tous les intervalles appartenant à cette ensemble en posant lowerbound:= lowerbound - Min(lowerbound) upperbound:= upperbound - Min(lowerbound) * Changement du champs uwidth du champs Relativelocation de toutes les multi- colonnes de l'Hypothesis et de la Conclusion dont le nouveau rank est égale à O en posant uidth:= width - Min(loImerbound) Dans le cas d'une multi-colonne dynamique, on soustraira le Min(lotowerbound) aux deux bornes du segment définissant idth. Si la borne inférieure de ce nouveau segment est négative, elle sera remplacée par "O". * Calcul du rang maximum des nouvelle multi-colonnes Max(rank), puis calcul du Max(upperbound) qui est maximum des bornes supérieures des intervalles appartenant aux multi-colonnes de l'Hypothesis et de la Conclusion dont le nouveau rank est égale à Max(rank). Changement du champs width du champs Relativelocation de ces multi-colonnes, en posant: wuidth:= width- Max(upperbound) Dans le cas d'une multi-colonne dynamique, on soustraira le calcul est plus difficile. Il faut en premier lieu calculer le nombre de colonnes de la zone Nbcol (Nbcol est égale au maximun de toutes les bornes des intervalles). On soustraira alors "Nbcol - Max(upperbound)" aux deux bornes du segment définissant width. Si la borne supérieure de ce segment est égale à INFINTE, elle ne sera pas modifiée. 3. Création d'une BasicScene à partir d'une liste de Block * Création de l'horloge Clock en prenant le nom de l'horloge d'un des Block. * Création de l'ensemble des Term représentant l'ensemble des signaux utilisés dans BasicScene en faisant l'union des ensembles de Term du champs back- ground de chaque Block. * Création de la liste des multi-colonnes à partir de l'ensemble des multi-colonnes appartenant à l'ensemble des Block. - Regroupement dans des ensembles séparés des multi-colonnes ayant le même champs location. - Pour chaque ensemble résultant, création d'une nouvelle multi-colonne dans la BasicScene o le champs pattern est égale à l'union des différents pattern représentant la liste des Line des différentes multi- colonnes, et o le champs location est égale à l'un des champs location. Pour les multi-colonnes de la Scene de départ qui ne sont jamais référencées dans l'ensemble des Block, insertion d'une multi-colonne dans la BasicScene o le champs pattern est vide, et o le champs location est égale à l'un des champs location de la multi-colonne de la Scene de départ. * Remplissage des parties non définies. Dans les étapes précédentes, nous avons créé un préfixe d'arbre du chronogramme. Toutes les informations importantes y sont. Mais ce préfixe ne peut être validé que si toutes les lignes sont pleines. On va alors parcourir l'ensemble des listes d'intervalles de cette nouvelle pro- priété. Soit Ii, le ième intervalle de la liste. Nous poserons I.location.upperbound (I.location. looerbound) la valeur du champs upperbound (resp lowerbound) du champs location de l'intervalle I. Si Ii.location.upperbound#-Ii+.location. lowerbound alors on va insérer dans la liste des intervalles d'un nouvel intervalle I, tel que - I. location.lowerbound=-I.location.upperbound - I. location.upperbound--=Ii.location.lowerbound - I.status=-- IRRELEVANT Si Ii est le dernier intervalle de la liste on aura - I.location upperbound = width Chapitre 3 Les sémantiques des chronogrammes 3.1 Les différents sens des chronogrammes Nous allons ici donner brièvement une idée sur les différents sens possibles des chronogrammes de CHLOE. Nous nous appuierons pour cela sur les utilisations poten- tielles de CHLOE dans le domaine de la validation de circuits qui sont la spécification et la vérification de modèle. hronogra1. I I i _ COU pourdscr rajoutant une une le n ouvelle a c ontrainter CettFige eontraintes crites sous forme chronograme peut alors permettre Pour définir une spécification à l'aide de chronogrammnes, on les assimile à des con- traintes sur le modèle. On raffinera ensuite la spécification du modèle ainsi définie en rajoutant une à une les nouvelles contraintes Cette liste de contraintes écrites sous forme de chronogrammnes peut alors permettre de spécifier entièrement un modèle ou de rajouter à une spécification partielle de nouvelles contraintes qui seront dans certains cas redondantes. Cette méthode de spécification sera utilisée pour des petits systèmes de contrôle, ainsi que pour les ASICs o la liste exhaustive des contraintes est encore imaginable, mais ses limites sont atteintes lorsque l'on veut spécifier exhaustivement de gros systèmes uniquement par chronogrammes. En effet, pour des protocoles ou des circuits importants, il semble très difficile de donner l'ensemble des propriétés comportementales par chronogrammes à cause de la multiplication des cas particuliers. Pour l'utilisation des chronogrammes dans ce sens là, il est nécessaire d'avoir des lan- gages et des compilateurs très puissants qui permettent ce type de programmation, et les vérifications de cohérences associées. Le langage SIGNAL et l'ensemble des outils s'y ratachant ont permis d'utiliser les chronogrammes pour la spécification par contraintes. Mais l'utilisation principale des chronogrammes reste la vérification de modèles. Cette fois on suppose donnée une spécification, on doit alors vérifier qu'elle réalise bien les propriétés représentées par les chronogrammes. Il n'est donc plus nécessaire de connaître l'ensemble des propriétés comportementales du système mais seulement les principales. Les chronograrnmes vont alors se comporter comme des analyseurs des traces du système. C'est le choix qui a été pris dans le cadre de la génération de code vers SVHDL. Ce langage nous permettra de nous connecter soit aux outils de simulation soit pour une exhaustivité des cas aux outils de preuves conçu à cet effet [CLS92]. Dans le cas de la preuve, d'autres outils peuvent être utilisés comme les Model Checkers basés sur la logique temporelle CTL ou les compilateurs SIGNAL. Ces deux utilisations des chronogrammres vont être formellement définies dans la suite du chapitre. Pour cela, nous avons étudié les chronogrammes existants mais dans lesquels la sémantique était souvent ambigie et intuitive. Nous en avons extrait un sous-ensemble, le plus complet possible, puis nous avons formalisé tous les aspects de ce sous ensemble. Dans le chapitre 2, nous avons défini la syntaxe des chronogrammes, nous allons main- tenant en présenter la sémantique afin de les définir entièrement et de les classer. Dans ce chapitre, nous allons utiliser deux modèles pour la définition sémantique des chronogramrnmes. Chaque modèle est écrit dans une théorie choisie pour sa puis- sance d'expression et dans le but de baser formellement les outils qui gravitent autour de l'éditeur de chronogrammes, tel les générateurs de code. Mais pour l'instant, la preuve de cohérence entre ces deux modèles n'a pas encore été réalisée. Dans un premier temps, nous développerons la sémantique d'un chronogramme, en terme d'intension. En fait, cette sémantique nous a permis de définir formellement tous les types de chronogrammnes possibles de CHLOE, elle est aussi adaptée pour servir de base à une extension très intéressante des chronogrammes, c'est-à-dire les chronogrammes multi-horloges qui sont des chronogrammes avec plusieurs horloges cadençant l'arrivée des événements sur les signaux. Elle servira aussi de base dans la génération de code vers le langage flot de données SIGNAL car les intensions ont été utilisées dans la définition de la sémantique de ce langage. Dans un deuxième temps, nous donnerons la sémantique en terme d'expressions ra- tionnelles. Cela nous permettra de trouver la place du langage CHLOE dans la hiérarchie des langages rationnels. Cette définition, même si elle est pour l'instant incomplète car nous n'avons pas encore spécifié l'ordre des événements sur deux lignes différentes, per- met d'avoir un résultat très intéressant sur le langage défini par un chronogramme. En effet, les circuits spécifiés à l'aide de chronogrammes peuvent être représentés par des langages infinitaires rationnels sans étoile de niveau de concaténation 3. nl s'agit là d'une sous-classe relativement restreinte de langages rationnels de mots infinis. Ceci permettra d'établir des résultats théoriques sur la complexité des automates générés par les compila- teurs. Déjà, le fait que le langage soit rationnel prouve que les automates sont à mémoires bornées. 3.2 La définition indexicale des chronogrammes Cette sémantique a largement inspiré la génération de code SIGNAL et devrait permettre de la fonder. 3.2.1 Introduction sur les notations Soit Z l'ensemble des entiers relatifs. Soit V l'ensemble des datations, c'est à dire l'ensemble des fonctions monotones et croissantes de IN dans IN. Pour B un sous-ensemble de IN. Nous noterons V(B) l'ensemble des datations des éléments de B dans IN. En d'autres termes, D(B) est une datation partielle de IN, seulement définie sur B. Dans certains cas, les chronogrammes contiennent plusieurs horloges. Dans un premier temps, nous ne considérerons que les chronogrammes avec une seule horloge qui sera notée par CLOCK et isomorphe, à EZ. Ici Z est le modèle de numérotation par ordre chronologique des cycles de l'horloge réelle. Par abus de langage, nous appellerons souvent cycle ou période les éléments de CLOCK. Afin de définir les chronogrammnes, nous avons besoin d'une fonction F, que l'on appellera la fonction sémantique dont la signature est 'S: S - S >, : CLOCK, ú Pour définir F nous allons dans un premier temps définir chacun des symboles utilisés pour définir sa signature en particulier ú et I . L'espace syntaxique noté S a été défini dans la section précédente, c'est en fait l'ensemble des sous-arbres ou des préfixes de sous-arbres de tous les chronogrammes pos- sibles. L'espace sémantique, noté S, est composé d'un ensemble d'applications de CLOCK, dans un ensemble ú, appelé l'ensemble des extensions associées. Ces éléments de S, notés par , sont appelés, pour des raisons historiques, des intensions. I (t), l'extension associée à à la période d'horloge t, est l'ensemble de toutes les observations que l'on peut faire sur une période d'horloge t (une observation étant également un ensemble). En fait, dans la section suivante nous allons définir cette fonction pour tous les sous-arbres de l'un des types suivant: term BasicInter BasicLine StaBasArea DynBasArea BasicScene Primitive Pour un sous-arbre appartenant à l'un quelconque de ces types nous allons définir un ensemble ú d'observations possibles. En revanche, pour tout élément de S n'étant pas d'un de ces types la règle suivante s'applique: (VI)(Vt)((I≤> E S A t E cLOCK) I (t) =0) Tout d'abord, nous allons définir l'ensemble ú pour les signaux c'est-à-dire pour l'ensemble des noeuds de type tera Le concept de base de notre approche formelle est l'observation. Soit x un signal, nous appellerons (x,ie,t) que nous noterons aussi xt la t-ième occurrence du signal x; ie est la valeur portée par le signal x pendant la t-ième période de l'horloge. x est l'identificateur du signal lui même, x E S. Dans le cas du langage primitif de chronogrammes, les termes représentent des signaux booléens. On aura donc: Ex = {s, E B} Dans le cas des BasicInter et des BasicLine une observation instantanée ne suffit plus. Il faut pouvoir observer le signal concerné sur un nombre quelconque de cycles. Soit to le cycle courant, l'ensemble CI peut être défini de la façon suivante. Soit I de type BasicInter ú= U U {Xe, t E I}} EN,toE e-Z t=o--n o x est associé à la ligne à laquelle l'intervalle I appartient. to est la période de fin d'observation de l'intervalle, elle appartient à 72 car les chronogrammes n'ont pas d'instant initial. n correspond ici à la largeur de cet intervalle, elle peut prendre n'importe quelle valeur dans IN, à cause des DynBasArea. La réunion de tous ces ensembles englobe l'ensemble des observations possibles pour les lignes qui sont des suite d'intervalles. Soit Ligne de type BasicLine úLigne = úI Pour plus de lisibilité, nous noterons to U {x,, it E]BI = x'to t=to -n Nous allons maintenant définir ú pour les objets de type StaBaskrea ou DynBasArea. * Ici non seulement il faut pouvoir observer sur un nombre quelconque de cycles, mais il faut pouvoir observer plusieurs signaux simultanément. Tous les signaux considérés sont observés sur le même nombre de cycles. Soit zone une StaBasArea ou une DynBasArea, soit TERM l'ensemble des signaux observés dans cette zone. Cet ensemble est calculable grâce aux informations contenues dans les différentes lignes de la zone. On aura alors: Leon. = U { U} EiNAoE2Z xETERM Soit zone une zone appartenant à la BasicScene scene, l'ensemble des signaux observés étant le même dans les deux cas, on a alors: acen,. = EúZ=o L'ensemble des observations possibles úFeii pour les noeuds Primitive sera égale à l'ensemble des observations possibles sur tous les signaux du chronogramme. On a donc défini pour chaque expression , l'ensemble ú correspondant qui est dépendant de son type. L'ensemble ú sera alors la réunion de tous ces ensembles: ú = U ú ES Nous pouvons donc maintenant considérer I l'ensemble des applications notées I de Clock dans E o E est parfaitement défini. Nous aurons besoin dans la suite d'un opérateur de compositions d'intensions que nous noterons l. La définition formelle de cet opérateur [ comporte trois cas de figure. Soient et deux objets syntaxiques appartenant à S et qui ont une image par F. Soient 1 = F( ) et I = F( ), alors Vt Si Z (t) 0 alors (z I I )(t) = I (t) Si I (t) = 0 alors II^^^^^ I t Enfin si (t) # 0 A I (Ot) # 0 alors (I > (t) A t E I (t)A (Vxt)(Vy,)(x E ai A y E Pt A x = y =É e = yg)} Les noeuds tern, BasicInter, BasicLine, StaBasarea, DynBasArea sont du type liste. C'est à dire que l'on peut les munir d'un opérateur de concaténation. Notons le e. L'application F est un morphisme de (S,e) dans (S, 1). Pour tout objet syntaxique et l'équation suivante est vraie: :( À ) = F( ) I F( ) L'opérateur I est également la définition sémantique de la composition de processus en SIGNAL [LB86]. 3.2.2 La fonction sémantique L'intension d'un signal La définition de F sur l'ensemble des term, (Vx)(x E tre.=: 32zx,.F(x) = Ix) avec (Vt)(t E cLoCK * Ix(t) = {{:xe},ie E IB}) Ceci est exactement la définition sémantique d'un signal en SIGNAL. Ainsi, ce que nous voyons en observant un signal, c'est une succession de booléens portés par ce signal, dont l'ensemble d'index est CLOCK. Cette séquence de booléens associée à un signal est appelée une trajectoire. Nous pouvons considérer Ax comme l'ensemble de toutes les trajectoires qui sont générées par le signal z: Ax = {(6t, t E cLOcK), (Vt)(t E CLOCK * ft e Ix(t))} Les intervalles Un intervalle I de type BasicInter, définit une fenêtre finie et le type de comportement que l'on observe dans cette fenêtre. La fenêtre est définie par les entiers BI et BS appartenant à l'arbre syntaxique et étant respectivement les valeurs des bornes inférieure et supérieure de l'intervalle. Les entiers BI et BS donnent alors respectivement la position de la borne inférieure et supérieure de la fenêtre relativement à sa position dans la ligne qui le contient et sont calculés grâce à l'arbre syntaxique. Soit Ligne la ligne de type BasicLine à laquelle I appartient. A chaque Ligne est associée une datation dont la définition sera précisée plus loin et que nous noterons Ligne Et pour tout t, définissant une période d'horloge quelconque, [t - (bLigne(BS) - Ligne. (BI)), t] est le segment fermé de l'axe du temps CLOCK, que l'on observe à travers la fenêtre définie par l'intervalle. En fait, un intervalle ne définit pas nécessairement des segments fermés. Le statut ouvert/fermé des segments défini par un intervalle dépend de S. BS et SBI deux paramètres de l'arbre syntaxique. On a donc I un intervalle de la ligne Ligne. Notons par Segj (t) le segment défini par I, à la période d'horloge t. Segi(t) peut être égal à un des segments suivants, selon le statut ouvert/fermé de I: [t (iLigne(BS) - Ligne(BI)), t] It - (Ligne.(BS) - Lign(BI)), t] t (IOLign.(Bs) - ikLigne(BI)), t[ It - (Ligne(BS) - I.Lign,(BI)), t[ Notons par S.BI SBS | et I les bornes inférieure et supérieure de SegI telles qu'elles sont définies par SBI et SBS, i.e., [ ou]. On posera alors S.BI SBS Sega(t)= I t-(eLigne(BS)-Ligne(BI)),t I La fonction SegI permet ainsi de définir le nombre de cycles d'horloge sur lesquels portera la contrainte au cycle t. Les observations possibles associées à I au cycle t appar- tiendront donc au sous-ensemble suivant de úI: { U {.,ïi E I}} iESegi(e) avec xi = (x, ij, i), qui correspond à l'observation au cycle i de la valeur s., portée par le signal x. La fonction SegI est une définition sémantique correcte de l'opérateur WINDOW de SIGNAL dans le cas o 4'Ligne est l'identité de 1N à IN. La sémantique de la fenêtre d'un intervalle étant définie, regardons la définition complète d'un intervalle dont le champ statua est égale à HIGH et qui est donc de la classe des BStableVal. Ces intervalles définissent une fenêtre dans laquelle le signal associé porte toujours la valeur 1. Ainsi Ix est un intervalle HIGH sur la ligne du signal m. Il définit une intension IIx image de x par la fonction sémantique F,comme suit (Vt)(t E CLOCK É ZIî(t) = {{Xi, i E Seg11(t)}, (Vi)(i E Segîx(t) * xi E Ix(i)Aii = 1)}) L'ensemble des trajectoires associées à Ix est ai', = {(5,, t E CLOCK), (Vt)(t E CLOCK E Zix(t))} Dans le cas général, le statut d'un intervalle nous fournit des informations qui sont inter- prétées comme un filtre de trajectoire. L'ensemble des trajectoires associées à un intervalle est inclus dans celui engendré par l'intervalle défini sur la même fenêtre mais ne possédant aucune contrainte sur les valeurs. Comme nous l'avons vu dans la section 2.2.2, il y a deux sortes de statuts: Les statuts BStableVal pour l'observation de signaux stables. En premier lieu, ils dis- ent que le signal à une valeur stable, et en second lieu, si cette valeur est égale à 1 ou à O. Un identificateur peut être associé à la valeur portée par un signal. Cet identificateur a une portée globale. Une utilisation répétée d'un même identificateur dans un chronogramme veut dire que le signal porte la même valeur dans les fenêtres respectives. Voici la liste des statuts stables (BStableVal) dans le langage primitif des chronogrammes: HIGH, LOW, STABLE, VALSYMB. Ils signifient respectivement: * le signal reste à la valeur 1 dans la fenêtre (HIGH), * le signal reste à la valeur O dans la fenêtre (Low), * le signal est stable dans la fenêtre, mais sa valeur est inconnue (STABLE), * le signal est stable dans la fenêtre, et sa valeur est définie à travers un symbole ou une expression (VALSYMB), Les statuts BEvent pour l'observation des événements sur les signaux. Ils donnent des contraintes sur le nombre de fronts à observer et sur leur type (front montant ou descendant). Voici la liste des statuts BEvent disponibles dans le langage primitif des chronogrammrnes: RISING, FALLING, EDGE. Ils signifient respectivement * le signal doit monter une et une seule fois dans la fenêtre (RISING), il n'y aucune contrainte sur le nombre de fronts descendants, * le signal doit descendre une et une seule fois dans la fenêtre (FALLING), il n'y aucune contrainte sur le nombre de fronts montants, * le signal doit soit monter soit descendre une et une seule fois dans la fenêtre (EDGE). Il peut être intéressant de permettre aux utilisateurs de chronogrammes de définir les statuts BEvent en utilisant des identificateurs ou même des expressions sur une logique d'événements, mais ce n'est pas fait pour l'instant. Définissons la fonction F sur l'ensemble des noeud de type BasicInter. Ci-dessous, nous proposons un schéma permettant de construire la définition complète de l'ensemble des chronogrammes. Ces formules sont ouvertes au niveau des périodes d'horloges notées t. Soit t E CLOCK: IIx(t) = {{(xi,i),i E Seg1x(t)},(Vi)(i E Segj(t) *= xi E Ix(i)) A Fil(Ix))} Si le champ signe de l'intervalle est égal à NOT alors II.(t) = {{(xi, i), i E SegISx(t)}, (Vi)(i E SegIx(t) *= x E Ix(i)) A NOTFil(Ix))} Dans la suite, Sta est une fonction permettant pour un intervalle donné I de connaître son statut grâce à son champs statua. Le statut de Ix définit Fil(Ix), le filtre associé à l'intervalle. Comme nous l'avons montré ci-dessus, un intervalle dont le statut est HIGH signifie que le signal concerné doit porter la valeur 1 dans le segment observé par la fenêtre. Sta(Ix) = HIGH =: Fi/(Ix) = (Vi)(i E Segj.(t) * si = 1) Un intervalle dont le statut est Low signifie que le signal concerné doit porter la valeur O dans le segment observé par la fenêtre. Sta(Ix) = Low * Fil(Ix) = (Vi)(i E Seg11(t) * si = O) Un intervalle dont le statut est STABLE signifie que le signal concerné doit porter une seule valeur dans le segment observé par la fenêtre. Sta(Ix) = STABLE *: Fil(Ix) = (3c)(c E IB A (Vi)(i E Seg1x(t) =* ii = c)) Un intervalle dont le statut est VAL.SYMB signifie que le signal concerné doit porter la valeur identifiée par VAL dans le segment observé par la fenêtre. L'identificateur VAL est fourni par l'arbre syntaxique. Sta(Ix) = VALSYMB:: Fil(iY) = (Vi)(i E Seg1x(t) * ii = Val) Un intervalle dont le statut est FALLING signifie que le signal concerné doit avoir un et un seul front descendant dans le segment observé par la fenêtre. Notons que rien n'est dit sur les fronts montants. Il peut y en avoir. Sta(Ix) = FALLING: Fil(Ix) = (3!j)(j,j + 1 E Segix(t) A ij = 1 A ii+1 = O) Un intervalle dont le statut est RISING signifie que le signal concerné doit avoir un et un seul front montant dans le segment observé par la fenêtre. Notons que rien n'est dit sur les fronts descendants. Il peut y en avoir. Sta(Ix) = RISING =: Fil(Ix) = (3!j)(j,j + 1 E Segix(t) A ij = O A ij+l = 1) Un intervalle dont le statut est EDGE signifie que le signal concerné doit avoir un et un seul front dans le segment observé par la fenêtre. Sta(Ix) = EDGE = Fil(Iz) = (3c)(c E IBA(3!j)(j,j+ 1 E SegIx(t) Aii = cA i+1 = -c)) Ces contraintes sur valeurs peuvent se traduire par des contraintes sur des horloges en SIGNAL, horloges définies comme caractéristiques des ensembles de cycles o les con- traintes sur valeurs sont vérifiées. L'ensemble des trajectoires associé à Ix est AI. = {(5t, t E CLOCK), (Vt)(t E CLOCK =, E z.(t))} Les lignes L'intension qui est définie par un chronogrammne est construite par une composition hiérar- chique des intensions définies par les éléments syntaxiques du chronogramme. Dans la partie précédente, nous avons proposé un schéma afin d'écrire l'intension définie par les intervalles sur un signal quelconque x. Cela va maintenant nous permettre de décrire l'intension définie par une liste d'intervalles sur un signal donné qui correspond au noeud de type BasicLine dans la grammaire du langage primitif de CHLOE. Nous considérons une liste d'intervalles comme la concaténation d'intervalles de la liste portant sur le même signal ident. Soit Ligne une ligne portant sur le signal ident connu grâce à l'arbre syntaxique et dont la liste d'intervalles est composée des intervalles Il,', I. Nous écrirons: Ligne = Ii^.a - - Id n - * Igidet = Puis par application de l'opérateur de composition d'intension noté I, on a: 1Ligne =I n i=1 n = I li, i- i Nous allons introduire les datations correspondant à chaque ligne. Pour la ligne Ligne, on a donc une datation, notée par Ligne tel que ?kLigne: BLigne CLOCK n Fe iLigre(n) o BLigne est l'ensemble des bornes inférieures et supérieures de tous les intervalles qui composent la ligne Ligne et dont le statut est différent de IRRELEVANT. Cet ensemble est facilement calculable en parcourant la liste des intervalles de chaque ligne, il est indis- pensable pour la définition des chronogrammes de ne pas prendre en compte les intervalles dont le statut est IRRELEVANT pour la définition formelle des propriétés de vivacité. La seule contrainte que l'on peut exprimer pour l'instant sur lbLigne, c'est qu'elle est croissante: c'est bien une datation. Cela ne veut pas dire que toutes les applications croissantes sont bonnes. Nous verrons dans la définition des zones que d'autres contraintes viennent s'ajouter lors de la composition des datations des différentes lignes et suivant le type de zone englobante. Les zones statiques StaBasArea et dynamiques DynBasirea Nous considérons une zone statique ou dynamique que nous noterons Zonek k correspond au rang de la zone dans la liste des zones de la scène. La zone Zonek est une composition de t lignes. Zonek - À Lignei i= i Notons que plusieurs listes d'intervalles peuvent être associées au même identificateur de signal. L'intension de la zone Zonek est définie par IzOnek = ILig.i i-1 Nous allons donc définir les datations des zones en fonction de celles des lignes. Plusieurs types de définitions de datations peuvent être considérés. Le sens des chronogrammes dépendra du choix de cette définition. Un type de zone correspondra alors à chaque choix. C'est au niveau des zones que l'on peut définir les contraintes supplémentaires indispensables dans la définition des datations des différentes lignes. (Vi,j) (O de l'ensemble des intervalles d'une DynBaArea. Dans le cas des zones StaBasarea, nbool& est égal au champ width de la zone. La datation associée est la fonction identité: (Vn E BZonek U {nbolà}, bZonek(n) = n) On peut alors en déduire une contrainte supplémentaire sur chaque iLigne appar- tenant à une zone statique. On a donc (Vi, O o Id et la fonction identité de IN dans IN. Dans le cas des zones DynBasArea, le champ uidth est un segment dans IN. Les data- tions définies par ce type de zones ont une expression inconnue. Cela ne veut pas dire que toute datation est bonne car il existe d'autres contraintes dans sa con- struction. Ces contraintes seront définies aux niveau de la définition globale d'un chronogramme. Mais on peut déjà dire que 4Zonelk est globalement croissante et que soient BI"t et BS,, les valeurs des bornesde ce segment widthet S$BI et S$BS leur statut respectif (toutes ces informations appartiennent à l'arbre syntaxique) on a alors: (Vm,n)(m,n E Bzonek U {nbcol} A m J étant définit de la même façon que dans la définition des intervalles. Comme la datation associée à chaque ligne est croissante, il y a donc un ordre entre les bornes des intervalles d'une même ligne, avec cette contrainte supplémentaire on spécifie un ordre entre les bornes des différentes lignes composants la zone. Cet ordre correspond à l'ordre visuel de gauche à droite qui vient naturellement dans la lecture des chronogrammes. Dans ce type de zone, nbcolà est égale à la plus grande borne de tous les intervalles. Remarque: Dans le cas des zones dynamiques, si l'on n'impose pas à 3&Zonk d'être croissante, on est ici dans une autre classe de zones qui correspond au cas particulier des chronogrammes de protocoles o justement il n'y a pas de synchronisation entre les lignes. Dans ce cas, kZonek n'est plus une datation. Les scènes Les scènes BasicScene sont composées d'une liste de zones qui sont soit statiques, soit dynamiques. Soit nbmcol le nombre de ces zones dans une scène. C'est un élément de l'arbre syntaxique, mais qui ne fait pas partie des objets concrets: nbacol Scene = * Zonek k= i On a donc n :Scene = l:ZOnek k=1 Nous allons maintenant utiliser les datations associées à chaque zone de la scène pour définir la datation associée à la scène entière. Soit nbcoli le nombre de colonnes dans la i-ième zone. Cet objet appartient à S dans le cas des StaBasirea ou est facilement calculable à partir de l'ensemble de intervalles d'une DynBasArea. Nous allons définir Bscone représentant l'ensemble des bornes d'une scène par nbmcol l-i BScene = U {(Z nbcoli) + n, n E BZonk} k=1 i=l Ici chaque borne est calculée, non pas par rapport au commencement de la zone qui contient l'intervalle, mais par rapport au commencement de la scène. On ajoute alors à chaque borne le nombre de colonnes déjà écoulées depuis le commencement de la scène. Ce nombre n'est pas nécessairement le nombre de cycle d'horloge écoulées si certaines zones sont des DynBasArea. Alors la définition de la datation associée à une scène est kScene: BScene -. Clock Vt E Bscene, 3!kO respectivement les kièmes zones de l'hypothèse et de la conclusion. Nous noterons nbacolHypo HYPO = À! YPOk k=1 l'hypothèse du PB, o nbmcolHypo est le nombre de zones de la scène RYPOANDpar nbmcolcoIc CONC = 1 CONC, la conclusion du PB o nbmcolcONC est le nombre de zones de la scène CONC. Il existe plusieurs contraintes syntaxiques qui relient ces deux objets. Elles en- traîneront des contraintes supplémentaires sur la définition des datations de chaque zone: e nbmcolHypO = nbmcolCONC = nbmcol Vk, O HYP0k et CONCk sont de même type (StaBasArea ou DynBasirea). widthypok = widthcoNc, À partir de cette définition, on peut maintenant définir les contraintes supplémentaires sur les différentes datations engendrées par l'ensemble des zones de l'hypothèse et de la conclusion. Soit BKypo, l'ensemble des bornes de tous les intervalles composant la zone HYPOt, BCONC. l'ensemble des bornes de tous les intervalles composant la zone CONCj: (Vn)((n E BHYPO, n BcoNC) => (Hypo,,(n) =,kcoxc,(n))) Cette contrainte, si elle est évidente dans le cas o HYPOk et CONCi sont des zones statiques (bZonek est égale à l'identité), est une contrainte de synchronisation im- portante entre les zones dynamiques de l'hypothèse et de la conclusion. En fait, deux événements alignés verticalement dans un chronogramme arrivent toujours au même instant. (VB1), (VB2), B1, B2 E Baypo, U BCOxc,) A B1 chronogrammne, alors c'est qu'il le suit. Apres avoir défini les contraintes supplémentaires sur les datations des zones Zonek, nous avons tous les éléments pour donner la définition de IPB qui utilise les différentes notations définies précédemment: Voici donc la définition de 1PB qui utilise les différentes notations définies précédemment: Soit Biypo et BCONC respectivement les bornes des scènes HYPO etCONC: t E Clock (Vt)(V-'pno)(30CONC)(,'axpo e V(Bypo) t 3coNC E V(BCOC) (3.1 IpB(t) = {'t, (Vat 6 CHPO)(Vpt 6 úCONC)((7t = at U p, A at E IWPO(t)) t (Pe E ICONC(t)))}) Alors, (VPB)(PB E Primitive =* (pB)(F(PB) = IPB)) O IPB est définie dans la formule 3.1. Cette ensemble correspond à l'ensemble des observations acceptées par le chronogramme parmi toutes les observations possibles. L'ensemble des trajectoires associée à Ix est APB = {(6t, t E Clock), (Vt)(t E Clock:= et E IPB} 3.3 La sémantique dans les langages rationnels Nous allons dans cette section définir le langage rationnel engendré par un chronogramme primitif. Ce résultat ainsi que la classification des chronogrammes dans la hiérarchie des langages rationnels est développé dans le rapport [ALP92]. 3.3.1 Introduction sur les notations Dans l'annexe C, nous rappelons sommairement les définitions et résultats de théorie des langages dont nous aurons besoin dans la définition des chronogrammes. Ces rappels sont destinés à fixer les notations employées mais ne sauraient se substituer à un ouvrage traitant de ces questions. Le lecteur désirant des compléments d'information pourra consulter les livres [Eil74, Per84]. Nous attirerons plus particulièrement votre attention sur une notation un peu partic- ulière qui pourraient dans certains cas être mal interprétée. Comme pour les mots, on peut définir les puissances d'un langage en posant L0 = {e}, Lé = L, L = LL, et par récurrence, Ln = L"-'L L'étoile d'un langage L, notée Lé, est l'union de toutes les puissances finies de L: L U L. >0 Cette notation très utile dans le monde des langages rationnels rentre en conflit avec la notation très répandu du produit cartésien. Dans le reste de la section, pour un ensemble A donné: A Ax A x--xA sera noté Ai An est alors l'ensemble des mots de longueur n dont chaque lettre est un vecteur à k composantes, chacune de ces composantes appartenant à A. Pour permettre une lecture plus facile, nous utiliserons aussi beaucoup la notation suivante: L[ml = U L' n de ses signaux. Ici nous considérerons donc des mots infinis à droite seulement, c'est- à-dire que l'on suppose dès maintenant l'existence d'un état initial. Contrairement à la semantique indexicale ou les signaux sont bi-infinis, on va ici restreindre la semantique des chronogrammes. Cette généralisation reste donc à faire. Nous nous baserons pour la définition sémantique du langage sur la syntaxe abstraite définie dans le chapitre précédent. Variables booléennes et valuations Une des particularités du langage CHLOE est l'utilisation de valeurs symboliques qui, dans le cas présent, sont des variables booléennes. Par analogie avec le calcul booléen, si v désigne une variable booléenne, i désignera la variable booléenne complémentaire de v et définie par 1 siV=0 0O sinon L'utilisation des variables booléennes permet au langage CHLOE d'exprimer des pro- priétés du type "le signal prend la valeur v au cycle t et la valeur v au cycle t + 3". Pour prendre en compte l'utilisation de ces variables, il est commode, dans un premier temps, de représenter un signal non pas comme un mot infini sur l'alphabet B, mais comme un mot infini sur l'alphabet étendu C=BuVuV' o V est l'ensemble des variables utilisées dans la description de la propriété et est facile- ment calculable grâce à l'arbre syntaxique. Pour revenir à l'alphabet B, il suffit de donner une valeur à une variable. Ceci est réalisé formellement par une valuation, c'est à dire une application v: C -* B telle que (a) pour tout b E B, v(b) = b (b) pour tout v E V, v() = v(v). Ainsi, sur l'exemple précédent la propriété peut se développer en: 'le signal prend la valeur O au cycle t et la valeur 1 au cycle t + 3" (ce qui correspond à prendre la valuation v définie par v(v) = O) ou "le signal prend la valeur 1 au temps t et la valeur O au temps t + 3" (ce qui correspond à prendre la valuation v définie par v(v) = 1). Une valuation v: C -+ B définit de façon naturelle un morphisme v: C -B*, en posant, pour tout mot clc2... c,, E C V(cIC2.c,) = V(CI)V(C2). V(Cn) Si L est un langage de C', le langage v(L) est appelé la valuation de L. Cette valuation v: C -- B définit de façon naturelle un morphisme v: Ck -- Bk, en posant, pour tout vecteur (: E Ci Ch (cl) (v(cj)) Cn V(Cn) Contraintes sur un seul signal Un signal est assimilé, rappelons-le, à un mot infini à droite u sur l'alphabet B. Nous allons voir que les contraintes définies sur un seul signal par le langage CHLOE s'expriment toujours sous la forme u E LB", o L est un certain langage rationnel de B*, dont nous allons développer le calcul. Le signal étant provisoirement assimilé à un mot infini u sur l'alphabet C, les con- traintes vont s'exprimer sous la forme u E LB', o L est un certain langage rationnel de C*. La contrainte finale s'exprimera sous la forme u E U v(L)B" &l vlu4tiol On distinguera en fait deux types de contraintes, les contraintes 'statiques", qui corre- spondent au cas o L est un langage nécessairement fini, et les contraintes 'dynamiques", qui peuvent correspondre au cas o L est un langage infini. Dans les deux cas, le langage L est obtenu comme concaténation finie de langages rationnels particuliers, les langages d'intervalles. Mais il y a une différence dans la lec- ture des contraintes. Par exemple, la contrainte exprimée par des intervalles statiques pourrait être: 'Pour t E IN, entre les instants t + ni et t + n2, le signal possède un front montant unique, entre les instants t + n2 et t + n3, il a une valeur constante v et entre les instants t + n3 et t + n4, il vaut toujours 0". Notons que ni, n2, n3 et n4 sont connues statiquement grâce à l'arbre syntaxique. Ce sont les bornes des intervalles [n, n2], [n2, n3] et [n3, n4] ayant respectivement le statut RISING, VALSYMB, et Low. Dans le cas d'une contrainte dynamique, le langage L est obtenu comme produit d'autres langages rationnels particuliers, les langages d'intevmalles dynamiques. Par ex- emple, la contrainte exprimée par un ensemble d'intervalles dynamiques pourrait être: "Pour t E IN, il existe ni, n2, n3, n4 tels que, entre les instants t + nl et t + n2, le sig- nal possède un front montant unique, entre les instants t + n2 et t + n3, il a une valeur constante v et entre les instants t + n3 et t + n4, il vaut toujours 0o. Ici nl, n2, n3 ne sont pas connus à l'avance, on sait juste dans quel intervalle de temps ils peuvent apparaître, et cet intervalle n'est pas nécessairement borné. Ici ni, n2, n3, n4 sont les images par les datations associées aux lignes portant les intervalles (cf section 3.2) Les langages d'intervalles (statiques ou dynamiques) sont eux-même obtenus à partir de langages dits primitifs, qui sont associés aux symboles primitifs'. Ce vocable recouvre tous les éléments de l'ensemble: V U V U {IRRELEVANT, LOW, HIGH, FALLING, RISING, STABLE, EDGE} c'est-à-dire tous les symboles de variables (éventuellement barrés) et les noms des statuts des intervalles primitifs. Rappelons brièvement la signification intuitive des primitives graphiques de CHLOE: IRRELEVANT On ne s'intéresse pas à la valeur du signal. HIGH Le signal est stable et sa valeur est 1. Low Le signal est stable et sa valeur est 0. FALLING Le signal possède un et un seul front descendant (mais peut avoir O, 1 ou 2 fronts montants). RISING Le signal possède un et un seul front montant (mais peut avoir O, 1 ou 2 fronts descendants). STABLE Le signal est stable mais on ne connaît pas sa valeur. EDGE Le signal change de valeur une fois et une seule. ce qui donne pour les langages primitifs associés aux primitives graphiques L(IRRELEVANT) = {0, 1}+ L(HIGH) = 1+ L(Low) = 0+ L(FALLING) = 01+0+1 L(RISING) = 1'0+1+0' L(STABLE) = 0+ U 1+ L(EDGE) = 0+1+ U 1+0+ D'autre part, les langages primitifs associés à chaque variable v sont: L(v) = v+ et L(v) = v+ On peut alors définir formellement la notion d'intervalle. là ne paa confondre avec le langage primitif des chronogrammes Un intervalle statique est un intervalle appartenant à une StaBasArea. C'est un triplet I = (n, m, t) o n et m sont respectivement la borne inférieure et supérieure de l'intervalle fournies par l'arbre syntaxique. Ce sont des entiers tels que O Ici et cela sera le cas tout au long de la section le complémentaire de L est pris dans C*. Par exemple, si n = 0, m = 3, t = EDGE et signe = NOT, on a L(I) = (0+1+ u i+o+)C n C3 = {000,010,101, 11} Un intervalle dynamique est un intervalle qui appartient à une DynBasiArea. Ici on ne tient pas compte des bornes inférieure et supérieure de l'intervalle, la largeur de l'intervalle dépendra de la largeur de la zone à laquelle il appartient. La sémantique des chronogrammes dans les expressions rationnelles ne tient pas compte de l'ordre des événements sur différentes lignes. Nous verrons en fin de chapitre ce que cette hypothèse entraîne comme différence avec la semantique indexicale. L'intervalle sera alors simplement I = (t) o t définit le statua. Le langage associé à I est le sous-ensemble de Cdéfini par L(I) = L(t) Si signe de I est NOT alors L(I) = L(t) Ici le complémentaire de L(t) est dans C*. Par exemple, si t = EDGE, on a donc L(I) = (0+1+ U 1+0+) Une ligne qu'elle appartienne à une StaBasArea ou à une DynBanArea est une suite d'intervalles. Le langage associé à une ligne (Il, I2,.., I.) est défini par L(Il, I2, * **, I,) = L(I&)L(I2)... L(I,) Cette construction n'est valable que parce que dans la construction de l'arbre, les inter- valles d'une même ligne sont totalement ordonnés. En effet, une ligne syntaxiquement correcte, ne possède aucune partie indéfinie, et il ne peut pas y avoir de recouvrement entre les intervalles d'une même ligne. Si signe de Lig est NOT alors: L(Lig) = L(I,I2,..., I) = (L(I)L(I2)... L(I))' Si on prend une ligne Lig appartenant à une StaBasArea, et composée de trois inter- valles, Il = (0, 7, v), I2 = (7,12, EDGE) et I3 = (12,15, v) et o signe=--NOT on a alors L(Lig) = [(v+ n C7)((0+1+ u 1+0+) n CS)(e+ n C3)]c Si on considère un ligne complètement isolée du chronogramme qui l'englobe, et L le langage associé à cette ligne, la contrainte définie par cette ligne est l'ensemble U v(L)Bw V est unie "&ltion Autrement dit, pour calculer la contrainte définie par une ligne, on calcule d'abord le langage L associé à cette ligne sur l'alphabet étendu C et on lui applique tour à tour les valuations possibles. Contraintes sur plusieurs signaux: StaBasArea et DynBasArea Nous allons maintenant définir le langage associé à une contrainte portant sur un ensemble de k signaux. Quelques notations complémentaires nous seront utiles. Soit A un alphabet. Pour chaque entier k, on note Ak l'alphabet formé de k-uplets de lettres de A, que l'on notera comme un vecteur colonne. Par exemple B8 est égal à l'ensemble des octets, et le triplet ( 0) est une lettre de B3. Ainsi (1) ( ) (1) () ( ) est un mot sur l'alphabet B3. En lisant successivement les lignes de la représentation précédente, on obtient les trois mots 10110, 11000 et 10000. On peut donc représenter le mot u donné ci-dessus par le triplet (10110, 11000, 10000) de mots de B*. Cette situation est générale: on peut toujours représenter un mot de longueur n sur l'alphabet A,, comme un vecteur de mots de A à k composantes. ai,, \ a2,1 a,, ai,2 a2,2 a Ga,), a2,k.. On note rTA: A -* A' x A' x... x A* l'application définie par k&ois ai,, a2,1 H aj Aai,2 a2,2 Jan,2J al,k a2,k an,k /aa,,,,, l222 ',2.... % lk 2,t a,: L'application TA est en fait un morphisme de monoides de A,* dans A' x A' x... x A'. Ce n'est cependant pas un isomorphisme (sauf si k = 1) puisque les composantes d'un élément de A* x A* x..--. x A* ont des longueurs qui ne sont pas nécessairement égales. Ceci conduit à noter Dk(A) = {(Uj,U2,...,Ui) E A* x A'-.- x A* j luil = Ju2j =... = lull} l'ensemble des k-uplets de mots de même longueur de A*. On voit que rA induit un isomorphisme de Ak sur Dk(A), ce qui permet d'identifier les k-uplets de Dk(A) à des mots de AI. Revenons aux signaux. Soit S l'ensemble des identificateurs des signaux. Dans un premier temps nous dirons que cet ensemble est égal à la réunion des identificateurs de signaux de l'hypothèse et de la conclusion du chronogramme. Ces deux ensembles ap- partiennent à l'arbre syntaxique. Cet ensemble est suffisant pour définir la sémantique intrinsèque du chronogrammne, mais dès que l'on veut composer ce chronogramme un système à vérifier ou à spécifier, il est nécessaire de connaître des informations supplé- mentaires sur l'ensembles des signaux de ce système. Une multi-colonne qu'elle soit statique StaBaiArea ou dynamique DynBas rea est un triplet M = (rank, width, LIG). width correspond à la largeur de la zone, ce sera soit un entier positif ou nul dans le cas des StaBasArea, soit un segment dans les DyBasArea. rank est la position de la multi-colonne dans la scene, mais ici il ne nous servira pas car la liste des multi-colonnes est par construction totalement ordonnée. LIG = (Ligq,.., Ligt) correspondant à la liste des lignes de la zone. A chaque ligne Ligij eat associé un signal s(j) E S. Notons que l'application s: LIG - S n'est ni injective, ni surjective. En effet, intuitivement, à chaque ligne correspond un signal, mais il est important de noter que deux lignes ou plus peuvent être attribuées au même signal physique. Ce procédé permet d'imposer plusieurs contraintes distinctes sur un même signal aux même cycles. On pourra aussi noter que tous les signaux de S ne sont pas nécessairement présents dans la LIG certains d'entre eux peuvent apparaître seulement dans l'hypothèse ou dans la conclusion. Soit S = (X1,...,Xà) l'ensemble des identificateurs des signaux du système. Pour sig E S L(sig) correspond au langage engendré par l'ensemble des contraintes portant sur ce signal. L(sig) = n L(Ligj) jerk (ng) Remarque, par convention, on a pour sig E S tel que s'-(sig) = 0 L(sig) = B' Le langage associé à une multi- colonne M est par définition L(M) = Ci " n ic'((L(X1) x L(X2) x... x L(X^)) n D^(C)) Si signe de M est NOT alors: L(M) = C^"" n 7rc'((L(Xi) x L(X2) x... x L(X^))' n D^(C)) Pour comprendre la formule précédente, on peut noter qu'après l'identification des élé- ments de Dk(C) avec ceux de C*, on écrirait, k L(M) = C n II L(X,) Dans le cas d'une multi-colonne statique StaBasArea, uwidth est un entier. Autrement dit, on sélectionne les k-uplets (ul,u2,...,uA) tels que u, 6 L(X1), u2 6 L(X2),... Uk E L(Xk) et Jul1 = 1U2 =... = Iu-k = width et on les identifie à des mots de C*. Dans le cas d'une multi-colonne dynamique DynBasArea, width est un segment de IN qui n'est pas nécessairement borné à droite. Soient BI, BS les entiers représentant respectivement les bornes inférieure et supérieure de ce segment si le statut de ces bornes est fermé, on aura alors: k L(M) = C[r'Is n ^'(Il L(Xi) n Dk(C)) i=o Suivant le statut (ouvert/fermé) des bornes on déduit facilement la définition de L(M). Maintement, si BS = oo alors: k L(M) = CiBI"[. n 7r1(II L(X*) n D2(C)) i=o o BI k = c \ U ck i=0 c'est à dire tous les mots d'au moins BI lettres. Nous venons de définir une multi-colonne par un langage rationnel de Cà. Or, étant donnée une valuation v, nous voulons définir une multi-colonne par un langage de B. Si ce langage existe, il est défini par l'expression k L.(M) = v(c,'" n (.'( II L, n 4,(C))) i=o Il reste donc à montrer que L,(M) est bien rationnel. Pour ce faire montrons que v commute avec la réunion. Lemme 3.1 Soit v: C -- B une valuation et soient L1,L2 deuz langages de C*. v(Li U L2) = v(Li) U v(L2) Preuve: m E v(Lî U L2):- 3m' E L U L2m = v(m') :: 3m' E L V 3m' E L2m = v(m') m E v(L) V m E v(L2) -;: m E v(Li) U v(L2)O Malheureusement, une telle commutation ne marche pas avec l'intersection dans le cas général. Montrons pourquoi elle marche dans le cas particulier qui nous concerne. Lemme 3.2 Soit v: C -- B une valuation et soit L1 langage de C et n E N v(Ll n C") = v(L,) n v(C") Preuve a) m E v(L,) n v(c"):- 3m, E Li/m = v(mî) 3m2 E C"/m = V(m2) alors Jm =v(M2) I=n t m = v(m):-| m =l m I donc mi E C" On a donc ml E L1 n C" et donc m 6 v(L1 n C") b) m 6 v(L1 n C") 3mn 6 L1 n C"/m = v(ml) Bm, E Lm =E v(m") m E v(L,) - 3m, E C"m =E v(mi) m E v(C") On a donc m E v(L) n v(C") o Lemme 3.3 Soit v: C -* B une valuation et soient L1, L2,..., Là des langages de C'. En notant -ri la i-ième projection de B* dans B' définie par ri(ml, m2,.. ., mk) = mi, on a alors la formule suivante k (CB"']" n ( -, L, n D, (C))) = B[B,., ( n -xil(L))) i=O l M=B1 E V(Clk) V(C2,k) v(c),) bl,l b2,1 (bM'i = U (Bkn. 2.I... I , bn,, E v(Li)}) B (,(:b2,) b bis.. bll b2, bm, bl,2 b22 b.12} MBS = U (Bi' n UlU2...Um rl(Ulu2...U-n,,,) E v(L,),...,,',(ulu2-. u",) E v(L,) m=BI = BIBIBn n,- lv(L,) o 1 par la conclusion. Plus formellement, on dira qu'un mot infini w sur l'alphabet B, vérifie une propriété P = ((M, M2,.. M,),(N1, N2,.. N,)), o les Mi et les Ni sont des multi-colonnes, si, pour tout suffixe s de w, il existe une valuation v telle que pour toute factorisation de s de la forme s = ulu2 uu,+ avec u E L,(M), u2 L.(M2),..., u. E L.(M,), u,.+1 E B ', il existe une factorisation s = uu *.. uu,+, avec u4 E L,(Ml) n L,(N1), U' E L.(M2) n LL(N2),..., u E L.(M,) n L(N,), u'.+ E Bk-. Le résultat suivant fournit une autre formulation de cette condition. Théorème 3.1 Un mot infini w sur l'alphabet B, vérifie P si et seulement si il ne possède aucun suffze dans l'ensemble K(P) = n L.(M,)L. (M2)-. L.(MV)Bk v/ vu-itioa L\((L(Ml) n L,(N,))(L.(M2) n L(N2))... (L,(M, .)n L(N,)))B' Preuve Il est plus facile de raisonner sur la négation de la condition. Par définition, un mot infini w sur l'alphabet Bi, ne vérifie pas P si et seulement si il existe un suffixe s de w tel que, pour toute valuation v, il existe une factorisation de s de la forme u = UlU2 - u,.+1 avec u1 E L,(Mz),u2 E L.(M2),...,u, E L,,(M.),u,+, E Bk mais telle que (L.(M1) n L.(N1))(L.(M2) n L.(N2))... (L.(M) n L.(N,)))B Théorème 3.2 Si le champ signe de la scène conclusion est égal à NOT alors on a K(P) = n L.(M1)L,(M2)... L(M,)B À, siu&som \(((L,(M,) n L,(N1))(L,(M2) n L,(N2))... (L(M,) n L,(N,))) B Preuve Dans ce cas aussi, il est plus facile de raisonner sur la négation de la condition. Intuitivement, les mots qui vérifient la propriété sont les mots o il n'existe aucun suffixe qui vérifie l'hypothèse et la conclusion en même temps. Il n'y a pas ici de problème de synchronisation entre les zones grâce à l'intersection des langages de chaque zone de l'hypothèse et de la conclusion. On a donc, un mot infini w sur l'alphabet Bu ne vérifie pas P si et seulement si il existe un suffixe s de w tel que, pour toute valuation v, il existe une factorisation de s de la forme u = ulu2... u, u.+l avec ul E Le(Ml),u2 E L.(M2),...,u, E L.(M,),u,.+l E fi mais telle que S E (L.(Mi) n L.(N))(L.(M2) n L.(N2))... (L.(M,) n L.(N,))B' Remarque: Le problème est différent lorsqu'il s'agit de nier l'hypothèse car il faut trouver tous les mots o il existe un suffixe qui ne vérifie pas l'hypothèse ni la conclusion syn- chronisées. Si l'on inverse, cela donne l'ensemble des mots o tous les suffixes vérifient soit l'hypothèse soit la conclusion. Cela n'a pas encore été formellement défini. De la formule de l'énoncé en résulte immédiatement le corollaire suivant. Corollaire 3.1 Un mot infini w sur l'alphabet Bi, vérifie P si et seulement si il appartient à l'ensemble L(P) = B' \ BiK(P). Corollaire 3.2 Si le champ signe de la propriété P est égal à NOT alors un mot infini w sur l'alphabet Bk vérifie NOT P si et seulement si il appartient à l'ensemble L(NOT P) = BZK(P) c'est à dire l'ensemble des mots o il eziste un suffize qui ne vérifie pas la propriété de départ. Le résultat principal est le suivant Théorème 3.3 Pour toute propriété P, l'ensemble L(P) est une partie rationnelle sans- étoile de niveau de concaténation 3. Preuve Ici nous ne donnerons que la dernière étape de la démonstration. Dans le rapport [ALP92], la place dans la hiérarchie des langages rationnels de chaque noeud de la grammaire est formellement prouvée. En effet, nous avons démontré dans ce rapport que les langages L,(I) pour I un intervalle, L,,(Lig) pour Lig une ligne, et L,,(M) pour M une zone sont de niveau de concaténation 3/2. On a donc les langages L,(Mi) et L(N,) sont de niveau 3/2. Comme les langages de niveau 3/2 sont fermés par intersection et par produit, les ensembles L,,(M,)L,(M2)... L, (M,)B" et ((L,,(M,) n L,,(N,))(L,,(M2) n L,,(N2))...(L,(M,.) fl L.(N, )))Be sont de niveau 3/2 également. Par conséquent K(P) est de niveau 2 et L(P) est de niveau 3. E0 Contraintes Nous allons maintenant donner la sémantique dans les langages rationnels des chrono- grammes pour la spécification. Dans ce cas là, un chronogramme est vu comme une contrainte supplémentaire que l'on ajoute à l'ensemble des contraintes déjà existantes. On appelle contrainte une suite finie de propriétés. Si (Pl, P2,..., P,) est une contrainte, et si L(P1), L(P2),.. ., L(P,) sont les ensembles de mots infinis associés aux propriétés P1, P2,..., P., l'ensemble associé à la contrainte est par définition L(P1) n L(P2) n... n L(P,,). Autrement dit, une contrainte peut être assimilée à une conjonction de propriétés. Cormme les ensembles de niveau 3 sont fermés par intersection, on déduit immédiatement du théorème 3.3 le résultat suivant: Corollaire 3.3 L'ensemble de mots infinis associé à une contrainte est une partie sans- étoile de niveau 3. Vérification de propriétés Dans le monde de la vérification de propriétés, on a donc le modèle du système à valider. Soit L(S) le langage rationnel engendré par la machine à états finis définie dans le modèle. Le système S vérifie la propriété P si et seulement si: L(S) C L(P) Ici, bien sûr, les langages L(S) et L(P) sont définis sur Bk, o k est le nombre de variables d'états ou signaux du modèle. 3.4 Les différentes sémantiques des multi-colonnes Pour bien comprendre les différences de sémantiques entre les différents type de multi- * colonnes nous allons donner un exemple: Soit un chronogramme primitif ne possédant qu'une multi-colonne dans chacune de ces Scenes. Par construction, ces deux zones doivent être de même type (StaBasArea ou StaBasArea) et de même largeur. Dans le cas de zones statiques StaBasArea, il n'y a aucune différence sémantique en- tre la sémantique indexicale et la sémantique en langage rationnel. Figure 3.2: Un exemple de chronogramme statique Dans la figure 3.3 et c'est le cas pour toutes les StaBasArea, les différents fronts de l'horloge sont syntaxiquement définis et donc le temps et l'ordre entre les différents 1 Es événements sur l'ensemble des lignes du chronogramme. Dans le chronogramme de la figure 3.3 le signal sigl reste stable à la valeur 1, deux et seulement deux périodes d'horloge avant de redescendre à la valeur O pour encore trois périodes. La transition descendante du signal sig2 devra se faire après une période de stabilité à la valeur 1 de quatre périodes, c'est à dire deux périodes d'horloges après la transition sur sigl. Ces deux conditions permettront à l'hypothèse d'être reconnue. L'horloge de l'hypothèse étant la même que celle de la conclusion, les événements de la conclusion se synchronise de la même façon. Si l'hypothèse est reconnue, la transition sur sig3 devra être réalisée une et une seule période après celle de sigl. Dans le cas de zones dynamiques DynBasArea il y a une différence entre leur se- mantique indexicale et leur sémantique en langage rationnel. Reprenons le chronogramme précédant, et remplaçons dans l'hypothèse et dans la conclusion les StaBasArea par des DynBasirea. Figure 3.3: Un exemple de chronogramme dynamique Nous allons utiliser ce chronogramme pour illustrer ces différences d'interprétation. Dans la sémantique indexicale, qui peut être considérée comme la sémantique la plus intuitive, l'ordre des événements sur les différentes lignes du chronogramme est très important. En effet, la transition descendante sur le signal sig2 de la zone définissant l'hypothèse doit nécessairement avoir lieu après la transition descendante sur le signal sigl de cette même zone. Suivant un axe des temps allant de gauche droite, on dira que la transition sur sig2 apparaît dans le futur de la transition sur sigl mais on ne sait rien sur le temps qui va s'écouler entre les deux transitions. Cette contrainte correspond bien à l'intuition que l'on a de ce chronogramme. Cette interprétation est en fait la plus courante, et c'est pourquoi nous l'avons choisie dans la définition de référence du langage.Dans cette sémantique, l'ordre que l'on peut appeler intuitif, est transposé au niveau des zones de même rang. En effet, dans le cas du chronogramme de la figure ??, la transition sur le signal sig3 devra se faire entre les deux transitions repérées par l'hypothèse. En revanche dans la sémantique en langage rationnel, l'ordre entre les événe- ments sur différentes lignes n'est pas pris en compte. Cela est parfois le cas dans les chronogrammes utilisés dans la définition des protocoles, o l'important est l'ordre des événements sur une ligne donnée, on ne s'interesse pas aux relations chronologiques entre différentes lignes (qu'elle appartiennent à la même zone o à deux zones de même rang). Dans l'exemple de la figure ?? seules les périodes de stabilité et l'apparition des événements sur les différents signaux sont prises en compte. Ici le front sur sig ainsi que celui sur sig2 ne sont pas ordonnés dans le temps. Prenons un exemple de trace possible pour les deux signaux de l'hypothèse sigl, sig2. Trace(sigl) = 00001111100 Trace(sig2) = 00011110000 Pour ces traces, et dans le sens donné par la sémantique rationnelle, l'hypothèse est reconnue à partir de la cinquième période. En effet, le signal sigl passe de la valeur 1 à O après une période de stabilité de six périodes d'horloge, le signal sig2 transitera après 3 périodes. Les deux fronts descendants sont reconnus mais celui sur sig2 apparaît avant celui sur sigl. Trace(sigl) = 0000 111100 I Trace(sig2) = 0001 1110000 En revanche pour la sémantique indexicale, cette configuration ne permettrait pas d'instancier l'hypothèse (les événements n'apparaissant pas dans le bon ordre). En fait, la même propriété interprétée dans sa sémantique rationnelle et exprimée par le chronogramme ?? peut être exprimable dans la sémantique indexicale par le chronogramme suivant. Grâce aux statuts de type BEvent, l'ordre des événement peut ne pas être explicitement défini. F. * L mp e d l m - -' -=-- " '= --"' xx Figure 3. -. Le.. m e p _'IfXu X _ C X X *1 n n nInnm m [, ni [Wmmam mm { Fiur 3.:L ieporf/xrme asl 6atqeidxc Ici nous voyons une différence qui peut paraître fondamentale entre les deux séman- tiques. Alors pourquoi deux sémantiques divergentes? En fait, les recherches que nous avons effectuées dans la définition du langage CHLOE ont été réalisées en parallèle, avec des raisons différentes. En effet, la sémantique en terme d'intention a été écrite dans le but de baser le compilateur vers le langage SIGNAL. On s'est alors aperçut qu'elle été bien adaptée aux différents aspects du langage CHLOE, et que l'on pouvait définir le langage complet en étant en permanence en phase avec les intuitions que l'on pou- vaient avoir sur l'ensemble des chronogrammes. La sémantique en termes d'expressions rationnelles a été réalisé pour nous connecter au monde des langages rationnels qui est un monde o de nombreux résultats théoriques existent. Il était alors importants de savoir quelle place pouvaient prendre les chronogrammes dans la hiérarchie des langages rationnels et d'établir des résultats théoriques sur la complexité des automates générés par les compilateurs. Malheureusement, nous n'avons pas encore pu spécifier l'ensemble des chronogrammes. Mais cette divergence sémantique sur les multi-colonnes dynamiques nous a permis de mettre à jour un type de chronogrammes différents utilisé principalement dans la définition des protocoles et qui pourait faire partie d'une deuxinème génération de chronogrammes. Chapitre 4 Les générateurs de code de Chloe Après avoir défini syntaxiquement et sémantiquement le langage des chronogrammes, il fallu leur donner les moyens d'être utilisés comme outils de validation de circuits. Dans le domaine de la vérification de circuit, il existe plusieurs types de langages et d'outils qui permettent de spécifier puis de vérifier des propriétés dynamiques d'un circuit. De ces langages, on a extrait trois familles dans lesquelles on a pris un représentant qui nous permettait de nous interfacer avec les outils existants: 1. SIGNAL pour les langages déclaratifs, flots de données et compilables. 2. CTL pour les langages déclaratifs non compilables. 3. SVHDL pour les langages impératifs parallèles. Une quatrième classe, qui est ceUlle des langages impératifs séquentiels comme C, est accessible via les compilateurs SIGNAL-C. Malheureusement, pour l'instant pour chacun de ces trois langages, il existe des chronogrammes qui ne sont pas compilables et donc non vérifiables et dont on parlera au cours de ce chapitre. Pour l'instant, deux générateurs de code (SIGNAL, SVHDL) ont été réalisés et ont permis d'utiliser l'ensemble des outils de simulation et de preuve compatibles avec ces langages. Nous allons ici développer les principes sur lesquels sont basés ces deux compi- lateurs, dans le cas de chronogrammes ne possédant que des StaBasfra (Basic Static Synchronous Area). Puis, dans un deuxième temps, nous discuterons sur les possibil- ités de généralisation de cet algorithme aux DyzBasr.a (Basic Dynamic Synchronous Area), et sur ses limites. Nous développerons ensuite comment, grâce à un couplage entre cet algorithme et les Model Checkers basés sur de la logique temporelle CTL, il est possible de vérifier des propriétés qui ne sont pas compilables directement en CTL ni dans aucun des deux langages (SIGNAL et SVHDL). Nous nous engagerons enfin vers une explication détaillée du générateur SIGNAL. 4.1 Principe généraux des compilateurs 4.1.1 Méthode de vérification des chronogrammes statiques Les propriétés de CHLOE sont basées sur une structure binaire avec d'un coté l'hypothèse et de l'autre la conclusion. On dira qu'un système vérifie bien la propriété si et seulement si "quelque soit un chemin accessible du système, chaque fois que l'hypothèse est reconnue dans ce chemin, alors la conclusion doit nécessairement l'être aussi en même temps". On n'est pas ici dans le cas d'une implication logique simple car il existe dans l'hypothèse et dans la conclusion des aspects temporels et de synchronisation très importants. L'algorithme de compilation a été réalisé pour les sémantiques extrinsèques des chronogrammes (cf chap 3) et, plus précisément, dans une optique de vérification d'une propriété sur un modèle. Nous verrons dans la section suivante, comment, grâce à des modifications très légères et surtout grâce au langage et au compilateur SIGNAL, on peut ré-utiliser une grande partie de cet algorithme pour une spécification par contrainte. En fait, dans le cas de la vérification de propriétés sur un système, il n'est pas question de synthétiser l'automate générant l'ensemble des patterns conformes au chronogramme. Nous allons créer pour chaque chronogramme, une machine correspondant à un analyseur de traces qui vérifie à chaque instant si le système satisfait la propriété définie par le chronogramme en observant les traces d'exécution du système. Nous ne faisons donc pas de la synthèse de programmes, mais des vérificateurs. Le principe qui a été adopté dans l'algorithme est, dans le cas o cela est possible (c'est-à-dire pour l'instant pour les chronogrammes statiques), de ramener toutes les in- formations nécessaires à la vérification de la propriété dans un seul signal qui portera ce que l'on appellera "la valeur de vérité de la propriété à chaque instant'. Ce signal peut être assimilé à un drapeau qui se lève si la séquence viole la propriété. En fait, chaque chronogramme représente une machine à état fini dont l'interface est composée, pour sig- naux d'entrées, de l'ensemble des signaux du chronogramme et de l'horloge, et pour signal de sortie, du signal "OK" portant la valeur de vérité de la propriété. A partir du moment o cette machine peut être réalisée, les méthodes de preuve o de simulation deviennent alors très simples. Il suffit, de créer un nouveau modèle en composant le modèle à vérifier et la propriété et en rajoutant le signal "OK' en sortie du modèle. Dans ce nouveau modèle, il y a dans certains cas une duplication des états avec une variable d'état supplémentaire. Pour un état donné du modèle initial: * Si tous les chemins menant à cet état vérifient la propriété, alors on lui associe un état dans le nouveau modèle avec la variable OK à true. * Si aucun chemin menant à cet état ne vérifient la propriété, alors on lui associe un état dans le nouveau modèle avec la variable OK à false. * S'il existe des chemins menant à cet état qui vérifient la propriété et d'autres non, alors on lui associe deux états dans le nouveau modèle. L'un représentant tous les chemins vérifiant la propriété avec la variable OK à true, et l'autre représentant ceux qui ne la vérifient pas avec la variable OK à false. MODME.K DUO Figure 4.1: La machine résultante Vérifier la propriété consistera alors à observer cette variable pour tous les états ac- cessibles du nouveau système, et à prouver qu'elle porte toujours la valeur true. Ce test est réalisé rapidement avec des outils de preuve manipulant les machines à états finis, ou bien dans le cas d'une exhaustivité moindre, par les outils de simulation. Cette façon de vérifier les propriétés donne aussi des indications très intéressantes sur le diagnostic des erreurs. En effet, on peut facilement localiser l'ensemble des chemins qui amènent a l'erreur. Cette méthode a certes beaucoup d'avantages car la preuve consiste alors à parcourir (sans le créer explicitement) une seule fois l'espace d'état du nouveau système, mais elle entraine une augmentation du nombre de variables d'états proportionelle à la largeur du chronogramme. Cette augmentation, le plus souvent négligeable par rapport au nombre de variables d'états du système, peut s'avérer difficile à gérer dans le cas de chronogramrmes larges et pleins c'est-à-dire, avec beaucoup d'informations à mémoriser et donc, générant un nombre important de variables. 4.1.2 Décomposition de la machine Nous allons maintenant montrer comment construire cette machine en composant les ma- chines correspondant aux scènes, elles même composées de machines correspondant aux zones, et ainsi de suite jusqu'aux intervalles pour qu'à chaque instant on connaisse la valeur de vérité de la propriété. En fait, le principe que nous avons appliqué pour la vérification d'une propriété sera transféré à tous les noeuds de la grammaire abstraite; la reconnaissance de l'hypothèse, de la conclusion, celle des noeuds de type StaBasàrea, de type BasicLine et de type Basiclnter sera à chaque fois codé sur un signal qui à tout instant, portera comme valeur, true si le schéma a été observé, false sinon. En fait, toutes ces machines peuvent être assimilées à des reconnaisseurs de forme qui à chaque instant testent si la configuration qui leur a été proposée est bien conforme, et si oui, passent le témoin pour la reconnaissance de l'étape suivante. Elles se comportent en fait chacune à leur niveau comme des calques dessinés dans une fenêtre que l'on fait coulisser le long des traces. Au niveau syntaxique,on peut remar- quer deux classes d'objets, il y a ceux qui s'empilent (les scènes et les lignes) et ceux qui s'enchaînent (les zones et les intervalles). Dans la composition des machines, cette clas- sification sera respectée car les objets qui s'empilent sont composés parallèlement, tandis que ceux qui s'enchaînent sont composés séquentiellement. Cette composition séquen- tielle n'est pas tout à fait standart car il est nécessaire de paralléliser pour pipeliner les informations à travers le temps qui seront indispensables pour l'étude. Nous allons maintenant développer les architectures des différentes machines corre- spondant aux objets syntaxiques. L'architecture d'une propriété En premier lieu, et à cause de leur structure binaire, les propriétés, vont être décomposées en deux machines correspondant à chaque BasicScene. * La machine devant reconnaître l'hypothèse; cette machine a pour entrées l'ensemble des signaux de l'hypothèse et pour sortie un signal testant à chaque état si les dernières entrées qui lui sont proposées, terminent une instanciation de l'hypothèse que nous appellerons "OKIHYPO". * La machine devant reconnaître la conclusion; cette machine a pour entrées l'ensemble des signaux de la conclusion et pour sortie un signal spécifiant à chaque état, si les dernières entrées proposées, terminent une instanciation de la conclusion que nous appellerons "OKCONC". A chaque état, la valeur du signal de sortie que nous appellerons "OK" sera donc égale à l'implication logique entre ces deux signaux: Vt OK(t) = (OKIYPO(t):- OKCONC(t)) qui sera programmé sous la forme: (NoTOKHYPO(t)) V OKCONC(t)) Si le champ signe du chronogramme est NOT on a donc: Vt OK(t) = NoT(OKHYPO(t), OKCONC(t)) s, HYPOTHESE OKHYPO SI 0K CK is OKCONCLUSIONNC Figure 4.2: Une propriété positive Nous allons voir comment, pour arriver à cette vérification statique sur chaque état, on a construit les machines correspondant à l'hypothèse et à la conclusion. Elles seront créées en suivant le même schéma correspondant aux noeuds de type BasicScene qui a besoin d'accéder à un ensemble de valeurs passées des signaux et donc à des mémoires. L'architecture d'une scène Pour reconnaître un chronogramme, il est donc nécessaire de pouvoir à chaque instant savoir si l'hypothèse et la conclusion ont été instanciées. Nous avons vu quelle était l'interface de ces machines, nous allons maintenant développer leur corps. Les BasicScene sont divisées en zones, et dans le cas précis seulement en zones de type StaBasArea. En fait, reconnaître à chaque instant une BasicScene, c'est reconnaître que les différentes zones qui la composent se sont bien instanciées consécutivement. si 0. 1) Figure 4.3: Une BasicScene Le signal de sortie de chaque zone, appelé "OKznzcel' pour la k-ième zone de la scène, est un booléen qui permet de savoir, à chaque instant si la succession des zones, du début de la scène jusqu'à elle comprise, a bien été reconnue. Pour une zone donnée, ce signal est donc calculé en fonction du signal de sortie de la zone précédente et de la configuration des différents signaux de la BasicScene. Ce calcul n'est pas immédiat, car il demande un nombre de périodes égal à la largeur de la zone. L'une des caractéristiques de ce type d'architecture est qu'à partir du moment o l'une des zones n'est pas reconnue, toutes les zones qui la suivent ne pourront être reconnues. Le signal de sortie de la BasicScene sera égal au signal de sortie de la dernière zone. Soit nbmncol le nombre de zones de la scène: Vt OK_cene(t) = OKzone"(t) Si le champ signe de la scène est NOT on a: Vt OK-acene(t) = NOT OK.. zonce""(t) L'architecture d'une zone statique Une zone statique (zonek) est composée d'une liste de lignes. L'architecture de la machine suivra aussi le même schéma. Chacune aura comme entrée l'horloge, un signal qui à chaque instant permettra de savoir si la suite des zones qui la précédait a été reconnue ou non (OKzonek-l (t)), et les signaux associés aux différentes lignes.Dans le cas de la première o k = 1 c'est-à-dire la première zone de la scène, OKzone-l (t)est égal à true. Le calcul du booléen qui validera l'instanciation de chaque ligne se fait en parallèle car toutes les lignes ont la même longueur. Soit n le nombre de lignes de la zone, on a: Vt OKzonek(t) = OKJlignek(t) A OKJigne'(t)... A OKligne"(t)) Figure 4.4: Une StaBasirea Si le champ signe de la zone est NOT on a donc: Vt OKzonek(t) = NOT(OKJigne4(t) A OKJigne4(t).... . A OKJligne(t))) L'architecture d'une ligne..DTD: L'architecture des lignes ressemble à celle des scènes et fonctionne sur le même principe. Ici, les lignes ne portent que sur un seul signal et les intervalles remplacent les zones. Mais la validation d'une ligne n'est réalisée que si les différents intervalles qui la composent ont bien reconnu consécutivement une trace licite. Un intervalle ne peut être validé que si tous les intervalles qui le précèdent ont tour à tour été validés, cette information est donnée par le signal de sortie de l'intervalle. Le premier intervalle de la ligne aura comme entrée le signal de sortie de la zone qui le précède. OU: i Figure 4.5: Une Ligne Le signal de sortie de la ligne sera égal au signal de sortie du dernier intervalle. Soit n le nombre d'intervalles dans la ligne ligne: Vt OK ligne(t) = OKinterv"(t) Si le champ signe de la ligne est NOT on a donc: t OKligne(t) = NOT OKinterv"(t) Les intervalles Les intervalles sont les éléments de base de la machine. Le test sur un intervalle se fait comme nous l'avons dit précédemment, en fonction du résultat de l'observation de l'intervalle qui le précède dans la ligne, ainsi que des valeurs successives portées par le signal. Le calcul de la valeur de vérité d'un intervalle se réalise en un nombre de périodes de temps égal à la largeur de l'intervalle. A chaque instant, on doit connaître la valeur de vérité de l'ensemble des intervalles. Pour cela, toute machine représentant un intervalle doit posséder des variables internes qui permettront de savoir si l'intervalle à été instancié ou non, et de calculer l'état suivant à partir de l'entrée courante. Lors de la création d'une ligne, on va instancier les machines qui correspondent aux différents intervalles. Prenons un langage générique, on a alors deux schémas qui corre- spondent au deux classes de statut BStableVal et BEvent. Pour le k-ième intervalle de la ligne portant sur le signal sig, et de longueur n, on aura donc une machine à état fini dont l'entrée est le signal à analyser sig et celui de sortie de l'intervalle précédant que nous noterons OKInt"-1. Sa sortie est le signal OKIntk. On posera sig(t) la valeur du signal sig au temps t. Dans le cas des statuts BStableVal (STABLE, Low et HIGH), on teste en premier lieu l'absence d'événement. On a donc besoin d'une mémoire sur le comportement du signal. Cette mémoire est codée dans un vecteur noté Mem, de longueur n qui est la longueur de l'intervalle. Il faut dans un deuxième temps pour les statuts (Low et HIGH) tester aussi la valeur du signal. Les composantes du vecteur passent à false dès qu'un événement apparaît ou si le signal ne porte pas la valeur souhaitée. Les intervalles sont ouverts, l'initialisation du vecteur Mem pour un intervalle de statut STABLE est donc différent des autres. Posons: ft(sig) = sig(t) pour status = HIGH ft(3ig) = not(zig(t)) pour status = Low ft(sig) = true pour status = IRRELEVANT V t, Mem[l]t = ft(sig) A OKJnt-' et V i E [2,.] Mem[il] = MeM[i - 1]_ A ft(sig) et OK_,nt, = Mem[n]e Posons: ft(sig) = (sig(t) 4 '. sig(t - 1)) pour statu = STABLE V t, Mem[1], = OKInth-1 et Vi E [2,,n] Mem[ilt = Mem[i - 11_, A f(sig) et OK-,ntt = Mem[n]t Mcm Mem f(sig) OKk_1 Ok_1I Figure 4.6: Compilation des statuts Figure 4.7: Compilation du statut HIGH, LOW, IRRELEVANT STABLE À l'inverse, dans le cas des statuts de la classe BEvent, on va tester l'apparition d'un événement particulier. On a encore besoin d'une mémoire toujours notée Mem et de longueur n. Mais on a besoin d'un deuxième vecteur, noté Mem', pour vérifier que cet événement n'arrive bien qu'une et une seule fois. Le premier vecteur Mem devient false dès que l'événement attendu apparaît et reste à false après. Le deuxième vecteur passera à false seulement à l'arrivée d'un deuxième événement de même type. Le drapeau associé à l'intervalle sera donc vrai, ce qui caractérise la détection d'une unique occurence de l'événement de bon type, si et seulement si Mem est à faux et Mern' est à vrai. Posons: gt(sig) = (sig(t) -: sig(t- 1)) pour statu = EDGE gt(3ig) = (aig(t - 1).' sig(t)) pour statu = FALLING gt(3ig) = (3ig(t) _ sig(t- 1)) pour statu = RISING V t, Mem[l]t = OKJntt' Mem'[1]t = OKIntth- et Vi E [2,n] Mem[i]t = Mem[i - 1]tI A ge(sig) Mem'[i]t = (Mem'[i- 1]-1 A gt(sig)) V Mem[i]t et OKJntt = Mem'[n]t A notMem[n]t 4.1.3 Problème dans l'extension aux StaBasArea Nous avons vu que ce type d'algorithme est bien adapté pour les chronogrammes ne possédant que des StaBasArea. A partir du moment o l'on intègre des zones de type DynBasArea, il y a deux problèmes majeurs qui se posent: * La mémoire: C'est le problème le plus important. Il se situe directement au niveau des intervalles dont on ne connaît pas statiquement la longueur, et donc le nombre de mémoires qu'il faut lui associer. Il serait nécessaire d'avoir des langages à allocation de mémoire dynamique. Les intervalles dynamiques devront donc être compilés d'une autre façon. * La synchronisation: Si l'on avait une mémoire dynamique, il resterait un autre prob- lème à résoudre au niveau de la synchronisation des différents événements dans une DynBasArea. Il est nécessaire de connaître à chaque instant comment les intervalles vont se positionner par rapport aux intervalles des autres lignes de l'hypothèse et de la conclusion. Ce type d'information est connu dans l'arbre abstrait d'un chronogramme, mais disparaît si l'on utilise telle quelle la compilation des zones. Il faut donc garder en mémoire, et cela au plus haut niveau de la structure, le moment o un intervalle passe le relais au suivant pour incrémenter une variable qui donnera à chaque instant dans quelle colonne de la DynBasirea on est. Dans le cas o ce problème de synchronisation n'est pas traité, la preuve de l'existence d'une machine pouvant vérifier la correction des traces relativement à une propriété définie par un chronogramme comprenant des zones dynamiques est faite. En effet, les chronogrammes comprenant des zones dynamiques, dont l'ordre des bornes d'intervalles placées sur différentes lignes n'est pas pris en compte, sont rationnels. Ceci est un corol- laire de la définition semantique sous forme d'expression rationnelles proposée section 3.3.2. La solution qui a été adoptée pour certaines classes de propriétés possédant de telles zones, est de coupler cet algorithme avec les algorithmes de preuve basés sur la logique temporelle CTL. Nous allons voir dans la section suivante quelles sont ces sous-classes. 4.2 Couplage de l'algorithme de compilation avec CTL Dans la section précédente, nous avons présenté un algorithme de compilation pour les chronogrammes ne possédant que des StaBasArea. Nous allons montrer au travers d'un exemple, comment ce sous-ensemble des propriétés de sûreté est compilable en CTL. Nous verrons que ce type de compilation pose des problèmes car elle ne peut pas suivre la structure interne des chronogrammes de CHLOE et entraine une explosion très rapide. D'autres logiques temporelles linéaires ou mixte tel la logique CTL* très puissante du point de vue du pouvoir d'expression des propriétés auraient pu servir à formaliser les propriétés déduites des chronogrammes, mais les outils de vérification associés sont d'une complexité beaucoup plus importantes [CD88], [Eme90] et donc moins efficaces que les Model Checkers basée sur la logique temporelle branchée. Nous verrons dans un deuxième temps, au travers de plusieurs classes de chronogrammes comment, grâce à l'utilisation de l'algorithme de compilation des zones statiques et du Model Checker basés sur CTL, des formules CTL simples sont alors générées et permettront de vérifier les propriétés correspondantes. Certaines de ces classes de chronogrammes ne sont directement traduisibles dans aucun des deux formalismes. Nous terminerons en donnant le filtre syntaxique qui permet de définir un sous- ensemble de chronogrammes et donc de propriétés qui pourront être prouvées grâce à cette méthode en donnant l'algorithme général. 4.2.1 Introduction sur la logique temporelle branchée CTL La logique temporelle branchée appelée COMPUTATION TREE LOGIC (CTL) [CG87], utilise un modèle temporel en temps discret et arborescent sur un graphe d'état fini. Chaque état correspond à l'état de toutes les variables du programme à chaque péri- ode d'horloge. Il pourra alors avoir plusieurs successeurs. C'est un bon outil pour la spécification et la preuve de propriétés de haut niveau sur des machines séquentielles. Dans l'annexe D, nous rappellerons brièvement la syntaxe et la sémantique des dif- férents opérateurs de cette logique. Pour plus de lisibilité dans les formules qui seront utilisées dans la section suivante, nous allons ajouter une définition supplémentaire qui n'existe pas dans les opérateurs de base de CTL: -o 1= AX'P - o I= AX(AX.... (AXP))) pour tout chemin (so, **,. J,si), de longueur i, s, 1= P 4.2.2 Compilation des chronogrammes statiques en CTL Nous allons commencer en donnant un exemple de chronogramme statique ainsi que la formule CTL équivalente. Nous généraliserons dans un deuxième temps en présentant les différentes étapes d'un algorithme pour l'ensemble des chronogrammes statiques dont les lignes ne possèdent que des intervalles de la classe des BStableVaL Exemple: Le chronogramme suivant définit une propriété entre les comportements de deux signaux sigl et sig2. Cette propriété se formulerait comme suit: Chaque fois qu'il existe un front descendant sur sigl, et que la valeur du signal ne remonte pas l'instant d'après, alors sig2 reste stable avec la valeur HIGH pendant la transition de sigl, mais transite obligatoirement l'instant suivant. Figure 4.8: Un exemple de chronogramme statique Nous allons donc traduire ce chroaogramme en logique CTL, puis en appliquant les algorithmes de preuve utilisés dans les Model Checkers[CM90], [BM90a] sur le modèleà valider, nous la vérifierons. Le chronogramme est équivalent à. la formule de logique temporelle CTL suivante: S.oit I l'ensemble cdes états initiaux du modè/le, Vso E I so J= AG(sigl = EX( not(sigl) A EX(not(sigl -- (sig2 A AX( (not(sigl) A EX( not(sigl));. (sig2 A AX(.not(sigl) -.. not(sig2)M Les formules CTL sont des formules appliqu/es sur les états, en revanche les c.hronogrammes sont typiquement des contraintes sur des chemins. En fait, seuls les -. hronogrammes pouvant se transformer en une propriété sur les états seront compilables en CTL. C'est le cas des chronogrammes statiques, mais l'introduction de zones dy- namiques dans les scènes peut entraîner, l'utilisation des formules sur les chemins de CTL* [CG87]. L'algorithme ndncal de compilati onoae enrlogrammes stptiques en CTL ne peut pas suivre rue utilsédu langage CHLOE. nest néces[Mire de domposer plus finement les intervales en briques de base correspondant aux unitrn de temps. La d&.mposition des intervalles de statut HIGH ou LOW ne pose pas de problème. En effet, un inter- valle de statut LOW ou HIGH peut àtre dlcomposu en intervalles unitaires (c'est-à-dire de Songueur 1) qui ont tousle mé me statut Low ou HIGH. Les intervalles dont le statut est IRRELEVANT n'entra nent aucune contrainte sur les signaux et doric sont décompil) en des briques de base toujours vraies. En revanche, l'utilisation d'chtervalle dont le statut est de la classe ovonm entratne mans la plupart des cas une explosion des configurations possibles et donc de la formule CTL e vdrifier. Nous allons développer ici l'algorithme qui a permis de générer la formule de l'exemple. Proposition 4.1 Tout chronogramme statique ne possédant que des intervalles Low, HIGH, ou IRRELEVANT est traduisible en CTL. Preuve Dans un premier temps, nous allons partir d'une sémantique basée a priori sur les chemins et qui n'est donc pas traduisible directement en CTL, et montrer comment nous allons la transformer pour se ramener à une formule sur les états. Il ne restera plus qu'à la traduire dans la syntaxe CTL. La première étape consiste donc à décomposer l'ensemble des intervalles en intervalles unitaires: VIi = (statut, BI, BS) appartenant à la i-ième ligne de la scène et portant sur le signal Sig alors Ii(J=,BII+i',IB) avec IÀ = Sig si statut = HIGH = not Sig si statut = Low = true si statut = IRRELEVANT Soit wuidth la largeur de la zone. Soit Hi la i- ième ligne de l'hypothèse composée de k intervalles (Il, I2,'"., Ik) chacun décomposable en brique unitaire. Par exemple, Il de longueur n en (HH2,...,H I), I' de longueur m -n en (H,+x, À -, H,H).... On a donc Hi = (H..H2%, H") soit Ci la i-ième ligne de la conclusion qui de la même façon se décompose comme suit Ci = (CI, C2,..., CL) Hi et C sont les comportements de base déduits de la décomposition des intervalles de la ligne correspondante. Par définition de la propriété, pour tous les états accessibles du système que nous noterons S: Pour tout état, tout chemin partant de cet étot qui vérifie lhypothèse doit vérifier la conclusion. Ce qui s'écrit de la manière suivante: Vsl E S, pour tout chemin (s1,S2,. .) alors, 1= Ai H et 92 I= Ai Hi et.... = Ai HLt s = Ai C' et s2 I= Ai C2 et..s.I= Ai Ca., est équivalent à Vs1 E S, S'il existe un chemin (1,s2,....), tel que s3 1= Ai Hii et s2 = Ai H2 et -,.,id, 1= Ai H. alors (s3 1= Ai Cl et (Vs2 successeur de s1, pour tout chemin (s2,.... ), s21= Ai H2 et...s,j= Ai H, s2 j= A, C, et..i, j= Ai C,)) est équivalent à Vs1 E S, S'il existe un chemin (s1,s2,....), tel que 31 j= Ai Hl et s2 j= Ai H2 et s...,a I= Ai Htid alors (s1 I= Ai Ci et (Vs2 successeur de s1 S'il existe un chemin (s2,33,....), tel que s2 1= Ai H2 et.. sa 1= Ai H alors (32 1= Ai C2 et (Vs3 successeur de s2, pour tout chemin (s3,....),..DTD: À13 j= Ai H. s. I= Ai Hé. S3 jj= Ai C3-S j= Ai C) est équivalent à est équivalent à Vs31 E S, S'il existe un chemin (sl,s32,....), tel que si I= A et s2 1 et *. -s,, Ai =. alors (s3 I= Ai C et (V32 successeur de sl, S'il existe un chemin (s2,33, ..), tel que s2 1= Ai Hj et...,,i I= Ai H-ti alors (32 1= Ai C2 et (Vs. .idt successeur de smh-l otà I= At Hé '- s3,,I= Ai C)) Ce qui correspond dans la syntaxe CTL à la formule suivante: Soit I l'ensemble des états initiaux du modèle, V so E I 0 |= AG((Ai Hl A EX(Ai H2 A.. EX(Ai Hi))) :(Ai Ci A AX((Ai H2 A EX(.. EX(A, Hi)))..DTD: - (Ai Ci A...... : Ai CG -1 A AX(Ai H u =* Ai C',,,)))) Remarque: Il est important de voir que cette réécriture préserve entièrement la synchro- nisation des différents événements. Pour les autres statuts, la décomposition en intervalles unitaires, n'entraîne plus seule- ment un nuplet mais un ensemble de nuplets correspondant à l'ensemble des comporte- ments possibles. Par exemple, pour un intervalle I dont le statut est RISING, dont la longueur est de 3 périodes d'horloge, et appartenant à une ligne portant sur le signal Sig, on a alors la décomposition suivante: I = ( (not Sig, not Sig, Sig), (not Sig, Sig, Sig), (not Sig, Sig,not Sig),(Sig, not Sig, Sig)) La composition de plusieurs intervalles de ce type devient alors exponentielle. L'autre problème qui se pose dans ce type de compilation est l'introduction, dans les différents noeuds d'un chronogramme, du champ signe à NOT. Dans l'algorithme défini dans la section précédente, cette introduction ne posait pas de problème, en revanche, dans le cadre de la traduction en CTL, le problème devient critique. En effet, à cause de la synchronisation nécessaire entre les différentes périodes de l'hypothèse et la conclusion, on est contraint de décomposer les intervalles en briques de base correspondant aux unités de temps. La négation d'un intervalle oblige à définir en extension l'ensemble des con- figurations possibles. Cela entraîne la multiplication de ces configurations, par exemple la négation d'un intervalle stable de largeur 4 correspond à 14 configurations possibles: de toutes les configurations possibles, seules les deux définissant la stabilité totale sont à écarter. La structure de l'arbre et sa compacité ne servent alors à rien. Le problème est encore plus délicat lorsqu'il s'agit de lignes, de zones ou de scènes. Cela ne veut pas dire qu'il n'est pas possible de les traduire, mais on retombe alors dans le même problème que dans le cas des intervalles BEvent, et l'explosion des cas rend cette possibilité difficilement utilisable dans la pratique. Dans la section 4.1.2, nous avons présenté un algorithme de compilation pour les zones statiques, qui à chaque instant donne la valeur de vérité de la propriété relativement aux traces qui lui sont proposées. La complexité de cet algorithme n'entraîne pas de problème, contrairement à CTL, dans l'utilisation des intervalles dont le statut est de type Event, et dans la négation de différentes parties du chronogramme. Ainsi, pour éviter l'explosion, nous avons pensé coupler cet algorithme avec les Model Checkers CTL pour permettre la preuve de propriétés plus complexes. Dans un premier temps, l'algorithme va transformer ce qui était des contraintes sur des chemins en contraintes sur des états en créant pour chaque zone la machine correspondante à une seule sortie. Dans un deuxième temps, on traduira la propriété définie par le chronogramme en relation entre les sorties de ces machines en utilisant la logique CTL. 4.2.3 Exemple de couplage algorithme/Model Checker CTL Les chronogrammes statiques Pour ce type de chronogrammes, nous allons utiliser le nouveau modèle qui a été généré grâce à l'algorithme présenté dans la section précédente. En fait la compilation plus la composition des chronogrammes opèrent une transformation profonde de la structure temporelle sous-jacente. En effet, la transformation des propriétés sur les chemins di- rectement en propriété sur les états est réalisée grâce à l'apparition de nouvelles variables d'état. La vérification d'un propriété consiste dans le cas des chronogrammes statiques à parcourir l'ensemble des états accessibles du nouveau système et vérifier que le nouveau signal que nous avons appelé OK' est toujours vrai, c'est à dire porte toujours la valeur true. Cela se formalise facilement en utilisant les opérateurs de la logique CTL, et se vérifie en utilisant le Model Checker. La formule à vérifier sera donc la suivante: Soit I' l'ensemble des états initiaux du nouveau modèle, V so0 E I' so J= AG(OK) Pour ceux dont le champ signe est égal à NOT, c'est à dire spécifiant l'existence d'au moins un état ne vérifiant pas le chronogramme initial, la formule sera: Soit ' l'ensemble des états initiaux du nouveau modèle, V 3o E J' Jo J= not AG(OK) ou bien so = EF(not OK) L'utilisation de CTL n'est pas très efficace pour les chronogranmmes statiques, car elle entraine l'utilisation d'algorithmes lourds liés aux opérateurs de CTL, alors que l'observation directe de la variable 'OK" est beaucoup moins complexe. En revanche nous allons voir dans les exemples suivant, qui introduisent des zones dynamiques, que l'usage d'un telle logique temporelle peut être très avantageuse. Introduction de DynBasArea Nous allons prendre maintenant un exemple de chronogrammes comprenant des DynBasArea. Il appartient à une famille de chronogrammes que nous ne savons compiler ni en utilisant l'algorithme de compilation tel quel, ni dans certains cas dans la logique CTL. C'est le cas comme nous le montrerons dans la suite, des propriétés de vivacité sur les chemins ou plus généralement des propriétés sur des chemins de longueur non bornée, qui sont exprimables sous forme de chronogrammes. Cependant, nous illutrerons sur un exemple simple un shéma de compilation en CTL* [CG87] qui ouvre d'autres voies de vérification. On va donc utiliser un mixage des deux algorithmes pour prouver certaines sous- classes de propriétés de sûreté ou de vivacité. Nous allons commencer par donner des exemples simples. Chaque BasicScene possède deux zones statiques séparées par une zone dynamique non bornée. Il n'existe pas de contraintes sur les signaux dans les zones dynamiques. Ceci est important car le passage à des zones dynamiques non vides n'a pas encore été traité. ZON-E1 ZOtNE2 ZONE 3 ZONE4 Figure 4.9: Structure du chronogramme nl n'y a ici aucune contrainte sur le nombre de signaux ni sur les comportements de ces signaux dans les différentes zones. En revanche, le champs uidth de la ZONE1 et de la ZONE3 sont égaux, ainsi que celui de la ZONE2 et de la ZONE4. Dans la suite, nous poserons wîdthzone2 comme la largeur de la ZONE2, uidthzone4 celle de la ZONE4, c'est-à-dire le nombre de périodes d'horloge qui s'écoulent pendant la zone. Propriétés de sûreté avec des zones DynasArea Dans cet exemple, il existe des contraintes explicites au moins dans les zones statiques de l'hypothèse, c'est-à-dire dans les zones ZONE1 et ZONE2. Le sens que l'on pourra donner à ce type de propriétés est: Chaque fois que la zonel est suivie de la zone2, alors on doit reconnaître la zone3 en même temps que la zonel et la zone4 en même temps que la zone2. On va alors transformer le modèle initial en rajoutant les quatre machines correspondant aux quatre zones statiques. Ces machines sont le résultat de la compilation des différentes zones. 1 *. MOMZZNE 2, z" IZ - oOK LYrM ZJDNE 4 l lo llll ZOt04 1i Figure 4.10: Modèle résultant Ici on a encore une transformation très importante de la structure temporelle sous- jacente qui va transformer la propriété sur les chemins du modèle initial en propriété sur les états du nouveau modèle. Soit M' la nouvelle structure, soit YS le nouvel ensemble d'état, la preuve de la propriété peut maintenant être réalisée en utilisant le Model Checker de CTL sur la propriété suivante: Soit I' l'ensemble des états initiaux du nouveau modèle, V 3o E I' So l= AG((OKzonel A EF(EX'-3'(OK.zone2))) (OK.zone3 A AG (AX'- *d (OK.zone2:- OK.zone4))) Ici on remarque que la synchronisation entre les différentes zones est bien con- servée. Cette propriété est encore théoriquement compilable directement en CTL, mais l'explosion combinatoire que nous avons évoquée pour les chronogrammes statiques est encore plus importantes dans ce type de configurations. Propriété de vivacité On est aussi dans le cas de chronogrammes possédant dans chaque BasicScene, deux zones statiques séparées par une zone dynamique non bornée. Considérons d'abord, qu'il n'existe aucune contrainte sur les signaux dans les zones dynamiques ainsi que dans la dernière zone statique de l'hypothèse ZONE2 et la première zone statique de la conclusion ZONE3. Le sens intuitif que l'on pourra donner à ce type de propriété est: Chaque fois que la ZONE1 est reconnue, alors on doit inévitablement reconnaître la ZONE4 dans le futur. On va alors transformer le modèle initial en rajoutant les deux machines correspondant aux deux zones statiques qui spécifient des contraintes sur les signaux. ZONEl ki- _oz _O1 Figure 4.11: Modèle résultant La figure 4.12 représente une partie du graphe d'états du modèle initial o nous avons mis en relief l'apparition des différentes zones. On voit alors que pour les chemins o la zonel apparaît entièrement, il est inévitable de reconnaître la zone4 dans le futur. Dans le graphe de la figure 4.13, on représente la même partie mais cette fois-ci pour le modèle modifié, c'est à dire avec deux variables d'états supplémentaires qui sont les drapeaux de chaque machine. La propriété peut alors se reformuler: quels que soient les états o OK.zonel est vrai alors inévitablement OKzone4 sera vrai dans le futur avec bien-sûr un décalage d'au moins la largeur de la ZONE4. Cette propriété est maintenant une propriété sur les états et l'on peut donc utiliser CTL. i. Figure 4.12: Le graphe initial Figure 4.13: Le graphe modifié On va alors prouver en utilisant le Model Checker de CTL, la formule suivante: Soit i ' l'ensemble des états initiaux du nouveau modèle, V o E 1' Oo j= AG(OK.zonel => AF(AX'v-ab"l (OKzone4))) S'il existe des contraintes dans la ZONE3, on aura alors la formule suivante: Soit I' l'ensemble des états initiaux du nouveau modèle, V so E I' so 1= AG(OK- zonel =i (OKzone3 A AF(AX -"' (OKzone4)))) Ce type de propriété est en revanche compilable en CTL*. Par exemple, si les deux zones ZONE1 et ZONE4 ont une largeur de 2 périodes, la ZONE1 visualisant un front descendant sur le signal "Sigl", la ZONE4 visualisant un front montant sur le signal "Sig2", la formule CTL* correspondant sera la suivante: Soit I' l'ensemble des états initiaux du nouveau modèle, V so E I' so j= A(G((Sigl A X(not Sig2)) > F( X' ((not Sig2) A X(Sig2))))) 4.2.4 Généralisation Dans la partie précédente nous avons donné des exemples d'utilisation du Model Checker CTL pour des chronogramrnmes possédant, dans chaque BasicScene, deux zones sta- tiques séparées par une zone dynamique non bornée et non contrainte. En fait, on peut généraliser cette méthode à un nombre quelconque de zones statiques séparées les unes des autres par une zone dynamique non bornée et non contrainte. Soit (Hi, H2,-, H,,) et (CI, C2,---, C,,) les zones statiques appartenant respective- ment à l'hypothèse et à la conclusion. Soit widthi le nombre de périodes des zones Hi et Ci. Dans un premier temps nous allons donner la sémantique de la propriété dans le modèle initial. Dans un deuxième temps nous la transformerons en prenant en compte les modifications qui ont été introduites dans la construction du nouveau modèle qui contient les différentes machines générées par chaque zone, et donc ce que l'on a appelé leur valeur de vérité respective. Cette modification de la formulation de la propriété n'entraîne au- cun changement dans la définition sémantique de celle-ci, en revanche elle va permettre de transformer ce qui était une propriété sur des chemins du graphe d'états du modèle initial en une propriété sur les états du nouveau modèle. f est tout d'abord nécessaire, comme dans le cas des chronogrammes statiques de décom- poser chaque zone période par période. On a donc VLC la kième ligne de la zone i, la décomposition de cette ligne en intervalle unitaire donne le tuplet suivant (L'[], L=[2],.* Li[widthi]) V , Hi =(Ak Hi 11,,A HH[width]) = (Hi, H"'i) VC,, Ci = (AC, j[l],. CAClwidthi]) = (Ci",... C, CK :S1 in H1 H2 H3 I Figure 4.14: Décomposition des zones Quelque soit k, 0 P-,1 + width._l, P.-1 > P,-2 + width,,_2 *. P2 > uwidth1 et 31 j= H,' et 32 j= H21 et *3* dfit, j= HLM,'i et P, {= Hl' et sp.,+ 1= H2 et *. **+.&2, {= j-HéU, et... et p. j= H et sp.,+ |= H,' et *.*p.+.,,a. j= HLM alors 31 =Cl et 32 =C2 et *.*.,a I=C"^ et sp. j= C12 et p+,1 1= C22 et **SP,+.. C!" et... et P,. j= Cl' et Sp,+, i= C; et *p.+*,.+ @= C" On va maintenant composer le modèle initial avec deux fois n machines correspondant aux différentes zones du chronogramme. Le modèle résultant possèdera alors deux fois n signaux supplémentaires "OKzone" qui sont les valeurs de vérité de chaque zone à chaque instant. Soit S' l'espace d'état du nouveau modèle, alors Vs E S', VZ, s, l= OKz si I=Z1 t + = Z et..+ ets..I= Z.i. a, J= not OK: Tout chemin (sk,...,s), de longueur uidth. vérifie sk l= notZ, ou s3+1 |= notZ2 ou... ou as, 1= notZ,;i,, Par construction du nouveau modèle il n'y a pas d'autre cas. On a donc, Vs1 E S', pour tout chemin (31,2,....), Chaque fois qu'il existe sp*,.., sp. P. > P._I + wUidth._l, P.-_ > P.-2 + wuidth_2... P2 > width1 et s3 j= OK,1 et sP2+t.id = OKH, et... et sp,+.,t |= OKH. alors sl 1= OKc, et s+,.it2 l= OKc, et... et sP,+.idAm j= OKc,. La transformation en une formule sur les états amène la traduction CTL suivante: Soit I' l'ensemble des états initiaux du nouveau modèle, V so E I' so = AG((OKH, A EF(EX"aa2(OKH, A EF(EX"aa(OKH,))... A EF(EXw"a(OKH. ))) ' (OKc, A AG(AX'2(0KH, A EF(EX" Uh"(OK,... A EF(EX-"U(OKW.")))). (OKc, A AG(AX""(OKH. OKc.))))))))) S'il n'existe pas de contrainte dans la zone H,, on est ici dans une autre classe de pro- priétés. Dans ce cas, la sémantique que l'on donne à ce type de propriétés est la suivante: Vs1 6 S, pour tout chemin (31,32....), Chaque fois qu'il existe 8pj, -.. Sp._, P.-I > P.-2 + width.-2, P,-2 > P- -3 + UatAh_3... P2 > udthl et a1 I= Hl et 2 = H21 et.. 3,", j= H,,, et Sp, I= H12 et 3,p+1 1= H22 et '" * ±w, j= H'.Ih. et... et ap. _= [=t-' et sp._-+x 1= 1H2-1 et... _ j+,_ 1= 2HL, alors 31 1=Cl et 2 l=C2 et, 1= 'w et P2 l= Cl2 et s2,+1= C2 et * *,.,l, s,,, I= Cl.,P.+, I= c; 2.,,,, I= c'U,, et... et sp._I j= C - et sep._1+ j= C2- et P,..._+ 1_ l= C3pigg_, et 3 P > P,.- + woidth,,_ tel que sp, . = Cl et p.p+ = I= C;' et... p.n+wt, l= Cs.;; Cette définition est complètement en accord avec la définition sémantique donnée précédemment. C'est en fait la dernière partie de la définition qui empêche la transformation de la propriété en une propriété sur les états. En effet, Vsl E S, pour tout chemin (s31, 3,..), 3P,, tel que sp, = C? et Ip.+î j= C' et "... +. 1 Cajg= L * correspond en fait à l'existence obligatoire d'un chemin dans le futur. Il est donc néces- saire de passer par une étape intermédiaire pour prouver ce type de propriétés. On va maintenant composer le modèle initial avec deux fois n moins une machines cor- respondant aux différentes zones du chronogramme. Seule la dernière zone de l'hypothèse ne sera pas compilée. Le modèle résultant possédera alors deux fois n moins un signaux supplémentaires "OKzone" qui sont les valeurs de vérité de chaque zone à chaque in- stant. Soit S' l'espace d'état du nouveau modèle, alors Vs_ E S', pour tout chemin (31,32,....), Chaque fois qu'il existe sp,,... sp._-I Pn-l > P.-2 + wtidth_2... P2 > widthl et que ai 1= OKH1 et sp2+,ui, = OKH, et... et sP._x+,,t_, |= OKH_x alors s1 J= OKc, et s.p,+,id, = OKc, et... et sp._+.,id,_1 j= OKc,_, et 3 Pn > P,,- + width,_- tel que sp.+,,id. j= OKc. Ce qui donne après traduction dans une expression CTL: Soit I' l'ensemble des états initiaux du nouveau modèle, V so E I' $0 l= AG((OKHI A EF(EX"""(OKH, A EF(EX'"(OK,))... A EF(EX-^(OKH_,)))._ (OKcóA AX'àvd2(AG(OKH, A EF(EX"t (OKH,... A EF(EXAm'(OK._)))) : (OKc2 A A... AX' "(AF(OKc))))))))) Dans cette section nous avons fait un premier pas dans la présentation des classes de propriétés que l'on peut prouver grâce au couplage algorithme de compilation/Model Checker. Ce premier pas est intéressant car il permet d'entrouvrir la possibilité de prouver des propriétés sur des chemins tout en gardant l'efficacité des algorithmes des Model Checkers. Ici le problème demeure lorsque les zones dynamiques possèdent des contraintes. En effet, dans ce cas là, même avec l'apport de l'algorithme de compilation pour les zones statiques, il semble nécessaire d'utiliser la pleine puissance des formules de CTL* sur les chemins. On peut aussi imaginer une utilisation commune de la logique temporelle et des chronogrammes. Les chronogrammes permettant de spécifier des blocks, ce pour quoi ils sont très ergonomiques. Ces blocks étant liés et quantifiés par des formules de logique temporelle. 4.3 Le générateur de code SIGNAL 4.3.1 La génération commune SIGNAL Dans cette section nous allons développer le code SIGNAL commun aux deux types d'utilisation des chronogrammes: la spécification et la vérification d'un système. Pour la sous-classe des propriétés que nous traduisons en SIGNAL, ce code commun est très majoritaire. En effet, l'algorithme de compilation en SIGNAL des chronogrammes dits statiques (car ne possédant que des zones statiques), suit de très près la structure abstraite du langage CHLOE. Nous allons créer pour la plupart des noeuds de l'arbre abstrait un pro- cessus SIGNAL. Puis nous instancierons, et composerons l'ensemble de ces processus pour calculer le processus résultant de la propriété. Pour le moment, l'algorithme de compilation n'a été réalisé et programmé que pour cette sous dcasse de chronogrammes. Mais, nous pouvons penser, sans pour l'instant en avoir fait la preuve, qu'il existe une traduction en SIGNAL de tous les chronogrammes définissant une propriété de sûreté. Cependant, les chronogrammes exprimant des propriétés de vivacité (des récurrences, des obligations, et les garanties) (dcf chap 2.1), ne pourront être compilés en SIGNAL que pour une utilisation de validation dans le cadre d'une simulation. Ici nous n'apporterons pas la preuve de cette affirmation, mais elle s'appuie sur des intuitions très fortes que nous allons présenter. Pour résumer rapidement, on peut dire qu'en SIGNAL on ne peut spécifier que des sys- tèmes vivaces. Les équations que l'on écrit pour spécifier un système ne peuvent définir ni un système générateur d'événements ni une contrainte imposant l'arrivée d'un événement. Les contraintes définies en SIGNAL s'imposent à l'environnement du système spécifié pour le cas o cet environnement se manifeste, elles n'impose pas à l'environnement de se manifester. Ceci est caractéristique des propriétés de sûreté. Concrètement, on poura spécifier en SIGNAL des contraintes sur des événements de- vant occurer, avant, ou simultanément avec un événement hypothétique. C'est le type de contrainte que l'on définit par des chronogrammes dont l'événement spécifié devant s'instancier le plus tard l'est dans la scène hypothèse du chronogramme. Nous conjec- turons que ceci est une condition nécessaire et suffisante pour que le chronogramme soit traduisible en SIGNAL. Notons que cette condition se teste au niveau de l'arbre syntax- ique assurant à l'utilisateur de CHLOE que le chronogramme qu'il est en train de saisir sera bien compilable en SIGNAL. Dans le cadre d'une utilisation de CHLOE pour la validation de modèles à l'aide de simulateur, tous les chronogrammes doivent être traduisibles en SIGNAL. En effet, le propre de la simulation est de faire s'exécuter le modèle à valider dans un environnement qui l'active. De cet façon le problème de la non vivacité intrinsèque des modèles définie en SIGNAL disparait. Un chronogramme spécifiant qu'après l'occurrence d'un événement A, un événement B doit arriver, se compilerait en SIGNAL, pour la validation par simulation, en un système qui garde en mémoire des occurrences de A et B ainsi que l'ordre de ces occurrences et qui lève un drapeau chaque fois qu'une occurrence de A n'a pas été encore suivie d'une occurrence de B. La simulation finie, il suffit de s'assurer que le drapeau est baissé. L'algorithme de compilation en SIGNAL que nous allons vous présenter ici, ne concerne que les chronogrammes ne possédant qu'une zone statique (StaBasArea). L'extension aux chronogrammes ne possédant que des zones statiques ne pose pas de problème car: Proposition 4.2 Tout chronogramme ne possédant que des zones statiques peut se réécrire dans un chronogramme n'ayant qu'une seule zone statique. Preuve Il suffit de concaténer les listes d'intervalles de chaque ligne en ayant pris soin de recalculer les bornes de chaque intervalle non pas par rapport au début de la zone mais par rapport au début de la scène. La nouvelle largeur du chronogramme sera égale à la somme des largeurs de toutes les zones.0 Dans la compilation en SIGNAL, le problème principal est en fait d'avoir un algo- rithme général dans le cas de chronogramme possédant une suite de zones dynamiques (DynBasalrea) et statiques (StaBasirea). Cela est essentiellement dû à la combinaison des retards dans des zones de différents types, car ces retards ne sont alors pas interprétés de la même façon. Nous n'allons pas pour le moment aborder ce problème. Nous allons développer les différentes étapes de cet algorithme de manière ascendante, c'est-à-dire en remontant la structure abstraite des chronogrammes des intervalles jusqu'à la scène. C'est à partir de là et donc seulement au niveau de la propriété que les générations de code pour la vérification et pour la spécification divergeront et nous verrons, dans un deuxième temps, de quelle manière. Les intervalles Nous commençons la description du SIGNAL qui spécifiera les noeuds les plus bas de l'arbre, c'est-à-dire les intervalles. Si on possède un langage de spécification générique qui accepte le paramétrage des processus, c'est le cas de SIGNAL et aussi de VHDL, on pourra alors avoir une seule machine par statut qui sera donc paramétrée par la longueur de l'intervalle. Sinon (c'est le cas dans SVHDL), on devra générer une machine différente pour chaque statut et chaque longueur d'intervalle. La généricité de SIGNAL, due en partie à la possibilité de paramétrisation des processus ainsi qu'à l'utilisation des MOTIFS, permet donc d'avoir un code fixe pour l'ensemble des statuts. En effet, pour chaque type d'intervalle (HIGH, LOW, RISING,...), la paramétri- sation des processus en fonction de la longueur de l'intervalle et de la borne inférieure de celui-ci, et l'utilisation de MOTIF entrainant la manipulation des signaux dans des fenêtres variables, permettent d'utiliser le même code pour l'ensemble des intervalles de même type. On instanciera, pour chaque intervalle, les paramètres et l'interface de ces processus lors de la génération de la ligne. Presque tous les processus qui définissent les différents statuts ont la même interface, seul le processus spécifiant les intervalles de type VAL-SYMB possède un paramètre sup- plémentaire qui correspond à un signal booléen stable tout au long du processus, et dont le nom sera le symbole donné à cette valeur. L'interface des processus se compose donc de: * Deux paramètres. - B.INF: Ce paramètre est un entier définissant la borne inférieure de l'intervalle par rapport à la fenêtre d'observation des signaux. Il est nécessaire de recal- culer les différentes bornes des intervalles par rapport au dernier événement observable du chronogramme qui correspond dans ce cas là, à la dernière péri- ode de l'horloge. Ceci est réalisé grâce au champ vidth des StaSynArea qui définit la largeur de chaque zone, et donc le nombre de périodes d'horloge qui se sont écoulées depuis le début de la zone. On a donc pour un intervalle Intervalle donné et dans le cas d'un chronogramme ne possédant qu'une zone statique: BlNFIntervalle = iidth Intervalle.location.upperbound (voir section 2.2.2) - LONG: Ce paramètre est la longueur de l'intervalle, c'est-à-dire le nombre d'unités de temps écoulées durant l'intervalle. Cette longueur dans ce type de chronogrammes est statiquement définie et sa valeur est égale à la différence entre la borne supérieure de l'intervalle et sa borne inférieure. LONG = Intervalle.location. upperbound - Intervalle.location.lowerbound * Une entrée: "ID.SIG" est un signal booléen qui sera instancié à l'appel du processus par le nom du signal qui est observé ou contraint. * Une sortie: "FLAG.IDSIG" est un signal booléen. Sa valeur est calculée dans le corps du processus, elle sera égale à true si l'intervalle à été reconnu au bon moment, à false sinon. Nous allons, pour chaque statut du langage primitif, donner le processus SIGNAL correspondant. Le schéma de génération du code suit la classification des statuts en deux classes: la classe des BStableVal et la classe des BEvent. Les statuts stables. Pour les statuts stables les processus sont composés de cinq par- ties: 1. L'interface dont on a déjà parlé. 2. La vectorisation du signal observé par rapport aux paramètres donnés de l'intervalle (LONG, BINF), [VECSTATUT:= ID-SIG $ BINF window LONG 3. Le parcours de tous les éléments du vecteur et affectation d'un signal interne qui est aussi un vecteur et qui donne la valeur de vérité de la contrainte. Par exemple pour le statut Low, tous les éléments du vecteur VECSTATUT doivent porter la valeur O. 4. Affectation du signal de sortie à la dernière valeur calculée. 5. Initialisation des signaux internes. Pour exemple, nous donnerons les processus correspondant aux intervalles de statuts STABLE et HIGH: 1. je statut HIGH: process INTUN = (integer BINF; # Debut de l'intervalle integer LONG) # Longueur de l'intervalle {? logical ID-SIG # L'entree est le nom du signal ! logical FLAG.IDSIG # la sortie est un signal qui dit si ID-SIG } # porte la valeur "true" durant l'intervalle (I VECIDSIG:= ID-SIG $ BINF window LONG # Vectorisation du signal IDSIG [ SIGTRUE:= true array boucle to LONG of # Verification de la stabilite du signal SIGIHAUT:= SIG-IAUT and VECIDSIG with SIG.HAUT[O]:SIGTRUE, VEC.ID.SIG end FLAGIDSIG:= SIG.HAUT[LONG] # Valeur de sortie du processus I) where # Initialisation des signaux internes logical SIGTRUE; [ LONG]logical SIG-HAUT init[ { to LONG}: true]; [ LONG]logical VECID.SIG init[ { to LONG}: true] end; 2. Le statut STABLE: process INTSTAB = (integer BINF; integer LONG) {? logical ID.SIG ! logical FLAGID.SIG } (IVECIDSIG:= ID-SIG $ B-INF window LONG SIGTRUE:= true jarray boucle to LONG of SIGSTAB:= SIG.STAB and (VECIDSIG[boucle- 1] VECIDSIG[boucle]) with SIGSTAB[O]:SIGTRUE, VECIDSIG[O]:SIGTRUE end FLAGIDSIG:= not SIGSTAB[LONG] I) where logical SIGTRUE; [ LONG]logical SIG5STAB init[ { to LONG}: true]; [LONG]logical VECID init[ { to LONG}: true] end; Les statuts événements. Les processus correspondant aux statuts BEvent sont com- posés d'une partie supplémentaire: 1. L'interface. 2. La vectorisation du signal observé par rapport aux paramètres donnés de l'intervalle (LONG, BINF). IVECIDSIG:= IDSIG $ B.INF window LONG 3. Parcours de tous les éléments du vecteur pour localiser la première transition du type désiré. Les éléments de ce nouveau vecteur que nous appellerons FIRST, portent la valeur false dès que cette transition apparaît. 4. Étude au fur et à mesure de ce nouveau vecteur pour savoir si cette transi- tion apparaît plus d'une fois. Les éléments de ce nouveau vecteur que nous appellerons FIRST, portent la valeur false dès que cette transition apparaît pour la deuxième fois. Dans son calcul, il a besoin des valeurs calculées par le vecteur FIRST. 5. Affectation du signal de sortie. Ce signal porte la valeur true s'il n'y a eu qu'une et une seule transition du type désiré durant tout l'intervalle. Pour ce calcul, il suffit d'utiliser la valeur du dernier élément de chaque vecteur FIRST et SECOND. 6. Initialisation des signaux internes. Pour exemple, nous donnerons les processus correspondant aux intervalles de statuts RISING et FALLING: 1. Le statut RISING: process INTRIS = ( integer B.INF, LONG) {? logical ID-SIG ! logical RISING} (j VECID.SIG:= ID.SIG $ BINF window LONG [ SIGTRUE:= true array boucle to LONG of FIRST[boucle]:= FIRST[boucle-1] and (not VECID-SIG[boucle] or VECTID. SIG[boucle-1]) SECOND[boudcle]:= FIRST[boucle] or (SECOND[boucle-l] and (not VEC.IDSIG[boucle] or VECTID.SIG[boucle-1])) with FIRST[0]:SIGTRUE, SECOND[0]:SIGTRUE, VECIDSIG end I RISING:=SECOND[LONG] and not FIRST[LONG] I) where logical SIGTRUE; [LONG]logical FIRST init[{ to LONG}:true]; [LONG]logical SECOND init[{ to LONG}:true] [LONG]logical VECID.SIG init[{ to LONG}:true] end; 2. Le statut FALLING: process INTFALL = ( integer BINF, LONG) {? logical ID.SIG ! logical FALLING} (I VECID.SIG:= ID-SIG S B.INF window LONG [ SIGTRUE:= true array boucle to LONG of FIRST[boucle]:= FIRST[boucle-1] and (VECIDSIG[boucle] or not VECT.IDSIG[boucle-1]) SECOND[boucle]:= FIRST[boucle] or (SECOND[boucle- 1] and (VECID SIG[boudcle] or not VECTIDSIG[boucle-11])) with FIRST[0]:SIGTRUE, SECOND[0]:SIGTRUE, VEC end FALLING:=SECOND[LONG] and not FIRST[LONG] I) where logical SIGTRUE; [LONG]logical FIRST init[{ to LONG}:true]; [LONG]logical SECOND init[{ to LONG}:true] [LONG]logical VECIDSIG init[{ to LONG}:true] end; Les lignes Si on possède un langage de spécification générique qui accepte le paramétrage des pro- cessus (c'est le cas dans VHDL), on pourra alors avoir une seule machine par statut qui sera donc paramétrée par la longueur de l'intervalle. Sinon (c'est le cas dans SVHDL), on devra générer une machine différente pour chaque statut et chaque longueur d'intervalle. Dans le cas des lignes, la généricité de SIGNAL n'est pas suffisante. Il est donc nécessaire de créer un processus pour chaque ligne. On donnera comme nom à ce processus le type de SaaicScne auquel la ligne appartient (hypothèse ou conclusion), suivi du nom du signal observé, suivi de la place de la ligne dans la liste pour différencier les processus portant sur deux lignes définissant des contraintes sur le même signal. Soit LIGNE une ligne appartenant à une BasicScene. Elle est composée d'un identifi- cateur ident donnant le nom du signal observé, et d'une liste d'intervalles Intl, Int2, Int3, Int4,...., qui définissent le comportement souhaité du signal à travers le temps. La contrainte engendrée par une ligne est égale au 'et logique" des contraintes engendrées par chaque intervalle. L'interface du processus pour une ligne est composée d'une entrée correspondant à l'ident de la ligne et d'une sortie qui est un signal booléen portant, à chaque instant, la valeur true si la ligne entière a été reconnue, et sinon la valeur false. Le corps du processus est composé de l'appel pour chaque intervalle, du processus correspondant. Chacun d'entre eux va générer un signal de sortie, et c'est le 'and' de ces signaux qui correspond au signal de sortie du processus de la ligne. L'instanciation de l'interface et des différents paramètres des processus est réalisée grâce aux différents champs de l'intervalle, de la ligne, mais aussi de la StafBasArea en- globante. 1. Le champ status de l'intervalle permettra d'instancier le bon processus. 2. Les valeurs des champs upperbound et lowerbound du champ location de l'intervalle permettront d'instancier le paramètre LONG. 3. La valeur du champs width de la StaBasArea et celle du champ locatioi&upperbound de l'intervalle permettront d'instancier le paramètre B.INF. 4. Le champ ident de la ligne sera le signal d'entrée du processus. 5. En ce qui concerne le signal de sortie du processus, ce sera un signal booléen, dont le nom sera défini en fonction des informations précédentes. Exemple:Soit la troisième ligne de la liste des lignes de la StaBasàrea dont la largeur est de neuf unités de temps. Cette ligne porte sur le signal 'SIG_3N et possède quatre intervalles. Intervalle 1:status = FALLING Intervalle 2:status = Low location.lowerbound = 0 locationloverbound = 3 location.upperbound = 3 locationu upperbound = 4 Intervalle 3:status = HIGH Intervalle 4:status = STABLE location.lowerbound = 4 locationlowerbound = 6 location.upperbound = 6 location. upperbound = 9 -------- c............ e _..eee.eeeee we eeeee.eeee -e- e-eeeeeeeeeeee ce.e..e.e.e... i W lllelllIÀll eellllll eel lele lgllee I e lllllllell.ellÀÀ lille Figure 4.15: Exemple de ligne dans un chronogramme statique On a donc le processus suivant: process LIGNEHYPsig32 = {? Logical sig3 ! Logical Lignei-ypsig3_2} (j IntHypsig3.2_0O3:=INTFALLING(9,3) IntHypsig3.2.3_4:=INT-LOW(6,2) I Int-Hypsig3. 2_4_6:=INT-HIGH(4,1) IntIHyp-sig3_2_6_9:=INTSTABLE(3,3) LigneHypsig3_2:= Int HypJsig3.2_0O3 and IntHypsig3_2_3_4 and Int Hypsig3_2_4_6 and IntHypsig3.2_6_9 I) where logical IntiHypsig3_2_0_3,Intllyp-sig3_2_3_4, IntHypJig3.2_4_6, IntHypsig3%._6.9 end; Les zones statiques La création d'un processus pour les zones statiques suit un schéma très semblable à celui des lignes. En effet, la contrainte générée par une zone statique est égale au "et logique" des contraintes sur chaque ligne. Son interface est donc composée pour signaux d'entrées de l'ensemble des signaux qui apparaissent dans la zone, et pour signal de sortie un signal booléen qui, à chaque instant, porte la valeur true si toutes les lignes ont été reconnues, sinon la valeur false. Le corps du processus est composé de l'appel pour chaque ligne, du processus corre- spondant. Chacun de ces appels va générer un signal de sortie, et c'est le 'and" de ces signaux qui correspond au signal de sortie du processus de la zone. Par exemple, pour la zone définissant l'hypothèse, ayant quatre lignes dont deux, la première et la quatrième, portant sur le signal sigl, la seconde sur le signal sig2 et la troisième sur le signal sig3. On aura alors le processus suivant: process ZONEHYP= {? Logical sigl, sig2, sig3 ! Logical ZoneHyp} (I LigneHyp 1:=LIGNEHYP sigl _(sigl) (I Ligne-Hyp.2:=LIGNE-HYP-sigll(sig2) (I Ligne-Iyp3:=LIGNEHYP- sigll(sig3) (I LigneHyp_4:=LIGNEHYP sigll(sigl) Zone.Hyp:= LigneHyp_1 and LigneHyp.2 and LigneHyp_3 and LigneHyp_4 I) where logical LigneHyp_1, LigneIyp.2, Ligne.Hyp.3, LigneHyp_4 end; Dans le générateur de code SIGNAL, la compilation des noeuds définissant les BasicScene est très simple car il n'existe qu'une seule zone statique. On peut donc imaginer des processus très simples pour les scènes HYP et CONC. process HYP - process CONC = {? logical SETHYP {? logical SETCONC ensemble des signaux de l'hypothèse ensemble des signaux de la conclusion ! logical HYP}! logical CONC} (I HYP=ZONEHYP(SETIYP) (À CONC=ZONECONC(SETCONC) t) j) 4.3.2 SIGNAL pour la spécification par contrainte process PROPCHRONO = {? event CK; logical Réunion de l'ensemble des signaux de l'hypothèse et de la conclusion. } (I synchro {when FLAG, CK} FLAG:= ( CONC {Liste des signaux de conclusion} when HYP {Liste des signaux de l'hypothèses} ) default true I) where L'instruction "synchro {when FLAG, CK}" définit le signal "FLAG" cormme devant porter la valeur true pour chaque cycle de CK. Comme CK est l'horloge maîtresse, la contrainte ainsi définie impose que les signaux impliqués dans le chronogrammne soient conformes au schéma spécifié par le chronogramme à chaque cycle. 4.3.3 SIGNAL pour l'analyse de trace process PROPCHRONO = {? event CK; logical Réunion de l'ensemble des signaux de l'hypothèse et de la conclusion. ! logical FLAG } (J synchro {FLAG, CK} J FLAG:= ( CONC {Liste des signaux de conclusion} when HYP {Liste des signaux de l'hypothèses} ) default true I) where Cette fois l'instruction "synchro {FLAG, CK}" définit une simple égalité entre horloge de 'FLAG" et 'CK". Ceci assure qu'à chaque cycle "FLAG" porte une valeur: true si la propriété est vérifiée; false si la propriété est violée. 4.4 Le générateur de code SVHDL VHDL [ABOR90] est fortement implanté dans le domaine de la description de matériel. Plusieurs environnements de vérification ont été réalisés à partir de ce langage [BPS91] [CLS92]. A partir de VHDL, le langage SVHDL ( SYNCHRONOUS VHDL SUBSET) [DBJ91, D092] a été défini pour lui donner une sémantique synchrone. Des prouveurs ont été développés pour ce langage et il est possible de vérifier si deux programmes SVHDL sont formellement équivalents. Il est aussi possible de vérifier des propriétés CTL sur un programme SVHDL. C'est pourquoi nous avons choisi ce deuxième langage pour la compilation des chronogrammes. La génération de SVHDL qui a été réalisée à partir des chronogrammes de CHLOE suit le schéma qui a été développé dans la section précédante. Tous les différents noeuds de l'arbre sont décompilés de manière à connaître à partir d'une séquence d'entrée si la propriété est vérifiée ou non. On peut alors connaître la valeur de vérité de la propriété à chaque instant soit par simulation soit par preuve. Dans l'annexe A, nous donnerons un exemple de génération de code SVHDL à partir d'un chronogramme statique, puis nous montrerons comment les traces engendrées par les simulateurs et les prouveurs peuvent être interprétées. Chapitre 5 L'é dition Dans ce chapitre, nous allons mettre en valeur la puissance de la structure abstraite du langage de chronogrammrnes CHLOE qui n'est en fait qu'une instance dans le domaine du matériel d'une structure beaucoup plus générale. Nous développerons dans un deuxième temps, la manière dont le contrôle de l'édition est réalisé par le logiciel. Dans la première section de ce chapitre nous présenterons le langage dans sa généralité. Nous introduirons les niveaux d'utilisation de CHLOE, en abordant les différents aspects génériques de la structure. Dans un deuxième temps, nous développerons au travers d'un exemple, ces aspects génériques en montrant comment CHLOE peut servir de base à un générateur de tableur o les règles de gestion seront programmables. Nous montrerons comment CHLOE s'adapte à l'ensemble de ces problèmes, en donnant à un même éditeur la possibilité d'être une superposition de quatre éditeurs: * éditeur de scénarios * éditeur de propriétés * éditeur de liens * éditeur de règles de calcul Nous donnerons dans un troisième temps, la technique d'édition utilisée dans CHLOE en montrant comment à partir de stimuli envoyés sur des objets graphiques concrets on accède aux noeuds de l'arbre syntaxique correspondant. Nous développerons comment tout cela a été concrètement programmé, puis l'ensemble des avantages de cette méthode. 5.1 Survol des aspects génériques Une des utilisations de CHLOE est la spécification de ce que l'on appellera des scénarios qui correspondent, dans le domaine du matériel, aux Scene c'est à dire aux formes admissibles par un jeu de signaux (ce qui a été sa première fonction), ou par exemple dans le domaine commercial, à des bons de commande. Dans les deux cas, ces scénarios doivent en général vérifier des contraintes, qui ont été préalablement spécifiées. De cette façon, les personnes chargées de la saisie de ces scénarios doivent se plier à ces contraintes; par exemple, dans le cas d'un éditeur de bons de commande, les commerciaux doivent respecter des règles dans la rédaction des scénarios, ce qui permettra de ne négocier les commandes qu'à des conditions réalisables par l'entreprise. Cela paraît aller de soi, mais ce n'est pas évident lorsque les différentes étapes de la commande sont complexes et que le vendeur n'a pas à l'esprit l'ensemble des contraintes. Ces contraintes globales à tous les scénarios de même type, seront définies soit sous la forme de ce que nous appelons liens, soit sous la forme de propriétés binaires. Ces propriétés ont une structure binaire du type "hypothèse-conclusion", dont la signi- fication est: 'si l'hypothèse de la propriété se réalise, alors la conclusion doit nécessaire- ment se réaliser'. Prenons encore un exemple commercial, et considérons la propriété suivante: 'si la totalité du montant de la facture n'est pas honoré dans les trente jours, il faut émettre une lettre de rappel" ou bien pour un exemple non causal "Les primes sont distribuées aux commerciaux le lendemain du paiement". Ici le versement de la prime n'est pas seulement lié au paiement de la facture, on peut imaginer qu'il y ait d'autres raisons à ce versement, par exemple les résultats globaux de l'entreprise, en revanche on ne doit jamais verser une prime avant le paiement, à charge du commercial de relancer son client. Le règlement de la facture peut être considéré comme un verrou. Notons que l'implication de la conclusion par l'hypothèse ne se réduit pas à une implication ordinaire dans une logique ordinaire. Ici, s'ajoutent des aspects temporels: l'hypothèse et la con- clusion sont placées dans le temps. Du point de vue de l'aspect concret de la spécification de ces propriétés, l'utilisateur voit simplement l'hypothèse définie comme un bloc dans un scénario, la conclusion définie comme un autre bloc dans un scénario, les deux blocs étant reliés par une flèche. En fait, ces propriétés seront traduites dans un sous-langage du langage de chrono- grammes, que nous appelons le langage primitif. Dans ce langage, les flèches ont été élim- inées et remplacées par un tableau vertical à deux cases, dont la case du haut représente l'hypothèse et la case du bas la conclusion. Les propriétés doivent être compilées. Le ré- sultat de la compilation peut être soit du code exploitable par un prouveur, dans le cadre de la vérification formelle de circuit par exemple, soit du document formel ou fortement codifié, par exemple un contrat commercial. Les liens, eux, permettent d'exprimer des contraintes à effet immédiat: elles sont interprétées. En effet, les liens posent des interdits, des limites à l'évolution d'un scénario. Ce sont des éléments qui contribuent à la paramétrisation de la sémantique au cours d'une session. Par exemple, dans le domaine commercial, on aura ce type de lien: ULe temps qui sépare une commande ferme de la livraison est d'au moins trois jours'. Concrètement, ce sont des liens colorés qui joignent les événements liés. La couleur a un sens: elle spécifie la nature du lien. On donnera une description informelle du langage des chronogrammes au travers d'un exemple tiré du domaine de la gestion. Il montrera l'utilité d'un tel éditeur, et permettra de décrire les principales fonctions de l'éditeur de chronogrammes. 5.2 Une application non hardware de CHLOE Nous allons voir, dans cette section, comment la structure abstraite du langage CHLOE se généralise dans la création et le contrôle de tableaux complexes. Il existe deux niveaux d'utilisation de cette structure qui correspondent à des niveaux hiérarchiques différents: 1. Utilisation initiale qui correspond au réglage des différents paramètres de l'éditeur: (a) Aspects lexicographiques de l'éditeur. i. Les items. Ce sont les noms des signaux (input, ouput,...) pour les chronogrammnes, ou les différentes étapes d'une commande pour un éditeur de bon de commande (NUM CMD, QUANTITÉENUM CMD, TRANS- PORTNUM CMD,...). ii. Les statuts. Les différents statuts d'un intervalle sont HIGH, Low, FALLING... pour les chronogrammes ou pour un éditeur de bon de com- mande des valeurs spécifiques caractérisant les état possibles des items (, "AIR" "MER",...). (b) Aspects sémantiques de l'éditeur. i. Définition de l'échelle de temps. Elle est de l'ordre de la nanoseconde pour les chronogrammes et sera représentée par une succession de créneaux, de l'ordre d'un jour pour un éditeur de bon de commande représenté par le nombre donnant le nombre de jours écoulés depuis le commencement. ii. La définition des propriétés globales à tous les scénarios. Par exemple: dans tout scénario spécifiant les différentes étapes d'une commande, le paiement doit être perçu au maximum 15 jours après la signature du bon. Elles permettent de réaliser un contrôle statique de la conformité de ce qui va se passer dans le scénario. iii. La définition des liens d'éditions globaux à tous les scénarios. Par exemple: dans tout scénario spécifiant les différentes étapes d'une commande, le transport des marchandises ne doit pas dépasser cinq jours. Ils permettent de réaliser un contrôle dynamique de ce qui est explicité dans le scénario. iv. La définition des règles de calcul, par exemple, la prime d'un vendeur est égale à 20% des bénéfices réalisés sur la vente. Figure 5.1: Utilisation initiale de l'éditeur 2. Utilisation terminale: (a) La saisie d'un scénario contrôlé en ligne par les liens et à posteriori par les propriétés données précédemment. (b) La saisie de nouveaux liens déflnis au fur et à mesure de l'édition. duo pt. de bendf mptMme Figure 5.2: Utilisation terminale de l'éditeur En réalité, l'utilisation initiale de l'éditeur constitue un véritable réglage de l'éditeur en vue de son utilisation terminale. Nous allons développer ces deux cas pour le sous-ensemble de la structure abstraite de CHLOE commun à de nombreux types de problèmes tel les chronogrammes bien sûr, mais aussi les tableurs, ou les gestionnaires d'emploi du temps. Ces problèmes, malgré des syntaxes concrètes très différentes, ont dans le cas général des structures abstraites très semblables. Ces structures, en schématisant, sont composées de deux axes princi- paux, en abscisse l'axe du temps qui situe temporellement les événements, et en ordonnée l'ensemble des items observables. En fait la difficulté principale réside dans l'édition puis la vérification de contraintes temporelles (chronologiques, ou chronométriques) entre les événements ou les états sur les différents items. La représentation de ces différentes applications nécessite d'avoir une structure syn- taxique générique pour utiliser CHLOE comme langage graphique de spécification de pro- priétés temporelles avec des compilateurs vers des langages quiexploiteront ces propriétés. L'éditeur, paramétré lexicographiquement (items, statuts,...) et sémantiquement (échelle de temps, propriétés, liens), permet dans un deuxième temps l'édition de scénarios qui sont des exemples de comportements possibles des signaux à travers le temps pour le matériel, ou des contrats commerciaux dans un éditeur de bons de commandes. Cette édition se réalise, comme nous le verrons dans la section suivante, avec un contrôle syn- taxique puissant. 5.2.1 Les éditeurs de CHLOE Pour illustrer les utilisations potentielles de CHLOE, nous prendrons comme exemple le réglage et l'utilisation d'un éditeur de bons de commande pour l'exportation de produit frais (par exemple du saumon) vers le Japon. Il devra gérer et valider les commandes, les livraisons jusqu'au paiement d'une vente de ce type. Nous définirons les différentes étapes utiles pour le réglage de l'éditeur puis nous présenterons une utilisation pratique au niveau des différents services concernés. Cet exemple mettra en valeur les aspects génériques de l'éditeur, car c'est un cas typique o les contraintes temporelles entre les différentes étapes de la commande sont très importantes et réduisent fortement les marges de manceuvre des commerciaux. Nous pourrons noter que dans ce cas là, les aspects chronométriques autant que chronologiques seront pris en compte. Les paramètres Dans un cas comme celui-là, le placement dans le temps des différentes étapes de la com- mande est très important. C'est ce placement qui va contraindre la réalisation d'une cormmande et qui permettra de contrôler sa validité. On remarque donc la nécessité d'une référence temporelle dans l'édition des propriétés ou des scénarios, c'est-à-dire d'une hor- loge qui permettra comme dans les chronogramnmes de cadencer les différents événements, et de spécifier l'ordre temporel dans lequel les différents états apparaissent. Dans chaque application, c'est en fait la fréquence de cette échelle de temps qui change, ainsi que sa syntaxe concrète pour rester proche des différentes habitudes. Nous donnerons dans le tableau suivant, un exemple d'utilisation pour plusieurs fréquences possibles: Nano-seconde: Matériel informatique grâce aux chronogrammes. Micro-seconde: Freinage automatique des métropolitains. Seconde: Feux de circulation. Minute: Tableaux d'affichage des départs et arrivées des trains. Heure: Emploi du temps. Jours: Étapes d'un bon de commandes. Les items et les statuts des intervalles sont eux aussi dédiés à l'application. Il seront pour les chronogrammes des signaux électriques avec des statuts bien particuliers (O, 1, Z, F,..). Dans l'exemple que allons développer, on peut imaginer des item représentant les différentes étapes d'une commande avec des statuts pouvant être booléens dans certains cas, ou des valeurs spécifiques (Exemple: pour un signal spécilant le type de transport, on peut imaginer des statuts "ROUTE", "AIR", "TRAIN", "MER"). Dans l'exemple d'un éditeur pour les bons de commandes, les noms des items seront paramétrés par le numéro de la commande en cours (NUM CMD). Les item qui sont utilisés ici ont en général des statuts très proches des statuts des chronogrammes primitifs. On prendra donc sept items qui, on le verra plus tard, seront utiles dans la description d'une commande. La liste des items n'est pas ici exhaustive. En effet, pour une descrip- tion plus détaillée on peut imaginer décomposer ces différents items en plusieurs sous items. NUM CMD Signal booléen prenant le statut -" le jour o la commande est signée et reprenant le statut "_" le jour o elle est payée. QUANTITÉ Signal prenant comme statut le nombre de kilo de saumon NUM CMD commandés le jour de la signature du bon de commande et reprenant le statut "_" après le paiement et évoluant si livraison incrémentale. TRANSPORT Signal prenant le jour du départ le statut associé au type de NUM CMD transport utilisé, et reprenant le statut "'" après la livraison et changeant de statut lorsque le mode de transport change. LIVRAISON Signal booléen prenant le statut "- le premier jour de la NUM CMD livraison des marchandises et reprenant le statut "2' dès qu'elle est finie. * PAIEMENT Signal booléen prenant le statut "" le jour du paiement des NUM CMD marchandises. Egal à "_" les autres jours. RELANCE Signal booléen prenant le statut "" seulement le jour de l'envoi NUM CMD de la lettre de relance. Egal à "'" les autres jours. BÉNÉFICE Bénéfice brut engendré par la vente, calculé le jour du paiement NUM CMD de la commande. Egal à ""' les autres jours. PRIME Prime du vendeur égale à un pourcentage des bénéfices de la NUM CMD vente. Égal à "'" les autres jours. Pour les statuts des différents items, on utilisera aussi le statut IRRELEVANT (le signal n'est pas observé durant l'intervalle de temps), ainsi que le statut RISING qui fera partie de la classe des statuts Event (le signal passe du statut "': à un statut différent une et une seule fois durant l'intervalle de temps). D'autres statuts de même type (FALLING, EDGE,...) pourront être utilisés dans l'édition d'une commande. Dans certains cas, des valeurs explicites seront données; par exemple pour l'item TRANSPORTNUM CMD les statuts possibles seront "AIR", "MER", "ROUTE", "TRAIN", et "_", i.e., le transport n'a pas encore commencé ou est terminé. Après avoir défini l'ensemble des paramètres de l'éditeur, on va maintenant utiliser la structure du langage primitif des chronogrammrnes pour définir les propriétés qui con- trôleront à posteriori l'ensemble des scénarios valides de l'éditeur, ainsi que des contraintes d'éditions qui seront vérifiées dynamiquement (spécifiées par des liens). Les propriétés binaires Pour illustrer les différentes étapes de cette spécification, nous allons reprendre l'exemple de l'éditeur de commandes de saumon frais pour le Japon, en présentant des exemples de points importants dans la réalisation d'une commande qui doivent toujours être vérifiés. Exemple de propriétés temporelles: 1. Le départ des marchandises se fait entre 2 jours et 5 jours après la signature de la commande. 2. Le paiement de la commande doit être effectué 14 jours près la livraison. 3. En cas de non-paiement, relance 14 jours après la livraison. 4. On ne vend jamais à perte. On extrait ainsi de ce type de commandes de nombreuses propriétés qui devront être vérifiées par toutes les commandes réalisées par cette entreprise pour le Japon. Les propriétés que nous avons données ci-dessus ont des structures très différentes les unes des autres, mais il est très facile de les reformuler en utilisant les différents paramètres précédemment définis, pour qu'elles aient une structure commune du type hypothèse-conclusion. Cette structure binaire est à la base de la définition des propriétés dans le monde des chronogrammes primitifs. Les propriétés sont donc divisées en deux parties: une partie considérée comme l'hypothèse de la propriété et l'autre comme la conclusion. La sémantique intuitive qui lui est donnée est: Si on reconnaît le comportement défini par l'hypothèse alors on doit reconnaître au bon moment le comportement défini par la conclusion. Voici donc la traduction des différentes propriétés dans cette structure: 1. Si la commande est signée, alors la marchandise doit partir entre 2 et 5 jours après (figure 5.3). 2. Si la livraison est réalisée, alors le paiement doit s'effectuer au maximum 14 jours après (figure 5.4). 3. Si la livraison est réalisée et que le paiement n'est pas effectué pendant les 14 jours qui suivent, alors il faut envoyer une lettre de relance (figure 5.5). 4. Le bénéfice d'une vente est toujours supérieur ou égal à O (figure 5. 6). Grâce à cette traduction, il est maintenant facile d'éditer ces propriétés avec un outil graphique très proche de l'environnement existant autour du langage des chronogrammes. On montrera dans les figures suivantes comment elles sont représentées dans une syn- taxe concrète ressemblant à ce qui a été fait pour les chronogrammes primitifs. Dans ce type de problème, l'échelle de temps qui a été choisie est la journée. Les chiffres placés dans la partie réservée à la discrétisation du temps permettent de visualiser les jours passés. La partie supérieure représente l'hypothèse de la propriété et la partie inférieure la conclu- sion. L'ensemble des figures aurait tout aussi bien pu être réalisé dans un chronogramme évoluéi qui permet grâce à l'utilisation de flèches de définir plusieurs propriétés dans un même scénario. Ici, les figures qui sont représentées ne sont pas, comme dans les chapitres précédants, des copies d'écran. Pour ce type de chronogrammes, le logiciel CHLOE aurait demandé quelques aménagements qui n'ont pas encore été programmés. | | || | 13 2 3 4 * *S 7 A ll i Figure 5.3: Propriété 1 Dans cette propriété, nous ouvrons une fenêtre de sept jours. Les deux premiers jours sont utiles pour spécifier le jour de la signature du contrat qui représentera l'hypothèse de la propriété (NUM CMD prend la valeur "- le jour de la signature du bon de com- mande). Les autres serviront à la définition de la conclusion de la propriété, ceci grâce à un intervalle de cinq jours commençant le lendemain de la signature, et ayant le statut RISING. Ce statut spécifie que le signal TRANSPORTNUM CMD est passé de la valeur Low à une valeur différente une et une seule fois durant l'intervalle, ce qui signifie que le transport doit nécessairement commencer une et une seule fois entre le deuxième et le cinquième jour inclus après la signature de la commande. La propriété 2 ressemble à la première. Nous avons besoin ici d'une fenêtre de 16 jours pour visualiser les différentes possibilités d'arrivée du paiement après la livraison. f IDé1 I I I I I I I1 I II I 1 2 3 4 S 6 7 8 9 10 11 12 13 14 1S 16 PAMO !p- CIf) Figure 5.4: Propriété 2 L'hypothèse de la propriété 3 met en jeux deux items: * l'item LIVRAISONNUM CMD pour le jour de la livraison * l'item PAIEMENTNUM CMD pour spécifier le non paiement de la commande pendant les 14 jours qui suivent cette livraison. La conclusion donne alors le jour o il faut envoyer la lettre de relance. Figure 5.5: Propriété 3 La propriété 4 est un peu particulière car il n'y a pas ici d'aspect chronologique. C'est un invariant, c'est pourquoi il n'y a aucune contrainte sur l'hypothèse de la propriété. En I revanche, on voit apparaître dans la conclusion un statut un peu particulier qui est ici une inéquation sur la valeur portée par l'item. _.- __. * __ Figure 5.5: Propriété 3 La propriété 4 est un peu particulière car il n'y a pas ici d'aspect chronologique. C'est un invariant, c'est pourquoi il n'y a aucune contrainte sur l'hypothèse de la propriété. En revanche, on voit apparaître dans la conclusion un statut un peu particulier qui est ici une in/quation sur la valeur portée par l'item. s= cE IRRELEVANT N= CND VAL>---O Figure 5.6: Propriété 4 Les différentes étapes de la commande sont saisies par le vendeur lors de la négociation avec le client des prix et des délais de livraison et de paiement, dans ce que l'on appellera le scénario souhaité de la commande. Les propriétés décrites de cette façon seront alors utilisées pour la validation à posteriori de ce scénario et dans un deuxième temps pour la vérification du bon déroulement de la commande facturation-livraisonpaiement réel. Elles sont câblées dans l'éditeur et ne pourront être modifiées qu'en suivant un pro- tocole particulier. La vérification nécessite alors une compilation de ce scénario et des propriétés. Les liens Nous sommes ici dans une troisième partie du réglage de l'éditeur. Après les différents paramètres lexicographiques, puis les propriétés, il est aussi utile de définir des liens en- tre les bornes des intervalles. Ces liens sont relatifs à l'item, mais aussi au statut de l'intervalle. Les liens donnés au cours de la spécification de l'éditeur seront globaux à tous les scénarios. Il seront donc automatiquement ajoutés à la liste des contraintes des intervalles reconnus comme étant une instance de l'intervalle et de l'item contraint. Ces liens permettront de réaliser dynamiquement un début d'analyse sémantique du scénario en empéc.hant l'utilisateur de base d'éditer des comportements erronés dans un scénario. Par exemple dans l'éditeur de chronogrammes, il est impossible de créer des intervalles ayant un statut de la classe event (EDGE, RISING, FALLING) et de longueur inférieure à deux unités de temps, car cela n'a aucun sens (la transition devant se réaliser strictement à l'intérieur de l'intervalle). Dans ce cas là, on a donc une contrainte sur la distance séparant la borne inférieure de la borne supérieure de tout intervalle ayant un statut faisant partie de la classe des event. Cette contrainte est que la distance séparant la borne inférieure de la borne supérieure de l'intervalle doit être supérieure ou égale à deux. Sur l'exemple de l'éditeur de bons de commande, plusieurs liens peuvent être définis. Par exemple, le transport des marchandises vers le Japon met au minimum deux jours mais ne doit pas dépasser six jours ce qui induit des contraintes sur la date de livraison effective qu'un vendeur peut promettre à son client. Cette contrainte qui est une contrainte d'édition doit empêcher le vendeur, à l'écriture du scénario, de proposer des délais de transport ne vérifiant pas l'une d'entre elles. Elles seront alors spécifiées graphiquement de la manière suivante. Le premier lien spécifie le fait que la longueur minimale d'un intervalle ayant un statut différent de "_" pour l'item TRANSPORTNUM CMD est de 2. Le deuxième donne la contrainte sur la longueur maximale de ce même intervalle: I TUD II!Z 11I 2}TS 11231 415 6 = { > = 2 + =>{ ≤ 6+ TI__R___ _ I TRU R VAL<> b VALo"" Figure 5.7: Spécification de la durée minimale et maximale du transport Les liens sont des contraintes supplémentaires spécifiées grâce au même éditeur que celui qui a permis l'édition des propriétés. Les règles de calcul Enfin pour terminer le réglage de l'éditeur, il est aussi important de donner comme paramètres des règles de calcul qui permettront lors de l'édition de générer automatique- ment et dynamiquement des intervalles en calculant leur statut ainsi que leur placement dans le temps. En voici deux exemples: 1. Le bénéfice brut d'une vente est égal à la valeur payée moins 30 francs par kilo commandé qui correspondent à son prix de revient. Ce bénéfice est calculé le jour du paiement. 2. La prime du vendeur est égale à 20% du bénéfice brut effectué au cours de la commande. Cette prime lui sera versée le lendemain du paiement donc le même jour que le calcul du bénéfice. Ici, nous allons donner la représentation de la première règle sur le calcul du bénéfice brut d'une commande à partir de la quantité (la valeur QT de l'item QUANTITÉENUM CMD) et du prix payé (la valeur symbolique PRIX de l'item PAIEMENT.NUM CMD). LI1LP PRIX P&M VA Ban"ICIC 8 VI 0.2 Figure 5.9: Calcul de la prime Figure 5.8: Calcul du bénéfice On voit dans l'exemple précédent que les règles de calcul sont aussi réalisées à partir du même éditeur. Elles ont la même structure que les propriétés binaires. Les inter- valles utilisés ici comprennent des valeurs symboliques. Ces expressions seront évaluées dynamiquement. Dans le cas du calcul de la prime, cette règle peut servir à un vendeur pour savoir directement quelle sera la prime relative à la commande qu'il vient d'effectuer. Il peut alors jouer sur sa marge pour faire baisser le prix, et faire signer cette commande. Mais elle peut dans un deuxième temps, grâce a une structure commune avec les pro- priétés binaires, être réutilisée, dans un autre service comme propriété pour vérifier par exemple que la prime a bien été versée au bon moment. Tous ces paramètres contribuent à la création d'une session d'édition qui servira con- crètement à plusieurs utilisateurs. Les figures ont été construites en s'inspirant des chronogrammes primitifs. Ces chronogrammes n'ont pas la qualité ergonomique des chronogrammnes évolués. Ces derniers, grâce aux flèches, permettent par exemple de regrouper tous les primitifs proposés dans une seule planche: un seul scénario. 5.2.2 Utilisation terminale: instanciation et contrôle La deuxième utilisation de la syntaxe abstraite correspond à l'utilisation pratique de l'éditeur précédemment spécifié. Au cours de la création d'un scénario, les différents utilisateurs de l'éditeur vont: - ajouter de nouveaux liens pour spécifier des contraintes entre les bornes de plusieurs intervalles, ils seront vérifiés en permanence au cours de l'édition et de la modification des scénarios, ajouter de nouvelles propriétés qui viendront s'ajouter à la liste des propriétés déjà définies et qui seront exploitées après compilation à posteriori. Dans l'exemple du tableur gérant la vente de produits frais, plusieurs commerciaux vont signer des commandes qui seront gérées par les paramètres globaux à tout l'éditeur (syntaxe concrète, propriétés, liens et règles de calcul). Chacun d'entre eux pourra en- suite, suivant ses contraintes personnelles ou celles de son client, ajouter des liens et des properiétés. Dans la figure suivante, nous donnerons l'exemple d'un scénario qui vérifie l'ensemble des propriétés et des liens que nous avons préalablement spécifiés. ! an 1112 3 4 S * * * w 1012 S" 141 "I1l] sF0do v alid AucoursdeladIscussionoaveclei r 1_ __ m- a-10 R Figure 5.10: Exemple de scénario valide Au cours de la discussion, avec le client, d'autres liens d'édition ont été ajoutés. C'est le cas, par exemple ici du lien spécifiant que la livraison devra se faire en une seule journée. Dans le scénario ci-dessus, on a donc un exemple regroupant l'ensemble des items (cmd 10 (NUM CMD), QUANTITÉELcmd_10, TRANSPORTcnd_10, LIVRAI- SONcmd_10, PAIEMENTcmd 10, PRIMEcmd._10) et réalisant une commande d'une tonne de saumon dont le transport commence trois jours après la signature du bon, (donc avant les 5 jours limites) et dure cinq jours dont deux par avion et trois par route ce qui vérifie les liens sur les contraintes de transport. La livraison complète de la marchandise sera donc réalisée huit jours après la commande, et le paiement des 50KF pour la tonne de saumon, six jours après cette livraison (donc bien avant les 15 jours limites). Le bénéfice réalisé grâce à cette vente est de 20KF donc supérieur à 0 et la prime du vendeur ayant réalisé cette vente sera alors de 4KF (20 000 * 0.2). Ce scénario peut donc bien être validé par le vendeur, il suffira maintenant au service de gestion de contrôler que ce scénario est bien réalisé par le client et les différents ser- vices concernés en vérifiant que toutes les propriétés valides dans le scénario prévu par le vendeur sont toujours valides dans le scénario réel. Il en est de même pour la propriété 3 "si la livraison est réalisée et que le paiement n'est pas effectué pendant les 14 jours qui suivent, alors il faut envoyer une lettre de relance (figure 5.5' qui n'intervenait pas du point de vue du vendeur mais qui doit être prise en compte dans la gestion du suivi des commandes. De même, un sous-ensemble de ce scénario peut servir de base à l'édition d'un bon de commande qui lui, une fois signé, aura valeur de contrat de vente. Dans l'exemple que nous avons présenté ici, la paramétrisation de l'éditeur a été réal- isée pour les exportations vers le Japon, mais les mêmes paramètres lexicographiques seront encore valables pour tous les éditeurs devant gérer les commandes dans n'importe quel pays (le NUM CMD, le transport, la quantité commandée.....). Il en est de même pour certaines propriétés, par exemple la propriété 1 sur le début du transport, ou la propriété 4 sur l'interdiction de vendre à perte. En revanche d'autres propriétés devront être adaptées aux politiques commerciales ou à l'éloignement de chaque pays visé (par exemple les contraintes de paiement, ou les liens gérant le transport seront spécifiques au pays). Nous avons vu deux utilisations possibles de la structure abstraite de CHLOE (les chronogrammes, les gestionnaires de commandes), mais c'est en fait tous les problèmes qui induisent des protocoles avec une dimension temporelle (protocole dans le matériel ou protocole gérant une commande) qui pourront ainsi être spécifiés en utilisant cette structure abstraite. 5.3 Le contrôle syntaxique de l'édition 5.3.1 La technique d'édition utilisée dans CHLOE L'éditeur de chronogrammes, qui a été réalisé à partir de la grammaire du langage, est conçu de façon à contrôler automatiquement la création d'un arbre syntaxique valide de chronogrammes. L'éditeur n'autorise au cours d'une session, que la création de préfixes d'arbres valides, et réalise donc un contrôle syntaxique avec un coût minimum. Les dif- férents objets qui composent l'écran se comportent comme des contrôleurs syntaxiques qui fitrent directement parmi les actions réalisées celles qui ont pour effet de métamorphoser le préfixe d'arbre syntaxique valide en un autre préfixe d'arbre syntaxique valide. En fait, chaque entité de la syntaxe concrète est vue comme un objet auquel est associé la liste des méthodes correspondantes aux différentes actions que l'utilisateur envoie à l'aide de la souris ou du clavier. Tous les objets graphiques générés par CHLOE sont excitables par la souris, mais les stimuli sont interprétés différemment suivant le type de l'objet que l'on stimule. C'est là que se situe la première étape du contrôle, car pour chaque objet graphique deux filtrages sont réalisés sur les différents stimuli possibles. Tout d'abord, on va éliminer tous les stimuli qui ne doivent avoir aucun effet sur l'objet concerné, puis pour les autres on va envoyer un message qui sera interprété suivant l'objet sur lequel on est en train de pointer et le type de stimuli que l'utilisateur a envoyé. Dans la figure 1.11, représentant une configuration de l'éditeur pour le hardware, nous donnons quelques exemples d'excitations possibles: CR.: affecati oJtkq... BM I: inserskn d'un clock Btn2:mionducdoat... BSn: Insetion d'un signa 8JI: modlioadSY des bomnes Bin: &Lrsbn du signal.... Key S: dwçgema de stata S W: destntcIon de lIntewvae Sft Btn: selecdon d'un ktervalle.... Figure 5.11: Exemples d'action sur un chronogramme de CHLOE La deuxième étape du contrôle, et de loin la plus importante, se réalise dans l'arbre syntaxique. En fait, à chaque type d'entité graphique correspond un type de noeuds dans la grammaire abstraite qui possède aussi sa table de méthodes valides. Cette table permet d'interpréter les différentes actions que l'utilisateur peut réaliser sur l'objet graphique en appliquant sur le noeud concerné de l'arbre syntaxique la méthode correspondant à l'action. Cette interprétation peut être réalisée grâce à une fonction qui pour chaque objet graphique du chronogramme fait correspondre un noeud unique dans l'arbre syntaxique du chronogramme. Soit NOEUDABS l'ensemble des noeuds de l'arbre syntaxique abstrait, soit NOEUDCONC l'ensemble des objets graphiques du chronogramme, alors il existe une fonction f: NOEUDCONC - NOEUDABS La fonction f est une injection si l'on reste dans le langage primitif des chronogrammes, mais n'est plus injective dans les chronogrammes évolués (i.e. les scénarios). En effet, les objets graphiques représentant les intervalles sont les antécédents de plusieurs noeuds, dès lors qu'ils appartiennent à plusieurs propriétés. Cette fonction n'est pas non plus surjective, car il existe dans la grammaire des noeuds qui n'ont aucun pendant dans la syntaxe concrète car ils ne doivent et ne peuvent pas être modifiés à partir de l'écran- clavier. Ces noeuds seront créés ou supprimés grâce à des actions qui font intervenir d'autres noeuds abstraits et concrets. C'est le cas par exemple du noeud Bound ou du noeud Status qui sont les fils ou petit- fils du noeud Interval et qui sont créés automatiquement après la création de l'intervalle et qui ne sont manipulés qu'à travers l'intervalle. Cette fonction permet pour chaque stimulus valide envoyé à partir d'un objet graphique concret d'accéder directement au noeud de l'arbre syntaxique abstrait corre- spondant et de l'interpréter en modifiant l'arbre. Pour chaque stimulus, un message est envoyé à l'arbre syntaxique. Ce message est un couple composé par l'identificateur de l'objet graphique et par le type d'action que l'on veut exécuter sur cet objet. Apres chaque action, l'arbre est nmis à jour et un nouveau préfixe de chronogramme est créé. Dans un troisième temps, il est nécessaire après chaque modification de l'arbre de remet- tre à jour l'image graphique. Le préfixe de l'arbre syntaxique du chronogramme en cours de saisie caractérise toujours l'état de l'éditeur. Par exemple, supposons que l'action de taper sur la lettre 'J, alors que le curseur de la souris pointe sur un intervalle corresponde au changement de statut d'un intervalle dans la couleur 'jaune". Cette action a été prévue dans la liste des actions et des méthodes associées à un intervalle. On a alors le mécanisme suivant: S STA'11S Figure 5.12: Du concret vers l'abstrait Si l'objet graphique est ainsi excité, on accède alors au noeud de l'arbre syntaxique correspondant à l'intervalle et on applique le changement de valeur du champ Statu. à UJAUNE". Figure 5.13: De l'abstrait vers le concret Ce changement de statut étant réalisé dans l'arbre syntaxique, il est nécessaire de remettre à jour l'écran en accédant cette fois à l'image graphique correspondant à l'intervalle et changeant par exemple la couleur du fond de l'intervalle. Cette mise à jour peut aussi se faire en détruisant l'image graphique de l'intervalle, puis en décompi- lant le nouveau sous-arbre. En fait, toutes les actions des éditeurs et des compilateurs sont entièrement contrôlées par la grammaire. Nous l'avons vu dans le chapitre précédant dans le cas des générateurs de code, nous allons montrer dans la section suivante comment l'éditeur l'est aussi'en présentant comment il a été programme. SAUVEGARDE sYNrAXIQUE PECOMPILATION| Co / DONNEES | LECOGRAPOMOUE | Figure 5.14: Rôle de la grammaire dans la structure fonctionnelle de CHLOE 5.3.2 Programmation de CHLOE Nous allons montrer comment, en alliant la programmation orientée objet à l'utilisation des générateurs d'interfaces graphiques, il est possible d'avoir une très grande flexibilité dans le développement d'éditeur pour de tels langages, tout en créant en temps réel une image écran équivalente à l'arbre abstrait représenté en mémoire. Nous allons décrire ici les différentes étapes d'une méthode qui peut êtreutilisée dans le développement d'un éditeur de langages graphiques. La définition d'un tel éditeur est divisée en trois parties: 1. Définition de la syntaxe abstraite. 2. Definition de la syntaxe concrète. 3. Définition des actions d'édition. La définition de la sémantique n'est pas abordé ici. Dans le cas du langage de chronogramme CHLOE, cette définition a été donnée dans le chapitre 3 et de façon moins formelle au travers des générateurs de code. Dans le cas d'un langage textuel, les définitions de la syntaxe concrète et des actions d'édition ne posent pas de problème, en revanche, cela devient beaucoup plus délicat pour les langages graphiques. En effet, par exemple, l'insertion d'une ligne dans un pro- gramme est entièrement gérée par l'éditeur de texte, alors que l'insertion d'une ligne (ou un signal) dans un chronogramme entraine une mise à jour très importante de nombreux objets graphiques. Il en est de même pour toutes les actions d'édition standard dans les éditeurs de texte telle que l'insertion d'un mot, la destruction d'un mot ou d'une lettre Le problème se pose aussi dans la définition des objets de base de la syntaxe concrète. Dans un langage textuel, ces objets sont des chaînes de caractères (if, then, while...), dans les langages graphiques, ce sont des objets de plus haut niveau, avec de nombreux paramètres. En fait ces actions d'édition représentent dans ce cas la grande majorité du développement. Dans le cas d'un éditeur pour un langage graphique, la définition de la syntaxe ab- straite du langage se fait en créant, pour chaque lettre de l'alphabet non terminal de la grammaire, une classe qui possède comme champ les objets correspondant à la deuxième partie de la règle. Dans chacune de ces classes, les différentes méthodes correspondent aux actions d'édition possibles sur l'ensemble des noeuds de ce type. Tout cela a été pro- grammé en utilisant le langage de programmation orientée objets EIFFEL [Mey92]. Certaines de ces classes correspondent à des objets graphiques. Sur ce type de classe, il est nécessaire de posséder des attributs et des méthodes supplémentaires qui permettront de dialoguer avec l'image graphique du noeud. C'est le rôle d'une classe de plus haut niveau dont toutes les classes graphiques hériteront, et qui est appelée "GRAPHIC.NODE". Cette classe possède une fonction d'affichage qui est en fait une fonction de création d'image graphique. Les arguments de cette fonction sont en premier lieu le type d'objets à dessiner (par exemple intervalle, ligne ou scène), puis l'objet graphique dans lequel il va être dessiné. Cet objet est l'image de son plus proche ascendant qui est aussi un noeud graphique. Souvent, c'est en fait l'image du père du noeud. Ce paramètre est très important car il est indispensable de garder dans la représentation graphique la hiérarchie qui existe dans l'arbre abstrait. Les autres paramètres sont relatifs au type d'objets à afficher, ils permettront de le dessiner conformément à l'arbre syntaxique. Cette fonction va créer un nouvel objet à l'écran, cet objet est annoté par un identi- ficateur. Pour tout objet graphique créé, l'identificateur sera différent. Il sera récupéré par l'objet abstrait grâce à un attribut supplémentaire appelé 'identwidget'. Ce champ permettra de connaître à tout moment le représentant dans la syntaxe concrète d'un noeud de l'arbre. Cela permettra de le manipuler en le détruisant ou en modifiant certains de ces champs, à partir de l'arbre abstrait. C'est le même identificateur qui servira à connaître quel nceud de l'arbre correspond à la partie de l'écran stimulée. Par exemple, les intervalles possèdent une image graphique dans la syntaxe concrète. La position et l'aspect de chacun d'entre eux sont calculés en fonction des feuilles des dif- férents fils (la position grâce aux feuilles du champ de type Segment, et l'aspect intérieur grâce à son Status). Ces différentes feuilles constitueront certains des paramètres de la fonction d'affichage. Sur cet objet, plusieurs actions sont possibles, par exemple la génération, la destruction, la modification de la taille de l'intervalle, le changement de son statut... Toutes ses actions entraînent la création ou la modification des noeuds de l'arbre correspondant à l'intervalle et à ses fils, il faut donc mettre à jour les objets concrets. Dans le cas d'une modification de feuilles d'un nceud, cela peut être fait de deux façons, soit en détruisant l'image graphique correspondant à l'ancien noeud puis en créant une nouvelle image relative au nouvel objet, soit en modifiant directement l'image graphique. Cette deuxième méthode a été adoptée dans le cadre de l'éditeur de chronograrnmmes, il est alors nécessaire d'associer à chaque fonction de modification du noeud abstrait, une fonction de modification de l'image graphique. Elle permet dans de nombreux cas des gains de temps considérables et surtout la réduction de la mémoire utilisée ce qui est le principal problème des applications graphiques. Nous avons donc présenté la manière dont nous avons défini la syntaxe abstraite, les actions d'édition et surtout le moyen de communiquer entre la syntaxe abstraite et la syntaxe concrète. Nous allons présenter dans un deuxième temps, comment cette syntaxe concrète associée à chaque type a été définie et comment il est possible à partir d'une image graphique de connaître son représentant dans l'arbre abstrait. La représentation graphique des différentes classes a été réalisée à l'aide d'un généra- teur d'interfaces graphiques appelé EGERIA [Bou92]. Cet outil permet de créer intérac- tivement des objets graphiques sous XWINDow/MoTIF [You90], puis d'en modifier les paramètres (couleur, position, actions sur ces objets....) dans un environnement multi- fenêtres très convivial. Il a été réalisé en premier lieu pour définir des interfaces utilisateurs ergonomiques pour d'autres outils. Elles sont en général prédéfinies, c'est à dire que dès la conception, on connaît exactement l'allure de l'ensemble des fenêtres utiles à la définition de chaque interface. Ce sont en général, des fenêtres possédant des parties textuelles, des menus, et des boutons qui, dès qu'ils sont activés, font apparaître d'autres fenêtres ou d'autres boutons etc... Il suffit alors de les représenter une à une, et une fois pour toutes grâce à l'éditeur d'EGERilA, et de programmer les différentes fonctions relatives à chaque action sur ces fenêtres. Elles sont alors sauvegardées sur fichiers dans un langage appelé WOOL. Au chargement de ce fichier, l'image écran sera alors fidèlement restituée grâce à l'interpréteur WOOL d'EGERIA. Dans le cas de CHLOE, nous n'avons pas utilisé EGERIA de cette manière qui est en fait la plus commune. En effet, dans la définition d'un langage graphique, l'ensemble des mots valides est en général infini ou du moins très grand. Par exemple, dans le cas de l'éditeur de chronogrammes CHLOE, on ne peut pas limiter le nombre ou la longueur des intervalles ou le nombre de lignes. On ne peut donc pas pré-dessiner l'ensemble des chronogrammes possibles, il est donc nécessaire d'utiliser l'aspect dynamique de ce type d'outil. En effet, la création d'un nouvel objet, ne se fait plus par chargement d'un fichier, mais par appel d'une fonction correctement paramétrée. Il y aura alors une fonction pour chaque classe d'objets graphiques. Cette fonction n'est pas automatiquement générée comme l'est le fichier associé à une fenêtre d'interface. En revanche, on peut récupérer ce fichier, puis le modifier en rendant certains de ces paramètres variables. Toutes les fonctions de création seront en particulier paramétrées par l'identificateur du père de l'objet graphique qui est toujours connu dynamiquement. Seule la fonction de création de la racine de l'arbre ne possède pas ce paramètre. Les autres paramètres seront en général relatifs aux différentes feuilles des sous arbres (pour les intervalles, ce seront les bornes et le statut), ou à la position de l'objet nouvellement créé dans une liste d'objets de même type (pour les lignes). L'intérêt d'outils tel EGERIA devient moindre mais il reste encore largement bénéfique pour le développeur. On peut alors regretter que la possibilité de spécifier des paramètres libres dans les objets graphiques puis de générer une fonction paramétrée par des vari- ables ainsi spécifiées ne soit pas encore prévu, mais il n'y a pas de problème lié à ce type d'utilisation des générateurs d'interfaces graphiques et si le besoin s'en fait ressentir cela semble être réalisable. A chaque nouvel objet graphique créé lors d'une session, EGERIA génère automa- tique un identificateur et cet identificateur va servir de lien entre les deux représenta- tions (abstraite et concrète) du même chronogramme. EGERIA permet aussi de filtrer et d'interpréter les stimuli que la souris ou le clavier envoient sur les différents objets graphiques. On peut donc envoyer un message correspondant à chaque stimulus à l'arbre abstrait. Ce message est composé de l'identificateur de l'objet graphique stimulé, du type d'action que l'on veut exécuter dessus, suivi des arguments nécessaires au déroulement de cette action. On va donc aller chercher dans une table appelée 'env" le représentant dans l'arbre abstrait associé à l'identificateur. Ce représentant existe nécessairement, car par construction, à tout objet graphique excitable correspond un et un seul nceud de l'arbre apte à interpréter le message. C'est donc uniquement au niveau de l'arbre syntaxique que tous les messages sont analysés et exécutés. Prenons par exemple l'ensemble des actions possibles lorsque le curseur de la souris est positionné sur un intervalle quelconque: : Modification des bornes. Shift : Destruction de l'intervalle. : Modification du champ statuae à IRRELEVANT. : Modification du champ statua à HIGH. : Modification du champ statua i Low. : Modification du champ statua à FALLING. : Modification du champ statua à RISING. : Mode d'aide associé aux intervalles Toutes ces actions, sauf l'apparition du mode d'aide, ont des conséquences sur l'intervalle. Tous les autres stimuli n'appartenant pas à cette table (même cliquer sur le bouton 3 de la souris sans appuyer sur la touche ), sont ignorés. On prend maintenant une de ces actions: "Appuyer sur la touche "r" pour un intervalle qui porte comme statut le statut Low". On va donc envoyer l'ordre de changement aux noeuds de l'arbre syntaxique correspondant. Cet ordre sera interprété grâce à une fonction appelée 'concrettoabtraitifunction" qui est générale pour tout type d'actions et d'objets. Dans le cas présent, cette fonction sera appelée avec les paramètres suivants: concret toabtrait.fuction (" OXXXXX" "Xchange-statu", " RISING") ipantif cateur Nom e la methode Pararetre Cette fonction est divisée en trois parties hormis le problème de transformation de type WOOL en type C: 1. Recherche dans la table appelée "env" de l'objet %obj" représentant le noeud abstrait correspondant à l'identificateur "OXXXXXQ". 2. Recherche du pointeur vers la fonction associée à "changeJtatus" pour un objet de type BASICINTERV dans une table générée par le compilateur EIFFEL. 3. Application de cette fonction sur l'objet "obj" avec comme paramètre la table "env" puis les autres arguments de la fonction. Dans le cas présent il n'y aura que le nom du nouveau statut "RIsING". Grâce à la possibilité de surcharge dans les classes EIFFEL, on applique donc la méth- ode relative au type de l'objet sur lequel elle est appelée. Par exemple, toutes les classes possèdent une méthode generation, une méthode destruction, celles qui sont du type LISTE possèdent toutes des méthodes d'insersion ou de suppression d'un élément mais il n'y a aucun problème de conflit. Il est clair que rajouter une action dans une table d'action, ou modifier la grammaire n'entraîne aucun changement dans cette fonction. Maintenant, nous allons montrer la structure de la classe EIFFEL correspondant aux intervalles: Class BASICINTERV export location, status, generation, decompilation, modification, change-status, repeat GRAPHICNODE inherit NOEUD Interface de la classe BASICINTERV feature Attributs: location: SEGMENT; status: STATUS; Actions d'édition: generation(env: ENVIRONMENT; pere.lig: STRING; borneinf:STRING; bornesup:STRING; status: STRING) is do end; decompilation(env: ENVIRONMENT; pere.lig: STRING) is do end; change. status(env:ENVIRONMENT; status:STRING) is do end; modification (env:ENVIRONMENT; borneinf:INTEGER; bornesup:INTEGER) is do end; Méthodes et attributs associés à la classe BASICINTERV La méthode de destruction est directement héritée de la classe GRAPHICNODE. Toutes les actions d'édition possèdent donc dans leurs arguments la table de correspon- dance entre les objets concrets et abstraits appelée "env'. Cette table va être automa- tiquement mise à jour à chaque création ou destruction d'un objet graphique. Ici, on voit apparaître deux méthodes qui ne peuvent pas être directement appelées par l'image graphique et qui sont communes à toutes les classes: * generation crée le sous-arbre relatif à l'objet et remplit les feuilles de ce sous arbre avec les différents arguments. Cette fonction est en général appelée par le père de l'objet, qui demande la génération d'un de ses fils. * decompilation affiche l'image concrète du nceud, et applique récursivement la dé- compilation aux différents fils de ce noeud. Cette fonction peut être appelée après une modification d'un noeud abstrait ou au chargement d'un chronogramme exis- tant, mais en aucun cas par l'image graphique car cette image est par construction toujours à jour, cela reviendrait à réafficher exactement la même image. Dans le cas du changement du statut d'un intervalle, on va donc descendre dans la feuille de l'arbre représentant le statut, puis on modifiera cette feuille si cela est possible. Pour un changement vers le statut RISING, il est nécessaire de vérifier auparavant que la différence entre les bornes inférieure et supérieure de l'intervalle est supérieure à 2. Ici la modification de l'arbre est très simple, dans le cas de l'insertion d'une ligne, ou d'une période de temps, les conséquences sur l'arbre ne sont pas localisées au sous-arbre incriminé et obligent à naviguer dans l'arbre entier pour modifier de nombreux nceuds. La modification de l'arbre étant réalisée, on va alors mettre à jour l'image graphique. Cette fonction a été optimisée dans le cas du changement de statut. En effet, on ne détruit pas l'image graphique de l'intervalle pour decompiler le nouveau noeud, mais on va appeler directement la fonction d'affichage de la classe GRAPHIC.NODE avec comme argument le champ identwuidget de l'intervalle modifié, suivi du nom de la fonction WOOL permettant ce changement d'attribut, suivi du nom du nouveau statut: affichagelfunction ( "QXXXXXO",change.tatwus.vool", R/SING") ideOfcatew de linr O Né de la fonction Pavmwt Ère Dans le cas d'une création d'un nouvel intervalle de statut RISING, dont la borne inférieure est u2" et la borne supérieure est U3", la fonction d'affichage est appelée avec les paramètres suivants: affichagefunction ( "OYYYYYOI, "intervalle","RISING" "2", "3" ideifcateurw de la ligne Nom de la fonctio Pmw.es 5.3.3 Avantages de cette technique de programmation Nous avons présenté comment et avec quels outils, l'éditeur de chronogrammes a été programmé. Ce qu'il est important de voir en premier lieu, c'est qu'il y a une totale indépendance dans la définition de la syntaxe concrète par rapport à la syntaxe abstraite. Cela donne un éditeur facilement modifiable au niveau de sa syntaxe concrète. En effet, le changement de syntaxe concrète peut même être paramétré grâce à un outil de génération d'interface tel EGERIA. Il suffit d'ouvrir l'éditeur d'EGERIA, de modifier interactivement l'allure des différents objets, puis de sauvegarder les modifications. Cela peut se faire très rapidement, sans compilation de l'ensemble du logiciel, grâce au langage interprété WOOL de contrôle d'EGERIA. Cela est très utile pour des langages graphiques o l'ergonomie est un problème important, et o la définition des objets graphiques est souvent relative aux habitudes des utilisateurs. Par exemple pour les chronogrammes de CHLOE, le problème est rapidement apparu lors des premières présentations. En effet, les chronogrammes sont en général utilisés en appoint d'une spécification papier de circuits. Il n'y avait pas de définition formelle du point de vue syntaxique et encore moins du point de vrue sémantique, chaque concepteur a ses habitudes et ses interprétations. Même si du point de vue sémantique, les concepteurs comprenaient bien les différents aspects du langage CHLOE, il y eut quelques difficultés du point de vue de la syntaxe concrète, surtout dans la représentation des différents statuts des intervalles. Il a donc fallu modifier plusieurs fois l'aspect concret des intervalles. Pour ce type de changement, comme pour le changement du motif spécifiant l'horloge, l'ouverture de l'éditeur EGERIA n'est même pas utile. Ce genre de modification est réalisé grâce à l'ouverture de l'éditeur de bitmap d'UNIX sur le fichier spécifiant le motif courant du statut puis le dessin du nouveau motif du statut puis la sauvegarde du nouveau fichier. Dès cette sauvegarde, le changement de motif est effectif, et tous les nouveaux intervalles seront affichés en prenant en compte la modification. En fait, il est très possible d'intégrer cette génération dans l'éditeur pour donner le moyen à l'utilisateur de personnaliser interactivement son chronogramme en paramétrant ses différents motifs. Dans un autre ordre, les modifications de l'aspect extérieur des objets graphiques telles la couleur, la largeur, la longueur, l'épaisseur de la * bordure,.... ne peuvent pas dans l'état actuel d'EGERIA être facilement réalisées inter- activement par l'utilisateur. Une solution serait la multiplication de variables globales: à chaque paramètre de chaque type d'objets est associé une variable globale initialisée en début de la session. L'utilisateur peut alors en cours de session modifier certaines de ces variables en appelant l'interpréteur WOOL, une redécompilation du chronogramme en cours permettrait la mise à jour du dessin. Cette solution, en l'habillant d'une interface un peu plus conviale que le seul interpréteur, est adaptable pour n'importe quel type de langage graphique, mais elle semble assez coûteuse en mémoire. En fait, la solution la plus intéressante et qui pourrait servir à l'élaboration d'un générateur d'éditeur pour langage graphique, serait la génération de fonctions paramétrables et non pas d'objets fixes par les générateurs d'interfaces. Celles-ci pourraient directement être prise en compte grâce au langage interprété. Du point de vue de la syntaxe abstraite des chronogrammes de CHLOE, la modifica- tion ou l'adjonction d'une nouvelle règle entraîne inévitablement des conséquences plus importantes avec une recompilation totale du logiciel. Pour des modifications légères de la grammaire, les changements sont parfois localisés aux classes donc aux règles incriminées. Dans certains cas, mais cela est très rare, on peut directement gérer cela par EGERLA. C'est le cas de l'ajout d'une nouvelle feuille dans une liste de feuilles. Par exemple dans les chronogrammes, l'ajout d'un nouveau statut peut être réalisé en utilisant l'éditeur EGERIA, sans recompilation. Cela n'est possible que parce que elle n'entraîne aucune modification dans les actions d'édition. En fait, ces actions représentent 90% du code dans un langage graphique, et elles sont très rarement génériques. Elles entraînent des modifications éclatées vers plusieurs noeuds qui n'appartiennent pas nécessairement aux fils du noeud stimulé. Cela empêche d'avoir des structures régulières dans les méthodes. Seules des méthodes de manipulation de liste pour des noeuds de ce type, ou la struc- ture de la méthode de decompilation des noeuds abstraits peuvent être considérées comme génériques, mais dans des outils graphiques la décompilation ne peut pas être considérée comme une méthode de mise à jour immédiate de l'image écran car elle entraîne des prob- lèmes d'efficacité insurmontables. Il est indispensable de programmer des méthodes de modification d'objets graphiques déjà créés qui sont bien sûr beaucoup plus efficaces du point de vue du temps et de la mémoire, mais dans lesquelles l'on perd le peu de généricité que l'on pouvait espérer dans les méthodes graphiques. En fait CHLOE, à cause en particulier des langages utilisés dans sa programmation, peut difficilement évoluer pour permettre ce type de paramétrisation globale interactive. En effet, EIFFEL n'est pas un langage interprété, et ne possède pas un niveau de généricité suffisant. Il serait sûrement plus judicieux pour créer un générateur d'éditeur pour lan- gage graphique d'utiliser le travail qui a été réalisé autours des langages textuels avec des outils de haut niveau tel CENTAUR. Ces différentes étapes dans la spécification d'un lan- gage graphique seraient accessibles en utilisant des outils génériques tels CENTAUR (dont les bases ont été données dès 1975 [VGHK+75]) pour la paramétrisation de la syntaxe abstraite, de la sémantique, et des actions d'édition, et un outil d'aide à la génération d'interfaces tel EGERIA pour les aspects purement graphiques de paramétrisation de la syntaxe concrète. Cette technique est utilisable pour n'importe quel type de langage graphique. On s'aperçoit que grâce à cette méthode de programmation, on se retrouve avec un code malléable, évolutif et robuste aux changements. Une grande partie des actions d'édition pourait être récupérée dans le cas de développement de langages graphiques possédant une structure analogue, en revanche pour le développement de langages graphiques apparentés aux bloc diagrammes ou aux réseaux de Petri la plupart des ces actions devront être réadaptées en profondeur. Indépendamment du code, et de l'analyse syntaxique réalisée au fur et à mesure de l'édition, cette méthode d'édition présente pour l'utilisateur deux grands avantages. Elle permet de localiser toutes les actions sur les objets graphiques en supprimant en grande partie la méta-syntaxe, et permet de limiter le nombre d'actions à retenir. Par exemple, si l'insertion d'un objet dans une liste s'obtient en cliquant sur le premier bouton de la souris, le geste pour insérer sera le même pour un signal dans la liste des signaux, pour un intervalle dans la liste des intervalles ou encore pour un cycle d'horloge. C'est la position du curseur de la souris sur la fenêtre définissant le chronogramine et donc le type du noeud de l'arbre syntaxique correspondant qui permet d'interpréter l'ordre comme insertion d'un intervalle sur une ligne si le curseur est positionné sur une ligne, ou insertion d'un signal après tel signal si le curseur est positionné sur un signal, ou insertion d'un cycle d'horloge si le curseur est positionné sur la partie graphique représentant l'horloge. Il en est de même pour toutes les actions de ce type, par exemple la sélection ou la suppression. Ce regroupement des actions possibles a déjà été appliqué dans certains éditeurs avec menu déroulant ou fixe [BKL89] mais la présence de ces menus en font des éditeurs à mode. En effet, si l'on est dans le mode suppression", quels que soient les objets graphiques que l'on manipulera, et surtout quelle que soit la façon dont on les excitera, on réalisera la même action, à savoir détruire, qui est définie par le mode courant, et la seule manière d'en changer est de choisir le nouveau mode dans le menu de marge (ou d'y accéder par un accélérateur). Le mécanisme d'édition tel qu'il a été développé plus haut, a été systématiquement ap- pliqué à tous les noeuds de l'arbre, et cela a eu pour conséquence d'éliminer complètement tous les menus de l'éditeur. En effet, les menus qui permettaient à l'utilisateur de définir le mode courant de l'éditeur ne sont plus utiles car avec ce type de contrôle, l'information est répartie au niveau de chaque objet graphique. On n'a donc plus un éditeur à mode, mais un éditeur que l'on appellera à "objet" (en rapport avec la programmation orientée objet), car l'action qui va être réalisée est définie par l'objet que l'on stimule. En fait, le mode courant de l'édition correspond au mode courant de l'arbre syntaxique qui se confond complètement avec le dessin du chronogramme que l'utilisateur saisit. Cela donne un éditeur o la méta-syntaxe est limitée à des parties d'objets définies au niveau des langages de programmation graphique (par exemple les ascenseurs dans les différentes fenêtres). Cela donne aussi un éditeur avec un apprentissage facile car possédant un mode d'aide lié lui aussi aux différents types d'objets, et qui, pour un utilisateur expérimenté, donne de très bonnes performances de saisie. Chapitre 6 Conclusion 6.1 Notre contribution Dans cette thèse, le premier but que nous nous étions fixé était de donner au concepteur de matériel le moyen de spécifier des propriétés temporelles de circuit dans un formalisme de haut niveau tout en restant proche de leurs habitudes. Les langages existants sont certes très puissants dans leur pouvoir d'expression, mais malheureusement difficiles d'accès. Avec les chronogrammes nous avions alors un bon support pour la définition de ce type de langage dans le monde de la conception de circuit. Nous avons donc adopté une approche "sciences naturelles" pour définir le langage CHLOE. Nous avons dans un premier temps analysé les différents chronogrammes em- ployés par les concepteurs et existants dans les différentes spécifications de circuit. Nous nous sommes alors aperçus qu'il n'existait pas de règles précises dans ce domaine. Les formalismes utilisés sont parfois très éloignés les uns des autres et souvent beaucoup d'intuition et de savoir faire sont nécessaire à leur lecture. Nous avons donc extrait un sous-ensemble de propriétés qu'il paraissait intéressant et surtout avantageux (ergonomiquement parlant) d'exprimer par chronogrammes pour des personnes habituées à ce type de formalisme. De ce sous-ensemble, il était important de faire émerger une structure commune qui nous permettrait d'avoir le maximum d'efficacité et de maniabilité. Nous avons donc dans un deuxième temps formalisé cette structure pour en faire un langage o la syntaxe et la sémantique sont formellement définies. Ceci étant fait, on s'est très vite aperçu qu'une hiérarchisation dans les langages de chronogrammes s'avérait indispensable. Nous avons alors décidé de créer deux niveaux de langages: d'un côté le langage appelé langage primitif qui reprend cette structure commune, et qui sert de base aux compilateurs, et de l'autre le langage évolué ou utilisateur essentiellement dédié à l'ergonomie qui permettra une pratique plus flexible des chronogrammes. La définition du langage primitif, pivot de tout l'environnement CHLOE,fut réal- isé pour permettre de spécifier un maximum de classes de propriétés. Au travers des différentes classifications existantes, on s'aperçoit que le langage permet d'aborder la plu- part de ces classes (sûreté, vivacité, récurrence, persistance,....), mais pour aucune de ces classes il n'est complet. Par exemple, même dans le cas des propriétés de sûreté la l disjonction de chronogrammes n'est pour l'instant pas acceptée. Cela peut paraitre dans un premier temps très limitatif, mais dans la pratique cette possibilité n'est pas util- isée. Bien sûr, pour des extensions ultérieures, il peut s'avérer intéressant d'augmenter la puissance du langage primitif, mais dans notre cas il était important d'aller le plus loin possible dans la spécification par chronogrammes, tout en restant collés au maximum à l'existant. Il ne sert à rien de se servir des chronogrammes pour spécifier des propriétés pour lesquelles ils ne sont pas adaptés. Les langages graphiques sont des outils puissants qu'il faut manipuler avec précaution et dans certains cas, le textuel est mieux adapté. Nous avons donc volontairement restreint le langage primitif aux aspects qui nous ont semblés les plus utiles. Dans la définition du langage primitif, la recherche de la structure commune, très importante dans une optique de compilation des chronogrammes, en fit perdre certains aspects ergonomiques. Un éditeur a été réalisé à partir de ce langage, mais il s'avérerait indispensable de créer un second langage capable d'évoluer au gré des demandes des util- isateurs sans remettre en cause la sémantique formelle des chronogrammes et l'ensemble des compilateurs. Les chronogrammes évolués furent définis pour pallier ce problème. Un éditeur basé sur leur structure fut alors développé; il possède des avantages er- gonomiques qui le rendent plus attractif et plus convivial. Mais il ne possède pas une puissance d'expression supérieure au langage primitif En effet, toute propriété spécifiée dans un chronogramme évolué peut être traduite dans le langage primitif pour son utilisa- tion ultérieure. Cet éditeur et ce langage se développent au fur et à mesure des demandes des utilisateurs autant du point de vue des aspects concrets qu'abstrait. Il était donc important, et c'est là l'une des principales difficultés des éditeurs graphiques, de réaliser un éditeur capable d'évoluer très rapidement avec les besoins des utilisateurs. L'éditeur de chronogrammes de CHLOE fut pensé dans cet optique. Entièrement dirigé par la syn- taxe, il permet grâce à la méthode de programmation utilisée et aux outils employés dans cette programmation d'accepter sans difficulté des modifications, même importantes, des aspects concrets du langage. Apres une définition syntaxique, la création d'un langage, qu'il soit graphique ou textuel, passe obligatoirement par sa définition sémantique. Nous nous sommes donc attachés à établir la sémantique. Le choix des formalismes pour cette définition a été en grande partie dicté par l'utilisation que nous voulions faire de ce langage graphique dans le domaine de la validation de circuits. Les chronogrammes ont en fait deux sens possibles. Le premier est de servir de moyen de spécification en les considérant comme des contraintes sur un modèle. Le deuxième et aussi le plus courant est d'être utilisés dans la vérification d'un modèle existant. Les chronogrammes seront alors considérés comme des propriétés dont on doit vérifier la validité sur le modèle. Notre but n'était pas seulement de définir un langage graphique et de réaliser les éditeurs correspondant, mais aussi de créer un environnement permettant leur utilisation la plus large possible. Cela nous a entrainé dans des mondes différents mais complémentaires, tels les logiques temporelles avec CTL, les langages synchrones avec SIGNAL, et les langages de description de matériel avec SVHDL. Le souci constant qui amena vers ces différents langages était d'utiliser le maximum d'outils déjà existants et de tester les algorithmes de compilation que nous avions définis. Après une première approche vers les logiques temporelles et plus précisément CTL, nous nous sommes intéressés aux langages synchrones et plus particulièrement à SIGNAL. Ce choix dicta alors le choix du formalisme qui est utilisé dans la définition seman- tique du langage primitif. En effet, la sémantique de SIGNAL étant définie en terme d'intension, nous avons repris ce formalisme pour définir la sémantique du langage primi- tifs des chronogrammes. Le langage complet fut alors défini. En parallele, et par un souci de classification du langage, une deuxième sémantique en terme d'expressions rationnelles a été écrite. Cette définition, même incomplète, permet d'avoir des résultats intéressants sur la rationnalité du langage de chronogrammes. Nous avons donc grâce à ces différents aspects montré qu'un langage basé sur les chronogrammes pouvait être un très bon outil de spécification formelle de propriétés dynamiques. 6.2 Les futures recherches et développements Notre but principal était de montrer la faisabilité de l'approche chronogramme dans le domaine de la validation de circuits. L'ensemble des contacts que nous avons eu avec les concepteurs nous conforte dans cette idée. Mais l'étude complète du langage et le développement de l'environnement CHLOE n'est pas encore achevé, il reste encore d'autres axes de recherche pour utiliser tout leur potentiel. Dans le domaine de l'utilisation de chronogrammes pour la vérification, il n'existe pas de compilateur pour l'ensemble des chronogrammes de CHLOE mais nos recherches continuent pour la compilation du langage complet. De nouveaux algorithmes sont en préparation surtout vers le langage SIGNAL; ils permettront de compiler les zones dy- namiques. Cet algorithme faisant appel a toute la puissance flots de donnée de SIGNAL est en cours de validation. Pour l'instant l'utilisation des chronogrammes de CHLOE est surtout axée vers la véri- fication de propriétés dynamiques sur un modèle existant. En fait, il n'y aucun moyen de vérifier auparavant que les propriétés ainsi spécifiées correspondent bien à l'idée que le concepteur s'en fait. La seule possibilité de vérification qui n'est pas complète mais qui peut donner des informations intéressantes, est de prouver qu'il n'existe pas de con- tradiction entre les différents chronogrammes d'un même modèle. Cette vérification n'est pas complète mais peut donner des informations intéressantes. Avec la définition séman- tique des chronogrammes dans les langages rationnels, prouver qu'il existe au moins une machine vérifiant l'ensemble des chronogrammes revient à prouver que l'intersection des différents langages engendrés par ces chronogrammes n'est pas vide. Une autre possibilité pour ce type de vérification, est d'utiliser le compilateur SIGNAL qui va résoudre le sys- tème d'équation engendré par les chronogrammes, du moins pour ceux qui sont compilés. Pour permettre d'augmenter encore la puissance d'un langage de chronogrammes, il serait intérressant d'accepter ce que l'on appellera des 'graphes de chronogrammes". Les chronogrammes seraient alors considérés comme des blocs reliés entre eux par des ex- pressions logiques. Ces expressions écrites dans une logique temporelle, permettraient de définir des propriétés de plus hauts niveaux avec des contraintes de synchronisation beau- coup plus faibles. On utiliserait alors toute la puissance ergonomique des chronogrammes ainsi que la puissance d'expression et de preuve déjà développées autour des logiques temporelles. Pour le momment l'édition et la compilation de chronogrammes sont réalisées en prenant comme hypothèse un temps discrétisé par une horloge de base. Un axe, qui semble interessant d'approfondir et qui correspond aussi à la culture des concepteurs, est d'introduire le temps continu dans les chronogrammes. Du point de vue de l'édition, cela ne posera pas vraiment de problème et la structure du langage semble être sauveg- ardée. En revanche, la compilation et l'utilisation de tels chronogrammes est beaucoup plus problématique. L'utilisation des automates temporisés et des logiques temporelles à temps continue telles TCTL [HNSS92] semble être mieux adaptées Bibliographie [ABM+89] F. Anceau, C. Berthet, J. C. Madre, O. Coudert, and J. P. Billon. La preuve formelle en milieu industriel, volume 8 N=6. 1989. [ABOR90] R. Airiau, J.-M. Bergé, V. Olive, and J. Rouillard. VHDL du langage à la modélisation. Presses polytechniques et universitaires romandes, Paris, 1990. [AL91] Christian Antoine and Bernard Le Goff. Timing diagrams for writing and checking logical and behavioral properties of integrated systems. In P. Pineto and P. Camurati, editors, Proceedings of the Correct Hardware Design Methodology, CHARME'91, Turin, Italy, June 1991. Elsevier. {ALP92] Christian Antoine, Bernard Le Goif, and Jean-Eric Pin. Une sémantique à base d'expressions rationnelles pour un langage de chronogrammes. Research Report RAD/DMA92029, BULL SA, Les Clayes sous bois, France, December 1992. [ALP93] Christian Antoine, Bernard Le Goif, and Jean-Eric Pin. Cromlech: un envi- ronnement pour chronogrammes, méthodes et outils. Research report, BULL SA, Les Clayes sous bois, France, 1993. [Ant91a] Christian Antoine. Définition syntaxique et sémantique du langage noyau des chronogrammes. Research Report RAD/DMA91XX, BULL SA, Les Clayes sous bois, France, October 1991. [Ant91b] Christian Antoine. Spécification de propriétés au moyen de chronogrammes et traduction en logique temporelle. Rapport de recherche Interne RR 90.04, Université de Provence, Marseille, France, Janvier 1991. [BCHG91] P. Bournai, B. Cheron, B. Houssai, and P. Le Guernic. Manuel SIGNAL, février 1991. [BG88] G. Berry and G. Gonthier. The ESTEREL synchronous programmning lan- guage: Design, semantics, implementation. Research report 842, INRIA, May 1988. [BKL89J Patricia Bournai, Vivianne Kerscaven, and Paul Le Guernic. Un environ- nement graphique pour la conception d'applications temps réel. In Col- loque sur l'ingénierie des interfaces homme-machine, pages 181-190, Sophia-Antipolis, 1989. [BL87] Albert Benveniste and Paul Le Guernic. Data flow model of synchronous programming, application to the language SIGNAL. Internal publication 385, IRISA, Rennes, December 1987. [BM88] R. S. Boyer and J. S. Moore. A Computational Logic Handbook. Aca- demic Press, 1988. [BM9Oa] S. Burch, E. M. Clarke and K. L. McMillan. Sequential circuit verification using symbolic model checking. 27 th DAC, juillet 1990. [BM9Ob] S. Burch, E. M. Clarke and K. L. McMillan. Symbolic model checking: 102 states and beyong. LICS, 1990. [Bor88] Gaetano Borriello. A New Interface Specification Methodologiy and its Application to Transducer Synthesis. PhD thesis, Computer Science Division of Universite of California Berkeley, May 1988. [Bor92] Gaetano Borriello. Formalizme timing diagrams. 1992. [Bou921 Vincent Bouthord. The EGERIA Manual Version 2.0, 1992. [BPS91] D. Borrione, L. Pierre, and A. Salem. Prevail: A proof environment for vhdl description. In P. Prineto and P. Camurati, editors, Procceding of the Correct Hardware Design Methodology, Turin, Italy, June 1991. Elsevier. [CBM89] O. Coudert, C. Berthet, and J. C. Madre. Verification of synchronous se- quential machines using boolean functional vectors. In Formal VLSI Cor- rectness Verification, North-Holland, novembre 1989. L.J.M. Cleasen. [CD88] E. M. Clarke and I. A. Draghicescu. Expresibility results for linear-time and branching-time logics. In J. W. de Bakker, W.-P. de Roever, and G. Rosen- berg, editors, Linear Time, Branching Time and Partial Order in logics and Models for Concurrency, volume LNCS 354, pages 428-437. Springer-Verlag, June 1988. [CE81] E. M. Clarke and E. A. Emerson. Design and synthesis of synchronization skeletons using branching-time temporal logic. In Workshop on Logic of Programs. LNCS 131, Springer-Verlag, 1981. [CG87] E. M. Clarke and O. Grumberg. Research on automatic verification of finite- state concurent systems. In Annual Reviews of Computer Sciences, pages 269-289, 1987. [Cla90] L. J. M. Claesen, editor. Formal VLSI Correctness Verification, Ams- terdam, November 1990. IFIP, North-Holland. [CLS92] CLSI Solutions, 5457 Twin Knolls Road, Columbia, MD 21045. VFORMALUser's Manual, October 1992. [CM90] Olivier Coudert and Jean-Christophe Madre. Verifying temporal properties of sequential machines without building their state diagrams. In Interna- tional Workshop on Formal Verification Methods of Finite State Systems, NJ, USA, June 1990. Rutgers. [Col82] A. Colmerauer. prolog -IH, Manuel de référence et modèle théorique. Université d'Aix-Marseille II, groupe d'intelligence artificielle edition, 1982. [Cou91] Olivier Coudert. SIAM: Une Boite à Outils pour la Preuve Formelle de Systèmes Séquentiels. PhD thesis, Ecole Nationale Supérieure des Télécommunications, Octobre 1991. [CPHP87] P. Caspi, D. Pilaud, N. Halbwachs, and J. A. Plaice. LUSTRE: A declarative language for programming synchronous systems. In 14th ACM Sympo- sium on Principles of Programming Languages, pages 178-188, Mu- nich, 1987. [Dai90] Daisy Systems Corporation. PED User's Guide, March 1990. [Daw92] John Dawes. The VDM-SL Reference Guide, 1992. [DBJ91] A. Debreil, C. Berthet, and A. Jerraya. Symbolic computation of vhdl hierar- chical descriptions. In First European Conference on VHDL Methods, septembre 1991. [DKC91] Mario Dufresne, Karim Khordoc, and Eduard Cerny. Using formalized tim- ing diagranms in vhdl simulation. In Second European Conference on VHDL Methods, pages 224-31, 1991. [DL91] Jeremny Dick and Jerome Loubersac. Integration structured and formal methods: A visual approach to vdm. In Lecture Notes in Computer Science, volume 550. ESEC, Springer-Verlag, 1991. [DLA90] D.Borrione, L.Pierre, and A.Salem. Formal verification of vhdl descriptions in boyer-moore: first results. In First European Conference on VHDL Methods, 1990. [DO92] A. Debreil and P. Oddo. Synchronous design in vhdl. In IEEE Computer So- ciety Press, editor, EURO-DAC92 EURO-VHDL92. Elsevier, septembre 1992. [Eil74] S. Eilenberg. Automata, languages and machines, volume A. Springer, 1974. [Eme90] E. A. Emerson. Temporal and modal logic. In Jan van Leeuwen, editor, For- mal Models and Semantics, Handbook of Theorical Computer Science, pages 995-1072. Elsevier, 1990. [FF90] Masahiro Fujita and Hisanori Fijisawa. Specification, verification and syn- thesis of control circuits with propositional temporal logic. In j. a. Dar- ringer and F. J. Ramming, editors, Computer Hardware Description Langages and their Applications, pages 265-279. IFIP, Elsievier Science Publisher, 1990. [GL1B87] Thierry Gautier, Paul Le Guernic, and Loîc Besnard. SIGNAL: a declarative language for synchronous programming of real-time systems. In Gilles Kahn, editor, Functional programming languages and computer architec- ture, pages 257-277. Lecture Notes in Computer Science, 274, Springer- Verlag, 1987. [HNSS92] T. A. Henzinger, X. Nicollin, J. Sifakis, and S.Yovine. Symbolic model checking for real-time systems. In Thomas Ottmann, editor, 7 th Symp. on Logic in Computer Science. IEEE Proc., Springer-Verlag, June 1992. [IEE88] IEEE. IEEE Standard VHDL Language Reference Manual, 1988. Std 1076-1987. [KCD92] Karim Khordoc, Eduard Cerny, and Mario Dufresne. Modeling and execu- tion of timing diagrams with optional and multi-match events. 1992. [KDC91] Karim Khordoc, Mario Dufresne, and Eduard Cerny. A stimulus/reponse system based on hierarchical timing diagrams. Technical Report 770, De- partement d'Informatique et de Recherche Operationelle Université de Mon- tréal, Avril 1991. [LB86] Paul Le Guernic and Albert Benveniste. Real-time synchronous, data-flow programming: The language SIGNAL and its mathematical semantics. Re- search report 620, INRIA, Rocquencourt, France, June 1986. [LB92] Yew-Hong Leong and William. P Birmingham. The automatic generation of bus-interface models. 1992. [Le 89] Bernard Le Goff. Inférence de contrôle hiérarchique: application au temps-réel. PhD thesis, Université de Rennes 1, 1989. [Lou91] Jerome Loubersac. Vtp users' guide. Technical Report 14.1.4.2. 3.1, Atmo- sphere Report, Décembre 1991. [Mad90] Jean-Christophe Madre. PRIAM: Un Outil de Preuve Formelle de Circuits Digitaux. PhD thesis, Ecole Nationale Supérieure des Télécom- munications, juin 1990. [MB88] Jean-Chistophe Madre and Jean-Paul Billon. Proving circuit correctness us- ing formal comparison between expected and extracted behavior. In Design Automation Conference, DAC'88, 1988. [Mey92] Bertrant Meyer. Eiffel: The reference Manual Version 2.3, 1992. [MJ91] M. Mertens and D. Jaillet. LDS System Description Language. BULL SA, July 1991. BULL S.A. CONFIDENTIAL & PROPRIETARY. [MP92] Z. Manna and A. Pnueli. Hierarchy of temporal properties. 1992. Commu- nication privée: Weizmann institute of science. [Mu188] The Institute of Electrical and Electronics Engineers, Inc. IEEE Standart for a High-Performance Synchronous 32-Bit Bus: MULTIBUS IH, 1988. [Mur88] J. Y. Murzin. Faon: A functional abstractor of netlist. In Actes du Sem- inaire de Programmation Logique, 1988. [Nef89] Frédéric Nef. La logique du langage naturel. Hermes, Paris, 1989. [Per84] D. Perrin. An introduction to automata on infinite words. Springer, 1984. [QS81] J. Queille and J. Sifakis. Specification and verification of concurrent systems in cesar. In 5 th International Symposium in Programming. LNCS 137, Springer-Verlag, 1981. [VGHK+75] V.Donzeau-Gouge, G. Huet, G. Kahn, B. Lang, and J.J. Levy. A structure- oriented program editor: a first step towards computer assisted progranm- ming. In Thomas Ottmann, editor, International Computing Sympo- sium. North-Holland Publishing Compagny, June 1975. [yN88] y. Noyelle. Traitement des langages évolués. compilation, interprétation, support d'exécution:. Masson, 1988. Chapitre IV. [You90] Douglas A. Young. The X Window System Programming and Appli- cations with Xt. OSF/MOTIF EDITION, 1990. Liste de Figures 1 Introduction 7 1.1 Chronogramme de bus............................. ........... 9 1.2 Chronogranmme de circuit........................... . 9 1.3 Chronogramme de protocole.......................... 9 1.4 La place de CHLOE.......................................DTD: .... 13 1.5 L'environnement CHLOE............................ 14 2 La syntaxe du langage CHLOE 19 2.1 L'automate des couleurs............................ 19 2.30 Les propriétés (1), (2), (3), (5) dans un chronogramme de CHLOE..... 21 2.4 La propriété (5)......................................... 23 2.4 La propriété(6)................................. 24 2.5 Un exemple de propriété de vivacité...................... 24 2.6 Un exemple de propriété de récurrence infinie................ 25 2.10 Les chronogrammnes de CHLOE......................... 26 2.8 Les chronogrammes évolués de CHLOE.................... 27 2.9 Les chronogranmmes primitifs de CHLOE................... 28 2.10 Les chronogrammes de CHLOE.................................... 30 2.11 Les chronogrammes évolués.......................... 32 2.12 La scène dans un chronogramme évolué.................... 33 2.13 Les zones statiques dans une scène...................... 34 2.14 Les segments des multi-colonnes dynamiques........................ 35 2.15 Les lignes dans les zones statiques ou dynamiques.............. 37 2.16 Calcul des bornes d'un intervalle........................ 38 2.17 Les intervalles dans les lignes d'un chronogramme évolué.......... 39 2.18Les segments dans IN..... .DTD: ........................ 39 2.19 Les valeurs stables dans l'exemple de l'automate des couleurs........ 41 2.20 Les événements dans l'exemple de l'automate des couleurs............ 41 2.21 Les propriétés dans un chronogramme évolué........................ 42 2.22 Le langage primitif... .DTD: .................................... 44 2.23 Les scènes dans un chronogramme primitif.................. 45 2.24 Les zones statiques dans une BasicSceno..................... 46 2.25 Les zones dynamiques dans une BasicScene........................ 46 2.26 Les lignes dans les zones statiques ou dynamiques.................... 47 2.27 Les intervalles dans les lignes d'un chronogramme primitif......... 47 2.28 La structure des statuts stables dans le langage primitif........... 49 2.29 Les événements dans le langage primitif.................... 50 2.30 Le chronogrammne évolué............................ 51 2.31 La propriété 1): Si on lit BLEU et que l'on est JAUNE, alors on est VERT au pas suivant............................................. 52 2.32 La propriété 2): Si on est BRUN, alors on le reste.................... 52 2. 33 La propriété 3): Si on lit ce que l'on est, alors on le reste.......... .DTD: ... 52 2.34 La propriété 5): On écrit toujours la couleur que l'on a au pas suivant... 52 3 Les sémantiques des chronogrammes 57 3.1 Le tryptique sémantique..................DTD: ...................... 57 3.3 Un exemple de chronogramme statique....... DTD: ...................... 84 3.3 Un exemple de chronogramme dynamique...... DTD: .................... 85 3.4 Le même propriété exprimée dans la sémantique indexicale......... 86 4 Les générateurs de code de CHLOE 89 4.1 La machine résultante.......DTD: ...................... 91 4.2 Une propriété positive.................... DTD: ......... 92 4.3 Une BasicScene......................................... DTD: .... 93 4.4 Une StaBasJlrea............................................. DTD: 94 4.5 Une Ligne.............................................. 95 4. 6 Compilation des statuts HIGH, Low, IRRELEVANT............. 97 4.7 Compilation du statut STABLE.................................. 97 4.8 Un exemple de chronogramme statique............................. 99 4.9 Structure du chronogramme..........................105 4.10Modèle résultant. ............................... 105 4.11Modèle résultant. ..... .DTD: ......................... 106 4.12Le graphe initial...................... DTD: ........... 107 4.13Le graphe modifié................................ 107 4.14 Décomposition des zones............................ 108 4.15 Exemple de ligne dans un chronogramme statique.................... 119 L'édition 123 5.1 Utilisation initiale de l'éditeur................................ DTD: . 125 5.2 Utilisation terminale de l'éditeur........................ 126 5.3 Propriété 1...................................131 5.4 Propriété 2...................................131 5.5 Propriété 3................... DTD: ................132 5.6 Propriété 4. .................................. 132 5.7 Spécification de la durée minimale et maximale du transport...... DTD: .. 134 5.9 Calcul de la prime...............................135 5. 10Exemple de scénario valide........................... 136 5.11 Exemples d'action sur un chronogramme de CHLOE............. 138 5.12 Du concret vers l'abstrait............................ 139 5.13 De l'abstrait vers le concret.......................... 140 5.14 Rôle de la grammaire dans la structure fonctionnelle de CHLOE...... 140 A.1 CHLOE dans un processus de validation.................... 165 A.2 Une mémoire répartie hiérarchisée....................... 166 A.3 Deux scénarios de transit de messages............................ 168 A.4 L'implication de l'état INV par l'état DR....................... 174 A.5 La négation....... DTD: ............................ 175 A.6 L'exclusivité de l'état DR.......... DTD: .................176 A.7 L'exclusion des états DR et SH.................. DTD: ...... 177 B.1 La transition d'une capsule sur une lecture............... DTD: ... 178 B.1 La transition d'une capsule sur une lecture.................. DTD: 187 Annexe A Un Exemple d'utilisation de Chloe A.1 La place de CHLOE Cette annexe présente, à travers un exemple, une méthode d'utilisation des chronogrammes dans le domaine de la validation de circuit. Cette méthode ne se veut pas originale. Elle a au contraire la prétention de suivre au plus près les habitudes des concepteurs. La présentation de cette méthode sur un exemple est l'occasion d'une mise en perspective de CHLOE. Ceci devrait aider le lecteur à comprendre comment CHLOE peut rendre service. La méthode peut se décrire en quelques phrases. Il est supposé qu'il existe un modèle du système à concevoir et construire. Ce modèle doit être validé. Des propriétés logiques et temporelles sont connues comme devant être satisfaites par le modèle. Ces propriétés sont.. DTD: spécifiées formellement sous forme de chronogrammes. Ces chronogrammes sont compilés. Le résultat de cette compilation est utilisé pour la validation. Pour cette validation deux moyens sont possibles: la simulation et la preuve. La méthode que nous proposons ne rejette aucuns des deux moyens, au contraire la compilation a été conçue pour que le même code généré puisse servir indifféremment en simulation et en preuve formelle. Le code généré est en fait l'analyseur de trace, l'observateur ou le vérifieur que les concepteurs développent et connectent à leur modèle pour les aider au dépouillement des traces produites lors des simulations. Le développement de ces observateurs souvent fait pour l'essentiel à la main est très long et très coûteux. CHLOE génère automatiquement un vérifieur à partir des propriétés temporelles spécifiées sous forme de chronogrammes. La figure A.1 illustre la place de CHLOE dans cette méthode. Le vérifieur généré par CHLOE peut se connecter à des niveaux très différents du modèle. Il peut aussi se con- necter aussi bien a des entrées qu'à des sorties ou qu'à des mémoires du modèle. PLACE DE CHLOE CON'rAJNF TEFPOREFILES MODLE1 GENERAnON AUTOMAIIQUE Figure A.1: CHLOE dans un processus de validation A.2 Un exemple: une mémoire répartie Afin de bien montrer le rôle du Langage de chronogramme et de CHLOE, cette méthode va être déclinée sur un exemple classique et important. Il s'agit du protocole de maintien de la cohérence de la mémoire répartie d'un gros multiprocesseur. Le modèle montré ici de ce protocole est une version simplifiée d'un protocole créé à BULL. Ce modèle a été spécifié en SVHDL et simulé. Il a aussi été traité par des outils de preuve formelle. La validation d'un modèle de protocole, d'un système de contrôle complexe ou d'un * circuit séquentiel pose un problème particulier lié à la définition de sa fonction. Contraire- ment à un additionneur ou un multiplieur dont la fonction peut se définir parfaitement par une simple table d'opération, en général, la fonction de systèmes tel un protocole est difficile à décrire. Cette complexité intrinsèque de la fonction de ces systèmes complique de façon considérable le processus de validation. La question est par exemple: Comment reconnaître sur des traces de simulation que la fonction est correctementmise en oeuvre par le modèle ? Sur l'exemple proposé, certains des aspects fondamentaux de la fonction du protocole vont être spécifiés sous forme de chronogrammes. La figure A.2 montre sous une représentation très schématique le multiprocesseur dont il faut valider le protocole. Figure A.2: Une mémoire répartie hiérarchisée Ce système est composé d'une mémoire centrale comprenant plusieurs partitions. Cette mémoire centrale est représentée par le rectangle du haut de la figure. On peut y voir les partitions représentées par des rectangles étroits et posés debout. Cette mémoire centrale est reliée à plusieurs capsules par des lignes série. Sur le schéma trois capsules sont représentées. Ce sont les rectangles du bas de la figure. Les lignes série sont représen- tées par les traits obliques allant de chacuns des rectangles représentant les capsules au rectangle représentant la mémoire centrale. Chaque capsule contient une mémoire cache reliée à plusieurs processeurs par un bus. La mémoire cache d'une capsule est représentée par un rectangle étroit et posé couché en haut du rectangle représentant la capsule. Le bus est représenté par un trait horizontal relié par le haut au rectangle représentant le cache au moyen d'un trait vertical et relié par le bas au rectangles représentant les processeurs aussi au moyen de traits verticaux. Chaque processeur possède sa propre mémoire cache privative. Le rectangle représentant un processeur a deux parties la partie du haut, la plus petite, représente la mémoire cache privative et la partie du bas le processeur lui-même. Les nombres de capsules, de processeurs dans chaque capsule et de partitions de mémoire centrale sont variables. Ceci est représenté par des séries de trois points. La règle d'inclusion entre les trois niveaux de mémoire est respectée. Une capsule ne peut communiquer qu'avec la mémoire centrale. La mémoire centrale ne peut se remettre à jour que par blocs entiers. La connexion par des lignes série des capsules à la mémoire centrale renforce la difficulté de la gestion de la communication: une connexion par bus a un effet synchronisant qui est perdu ici. Les lignes série sont monodirectionnelle; il y en a deux, une dans chaque sens, entre chaque capsule et la mémoire centrale. Le modèle pris pour exemple se situe au niveau d'abstraction suivant: * dans le système n'existe qu'une seule adresse de bloc mémoire, * chaque capsule est réduite à l'automate de contrôle de sa mémoire cache, * l'automate de contrôle de la mémoire cache de chaque capsule reçoit en entrée les requêtes de lecture et d'écriture qui viendraient, dans un modèle complet, des proceseurs internes à la capsule, * la mémoire centrale est réduite à son automate de contrôle. Les lignes série son simulées par un multiplexeur et un démultiplexeur. La figure ?? montre le schéma-bloc du contrôleur de cohérence. Ce schéma-bloc est une représentation structurelle d'un modèle SVHDL du contrôleur. Ce modèle a été spécifié en SVHDL pour pouvoir être traité par l'outil de preuve formelle VFORMAL développé à BULL. La caractéristique la plus remarquable du modèle est son synchronisme: l'horloge ck cadence l'ensemble du contrôleur. La figure A.3 montre sous forme d'un chronogramme une partie de la fonction du pro- tocole. Ce chronogramme n'appartient pas au Langage de chronogramme. En revanche une extension du langage de chronogramme incluant ce type de chronogrammes est à l'étude. Bien que fort différent en apparence des chronogrammes appartenant au Langage de chronogramme, la différence essentielle entre ce chronogramme et les chronogrammes du Langage de chronogranmme n'est pas syntaxique mais sémantique: le chronogramme de la figure A.3 n'est pas synchrone, et les dépendances chronologiques des événements y sont toujours explicites; en effet, deux événements y sont ordonnés que s'ils se trouvent sur un même axe horizontal ou s'ils sont liés par une flèches obliques, cette relation est transitive. fart, Sh C4 Dr S\ IIV _ C2 aS I ' "'"">- cm Figure A.3: Deux scénarios de transit de messages. Le diagramme de la figure A.3 est composé de cinq flèches horizontales entre lesquelles sont tirées des flèches obliques. Chaque flèche horizontale représente le processus, séquen- tiel par hypothèse, contrôlé par une des entités du contrôleur: les flèches C1, C2, C3 et C4 représentent chacunes une capsule, la flèche CM représente la mémoire centrale, le multiplexeur et le démultiplexeur ne sont pas représentés. Les flèches obliques représen- tent le transit de messages entre les entités le long des lignes série. Elles sont obliques car le transit d'un message prend du temps, par hypothèse. Les flèches horizontales sont composées de plusieurs segments d'épaisseur différente. Chaque épaisseur représente un état spécifique de l'entité correspondante. Les changements d'épaisseurs co'incident avec les extrémités des flèches obliques parce que les transitions d'états se produisent aux émissions ou aux réceptions de messages. Les états et les messages sont étiquetés. Les états peuvent être INV pour invalidate qui signifie qu'il n'y a pas de copie correcte du bloc dans l'unité mémoire de l'entité correspondante, SH pour shared qui signifie que la copie du bloc présente dans l'unité mémoire de l'entité correspondante est correcte mais qu'elle ne peut pas être mise à jour, droit en lecture seulement, DR pour durty qui signifie que la copie du bloc présente dans l'unité mémoire de l'entité correspondante est correcte et qu'elle peut être remise à jour, droit en écriture, BLWT pour bloc waited qui signifie que l'entité correspondante est en attente d'une copie correcte du bloc, autorisation de lecture, INVWT pour invalidation waited qui signifie que l'entité correspondante est en attente ou d'un ordre d'invalidation ou d'un quitus, dans le premier cas la copie du bloc présente dans l'unité mémoire de l'entité correspondante doit être considérée comme incor- recte, interdiction de lecture, dans le deuxième cas l'entité correspondante gagne le droit d'écrire, SP pour siphon qui signifie que la mémoire centrale est en attente d'une copie correcte du bloc. Les messages peuvent être BLCLn pour bloc cala qui signifie que l'entité n demande une copie correcte du bloc, BLn pour bloc qui signifie que la copie du bloc contenue par le message est pour l'entité n s'il s'éloigne de la mémoire centrale et vient de l'entité n s'il va vers la mémoire centrale, INVRQn pour invalidation request qui signifie que l'entité n demande l'autorisation en écriture, elle suggère donc aux autres entités d'invalider leur copie, INVBRn pour invalidation broadcasting qui signifie que la mémoire centrale ordonne à l'entité n d'invalider sa copie, cette entité perd son droit en lecture, ACKn pour acknowledge qui signifie que la mémoire centrale répond favorablement à une requête de demande en écriture (INvRQ) de l'entité n. La figure A.3 propose deux scénarios, l'un occupant la partie gauche de la figure et l'autre la partie droite. Celui de gauche est un retour au droit de lecture (SH) de l'ensemble des entités. D'abord, l'entité C2 est dans l'état DR qui signifie qu'elle a le droit de modifier sa copie du bloc. Les autres entités, y compris la mémoire centrale, sont dans l'état INV qui signifie qu'elles ont une copie incorrecte du bloc. Les capsules C1, C3 et C4 émettent une demande d'une copie correcte du bloc (BLCL) et se mettent dans l'état BLWT. Aucune information sur le placement relatif dans le temps de ces trois émissions n'est connue, car aucune dépendance chronologique n'est spécifiée sur le chronogramme de la figure A.3. La requête de la capsule C1 est reçue la première par la mémoire centrale. La mémoire centrale n'a pas de copie correcte du bloc: elle émet vers la capsule C2 une demande de copie correcte de bloc (BLCL2) et se met dans l'état SP; la capsule C2 est la seule entité a posséder une copie correcte du bloc (BL2). A la réception du message la capsule C2 envoie à la mémoire centrale une copie correcte du bloc. La capsule C2 prend dès lors l'état SH car elle ne peut plus écrire. À la réception de la copie du bloc la mémoire centrale se met dans l'état SH, car elle possède maintenant une copie correcte du bloc. Et elle émet vers les capsules C1, C3 et C4 une copie correcte du bloc (BL1, BL3 et BL4). Elle émet ces trois messages car elle a reçu de chacune de ces trois capsules une demande de copie correcte du bloc. Chacune de ces trois capsules reçoit une copie correcte du bloc et passe immédiatement dans l'état SH. Le scénario de droite est une obtention des droits d'écriture de la capsule C1. À l'issue du scénario de gauche toute les entités sont dans l'état SH, elles peuvent toutes lire. Les capsules C1 et C3 émettent vers la mémoire centrale une demande en écriture (INvRQ) et se mettent dans l'état INVWT. La requête de la capsule C1 arrive la première. Dès réception de cette requête, la mémoire centrale passe dans l'état INV et émet un quitus vers la capsule C1 (AcK1). La mémoire centrale diffuse également aussitôt un message d'invalidation vers toutes les autres capsules 02, C3 et C4 (INvBR2, INVBR3 et INVBR4). À la réception du quitus, la capsule C1 passe dans l'état DR: elle a le droit de modifier sa copie du bloc. A la réception de l'ordre d'invalidation les autres capsules passent dans l'état INV: elles perdent leur droit de lecture. De plus, la capsule C3 interprète la réception du message INvBR3 comme un refus de la mémoire centrale. La mémoire centrale, elle, ne répondra jamais au message INvRQ3 car elle considère que le message INVBR3 qu'elle a émis vaut pour une réponse. Le bilan de ces deux scénarios est le passage du droit en écriture de la capsule C2 à la capsule C1. Par hypothèse, il n'y a qu'un bloc dans ce modèle: c'est un modèle pour jouer. Ce type de spécification se pratique très tôt dans le processus de conception. Un des mobiles importants du développement de CHLOE, est de permettre aux concepteurs de récupérer ces épures initiales afin de vérifier si elles sont respectées par les modèles complets et très raffinés qu'ils produisent dans les étapes terminales du processus. Con- sidérant un chronogramme comme celui de la figure A.3, il est possible d'en extraire des propriétés qui peuvent être des propriétés du modèle terminal. Supposons que l'on passe une règle de gauche à droite du chronogramme en la maintenant perpendiculairement aux flèches représentant les entités. On peut alors noter que certains états semblent s'exclure les uns les autres, par exemple SH et DR ou DR avec lui-même, alors que d'autres sem- blent s'impliquer, par exemple DR et INV. Par ailleurs, chaque épaississement et chaque rétrécissement des flèches horizontales représente une transition interne à l'entité corre- spondante. La transition se produit à la réception ou à l'émission d'un message. Ces transitions aussi peuvent être spécifiées dans le Langage de chronogrammne afin de voir si elles se déroulent comme souhaité. A.3 Sa validation A.3.1 Extraction de quelques propriétés De l'ensemble des propriétés que l'on peut vouloir lire sur la figure A. 3, trois sont refor- mulées sur la table A.1. Va, b E {CM, C1, C2, C3, C4} a 9 b DR(a) => INV(b) Cette propriété ne peut pas être vraie. Va, b E {CM, C1, C2, C3, C4} a # b DR(a):t -DR(b) nl est essentiel que cette propriété soit vraie. INV(C4) BRD(C4) BLWT(C4) INv(C4)BLCL(C4)- Cette propriété va servir de démonstration Table A.i: Trois propriétés possibles du contrôleur Dans les expressions de cette table, le fait que l'entité a soit dans l'état DR est noté DR(a). Cette notation est générique. 1. La première propriété est naïve mais intéressante. En effet, au premier abord, il peut paraître saint que l'autorisation d'écrire ne puisse se produire que lorsque toutes les entités ont invalidé leur copie de bloc. En réalité le fait que le temps de transit des messages ne soit pas nul nécessiterait une complication considérable du protocole pour que cette propriété soit satisfaite. En revanche, les états globaux du système tels qu'une entité a le droit d'écrire alors qu'une autre a le droit de lire doivent être transitoires, c'est-à-dire que de tels états résultent uniquement du fait qu'une entité a déjà acquis le droit d'écrire alors qu'une autre entité n'a pas encore perdu le droit de lire, mais qu'elle va le perdre. Un état global est transitoire s'il existe un message en transit qui à sa réception provoquera une transition locale qui modifiera l'état global. Dans cet exemple le message serait une INVBR: considérer la figure A.3 et imaginer que le message INVBRl traîne en route. CHLOE offre un dispositif de diagnostic qui permet de repérer les états transitoires. 2. La deuxième propriété peut être considérée cornmme la propriété fondamentale de ce protocole: deux processeurs ne peuvent pouvoir écrire simultanément dans deux copies d'un même bloc; les écritures doivent être totalement ordonnées. 3. La troisième propriété est une simple transition. Elle servira de test. Ici, apparaît la requête RD, émise par le processeur encapsulé dans la capsule. A.3.2 Leur expression sous CHLOE La figure A.3 et la table A.1 faisaient référence à un modèle abstrait du protocole. Ce modèle qui reste implicite dans ce rapport utilise des symboles pour définir le protocole: DR, SH, INVBR... Le modèle simulable écrit en VHDL définit le même protocole à partir de signaux de type vecteur de bits. Les symboles du modèle abstrait sont donc encodés dans des vecteurs de bits. Cet encodage est donné dans la table A.2 suivante. Les noms mentionnés dans la colonne de gauche sont les identificateurs de signaux du modèle VHDL. La deuxième colonne propose pour chacun de ces signaux plusieurs valeurs. La troisième colonne donne pour chacune de ces valeurs une brève explication de son sens. Enfin la quatrième colonne fournit le symbole correspondant dans le modèle abstrait. Les signaux de cette table sont internes aux capsules, aussi on n'y retrouve pas les mêmes identificateurs que sur la figure A.3. Le signal cm-out porte les messages émis vers la mé- moire centrale. Le signal cmmin porte les messages reçus venant de la mémoire centrale. Les signaux dir et act portent l'état interne de la capsule. Le modèle VHDL est syn- chrone. Son exécution est entièrement cadencée par l'horloge ck. Cette synchronisation forte impose de faire transiter des messages vides. Ces messages n'apparaissent pas dans le modèle abstrait; aucun symbole ne leur est donc associé. Dans le modèle VHDL, les capsules étant réduites à l'automate de contrôle de leur mémoire cache, l'environnement doit émettre les requêtes de lecture et d'écriture: dans le modèle complet ces requêtes sont émises par les processeurs encapsulés dans la capsule. Ces requêtes émisent par l'environnement sont portées par le signal pri. n. Enfin un contrôle de charge des file d'attente qui sont finies dans le modèle VHDL est assuré. Le signal linein permet d'effectuer un retour sur les capsules afin de gérer les débordements. ck: horloge commune prtin: "00" pas de message "01" demande en lecture (RD) "10" demande en ecriture (WR) cmin: "000" pas de message "001" copie d'un bloc (BL) "010" appel de bloc (SP) "011" ordre invalidation (INvBR) "100" quitus (AcK) cmout. "00" non significatif "01" copie de bloc (BL) "10" appel de bloc (BLCL) "11"i demande invalidation(INvRQ) line.in: '0' ligne invalide 1' ligne valide dir: "00" etat invalide (INV) "01" etat partage (SH) "10" etat proprietaire (DR) act: "01" etat repos (CcIDL) "11" etat attent bloc (BLWT) " 10" etat attent quitus (INvWT) Table A.2: La table d'encodage des symboles Pour valider le modèle VHDL, il faut établir la relation entre les propriétés exprimées au niveau du modèle abstrait et le modèle VHDL. Cela ne consiste pas uniquement à vérifier si telle ou telle propriété appartient ou non au modèle, mais aussi à tester des propriétés dont on ne sait pas si elles appartiennent au modèle, par exemple la première propriété de la table A.1 dont, en fait, une approximation acceptable seulement appartient au modèle VHDL: si on omet les états transitoires, il est vrai que Va, b E {CM, Cl, C2, C3, C4} a # b DR(a) > INV(b). Cette propriété est donc l'implication de l'état INV par l'état DR. La figure A.4 montre le chronogramme primitif définissant cette propriété dans le cadre du modèle VHDL. Ce chronogramme définit l'instance de cette propriété pour a = C2 et b = C3. Ceci nous amène immédiatement à faire remarquer que devoir considérer comme cela les différentes instances d'une propriété générique peut vite devenir fastidieux. Un mécanisme de paramétrisation des identificateurs d'items, ou de signaux, doit être mis en oeuvre dans l'éditeur. Figure A. 4: L'implication de l'état INV par l'état DR ck: horloge commune dir: "00" etat invalide (INV) "10" etat proprietaire (DR) Table A.3: Extrait de la table d'encodage Cette propriété est une contrainte sur un seul cycle d'horloge. La table A.3 donne un extrait de la table A. 2 qui permet de lire le chronogrammne de la figure A.4. L'horloge maîtresse est donc identifiée par ck. L'état interne de la capsule C2 de symbole DR est donc encodé par le vecteur de bits C2_dir portant la valeur (1,0), c'est-à-dire le bit de poids fort de C2_dir, identifié sur le chronogramme par C2_dir_1, est à 1, et son bit de poids faible, identifié sur le chronogramme par C2_dir_0, est à 0. Ainsi la scène hypothèse, la scène du haut, spécifie que la capsule C2 doit être dans l'état de symbole DR. Une lecture semblable de la figure A.4 et de la table A.3 permet de voir que la scène conclusion, la scène du bas, spécifie que la capsule C3 doit être dans l'état de symbole INV. Le sens des deux scènes superposées est: à chaque cycle de 7l'orloge ck, si la capsule C2 est dans l'état de symnbole DR alors la capsule C3 doit être dans l'état de symbole INV. Les figures A.5 et A.6 et la table A.4 permettent d'introduire comment la propriété Va, b E {CM, C1, C2, C3, C4} a # b DR(a) = -DR(b) peut être définie par un chronogramme. Cette propriété définit l'incompatibilité de l'état de symbole DR avec lui même: jamais deuz capsules distinctes ne peuvent avoir simul- tanément le droit d'écrire. Cette propriété pour être écrite aisément nécessite de spécifier la contrainte: telle capsule ne doit pas être dans l'état de symbole DR. Ceci peut ce faire sous CHLOE en niant une scène. Figure A.5: La négation La question de l'apparence visuelle de la négation sur un chronogramme n'a pas encore été tranchée. Pour les chronogrammes à flèche, dits évolués, il est possible de s'inspirer du complémentaire tel qu'il est dessiné sur les plans de circuits à porte. Pour les chrono- grammes primitifs la question reste plus largement ouverte: changement de couleur, inversion vidéo... Sémantiquement, la négation est un plus considérable. Pour aug- menter autant que possible la puissance d'expression du Langage de chronogramme, la possibilité de nier est laissée partout: on peut nier un intervalle, un bloc, une ligne, une aire ou multicolonne, une scène et un chronogramme tout entier. On peut utiliser plusieurs fois la négation dans un chronogramme. L'ergonomie est sans doute le revers de la médaille. En effet, en niant habilement plusieurs niveaux d'un chronogramme, il est possible de définir des propriétés inattendues pour ce mode d'expression. Une confusion sur le sens de certains chronogrammes pourrait s'en suivre. Peut-être faudra-t'il limiter l'usage de la négation. e - -"'-.::.;gI - - -I - 1*;I e - - I ''-_ I EE _jj] a L.. Iû Bz I -I IIIt.F Figure A.6: L'excluivté de l'état DR i-, sr--;- # 0 ''e - M --v,-a r j-. Figure A.6: L'exclusivité de l'état DR ck: horloge commune dir "10" etat proprietaire (DR) Table A.4: Extrait de la table d'encodage La figure A.6 montre un chronogramme dont les scènes hypothèse et conclusion sont identiques aux capsules concernées près: la scène hypothèse, celle du haut, définit une contrainte sur le signal dir de la capsule C1, alors que la scène conclusion, celle du bas, définit la même contrainte sur le signal dir de la capsule C2. Cette contrainte est: La capsule doit être dans l'état de symbole DR. Ainsi en niant la scène conclusion on définit la propriété:Pour tout cycle de l'horloge ck, si la capsule Cl est dans l'état de syrmbole DR, alors la capsule C2 n'est pas dans l'état de symbole DR. La figure A.7 et la table A.5 propose la définition par chronogramme d'une propriété appelant aussi l'utilisation de la négation. Il s'agit de l'incompatibilité des états de sym- boles SH et DR. Dem O I -' _c - _ t {[[ iiE A..... c7 _, _, Figure A7: L'exclusion des états DR et SH c: horloge commune di: "10" etat proprietaire (DR) ô"01 etat partage (SH) Table A.5: Extrait de la table d'encodage La scène hypothèse, celle du haut, définit la contrainte: La capsule C1 est dans l'état de symbole DR. La scène conclusion, celle du bas, définit la contrainte: La capsule C2 est dans l'état de symbole SH. En niant la scène conclusion, on définit la propriété: Pour tout cycle de l'horloge ck, si la capsule C1 est dans l'état de symbole DR, alors la capsule C2 n'est pas dans l'état de symbole SH. Attention, cette propriété est fausse. Ces états peuvent coexister si un message INVBR est en transit. Le chronograrnme de la figure B.1, page 187, définit la transition d'une capsule à la réception d'une requête de lecture (RD) en l'absence d'une copie correcte du bloc dans la mémoire cache de la capsule (INv). INV(C4) RD(C4) BLWT(C4) VL L(C4) Ici, cette propriété est formulée pour la capsule C4. La table A.6 fournit l'extrait de la table d'encodage qui permet de décoder le chronogramme Figure B.1. ck: horloge commune prin: "01" demande en lecture (RD) cm-out "10' appel de bloc (BLCL) dir: "'00' etat invalide (INv) act: "11 etat attent bloc (BLWT) Table A.6: Extrait de la table d'encodage À la lecture de cette table, il est possible de récrire la transition comme suit: dir = (0,0) 0 Ut( act-(1,1) =o-:,o),ac --'(1,0 1) Cette propriété définit une contrainte sur deux cycles de l'horloge ck. Elle permet d'illustrer une grande qualité des chronogrammes. Un des aspects délicats de la défi- nition et de la mise en oeuvre des transitions d'un système est la synchronisation. Une transition suit toujours le modèle intemporel: sur un état donné * réception d'un stimulus, * émission de stimuli, * changement d'état. Partant de ce shéma, il faut définir la chronologie et la chronométrie de ces trois points. Sous le contrôle d'une horloge maîtresse, ceci signifie placer ces trois points aux bons cycles d'horloge. Le chronogramme Figure B.1 spécifie clairement que le message émis l'est dans le même cycle que la réception du stimulus, ici la requête de lecture, tandis que le changement d'état n'est effectif qu'au cycle suivant. De ce point de vue les chronogrammes primitifs sont peut-être plus éloquents que les chronogrammes à flèches. -o _ ___ _ _ ,. -' _i *: -U-_' ' ' - - __t elgr. - ,- -w- - -I I-EP,-' 1 r7 Figure A.8: La transition d'une capsule sur une lecture Vérifier qu'une telle transition est bien mise en oeuvre consiste non seulement à s'assurer de la correction des valeurs portées par les signaux impliqué, mais également, et peut- être surtout, à s'assurer de la correction temporelle de son comportement. Pour cela il est primordial de pouvoir spécifier sans ambiguïté ni complication inutile le modèle de comportement souhaité. A.3.3 Le code généré La structure du code généré par le compilateur de CHLOE est décrite au section 4.1.2. La figure ?? montre comment le code généré peut-être utilisé pour mettre en oeuvre un processus de validation. Le compilateur génère des vérifieurs, encore appelés observateurs ou analyseurs de traces. Dans les environnements VHDL et SIGNAL, Ces vérifieurs peuvent, et doivent, être connectés au modèle à valider. Le schéma-bloc de la figure ?? comprend trois vérifieurs qui prennent chacun en entrée des signaux d'une des trois capsules et émettent chacun un signal booléen. Ces vérifieurs auraient pu être encapsulés complètement dans les capsules. Ce nouveau modèle ainsi construit a des propriétés très intéressantes pour la validation du modèle initial du point de vue de la ou des propriétés représentées par les vérifieurs. Pour les propriétés dites de sûreté, le fait que le modèle initial les vérifie ou non se lit directement sur les états du nouveau système. Pour les propriétés dites de vivacité, le fait que le modèle initial les vérifie ou non se déduit de l'existence de circuits dans un sous-graphe du graphe d'état du nouveau modèle. Ce sous-graphe se calcul à partir d'une simple lecture des états du nouveau modèle. La validation peut se faire soit par simulation soit par des techniques de preuve formelle. Il est évident que la preuve exhaustive ne peut pas être obtenue dans le cadre de la simulation. On donnera dans l'annexe un exemple de génération de code SVHDL. A.3.4 La simulation: quelques traces Les tables A.? et A.8 donnent les traces complètes de la simulation du modèle VHDL montré sur la figure ??. Cette simulation a été faite par le simulateur SYNOPSIS. 04. 00 00,.0.0 -' O ooo.0 21 wu,,"- 1,, Villa ""'" 0i Ii:m"m 4 Pa S I PlMii - Me ow.4 taU93P939 Pûq t-u. I qbu, t- 2 0 0 0 bc OOOOUOOI__lonJO J", opâà,oo,PR aattJ l rol roll0 000 6 4 16 0 -i. id monitor active CLUSTER*/OK sur la sortie de chaque vérifieur. Dans le modèle qui a servi pour la simulation, les vérifieurs sont encapsulés dans les capsules. La partie intéressante de ces traces est reprise dans la table A.9. La simulation s'est faite sur un cycle d'horloge tous les vingt nanosecondes, ce qui fait une simulation de vingt sept cycles d'horloge en tout. Chaque fois que la valeur d'un signal change, elle est affichée. Lorsque la propriété est violée par une des capsules, la valeur du signal de sortie du vérifieur de la capsule est 0, autrement elle est 1. Initialement les signaux de sortie des vérifieurs sont à 1. 0 NS Ml:.. /CLUSTER0/OK (value = '1') M2:.. /CLUSTER1/OK (value = '1') M3:... /OK (value = '1') Ml:.. /CLUSTER0/OK (value = '1') M2:.. /CLUSTER1/OK (value = '1') M3:.../OK (value = '1') NS M3:... /CLUSTER0/OK (value = '0') M2:... /CLUSTER1/OK (value = '0') Ml:.. /CLUSTER2/OK (value = '0') NS Assertion WARNING at 40 NS in... /CLUSTER0/...: "PROP is violated! "..DTD: Assertion WARNING at 40 NS in... /CLUSTER1/...: "PROP is violated! " Assertion WARNING at 40 NS in... /CLUSTER2/...: "PROP is violated! " M3:... /CLUSTER0/OK (value = '1') M2:.. /CLUSTER1/OK (value = '1') Ml:... /CLUSTER2/OK (value = '1') 540 NS Table A.9: Morceaux choisis des traces de simulation Les traces de simulation montrent que dès le premier cycle d'horloge les signaux de sortie des vérifieurs passent tous à 0. La propriété est donc violée ce qui provoque l'écriture de messages d'avertissement lors du cycle suivant. Au deuxième cycle d'horloge, les signaux de sortie des trois vérifieurs repassent à 1. Ils se stabilisentdéfinitivement... pour cette simulation! L'interprétation de ces résultats peut être qu'il y a des erreurs d'initialisation de certains signaux puisqu'après le premier cycle tout semble se passer normalement. En fait, une autre interprétation peut être faite: les tests choisis ne mettent jamais le système dans un état o la transition testée pourrait s'allumer; la contrainte définie par la scène hypothèse n'est jamais respectée sauf à l'instant initial, donc, sauf à l'instant initial, la propriété est toujours satisfaite. Pour s'en assurer il suffit d'installer aussi un afficheur sur le signal de sortie du vérifieur de l'hypothèse. La compilation doit rendre ce signal disponible. Il est tout-à-fait envisageable de truffer le modèle de vérificateurs. Dans ce cas il peut être astucieux de résumer les résultats des tests à l'aide d'autre chronogrammes. On peut ainsi mettre en oeuvre sur un mode hiérarchique une vérification très sophistiquée. Cette possibilité devrait pouvoir s'avérer très utile pour la pause de diagnostic. A.3.5 La preuve: quelques traces -rig.I-trasm -w2 -codp -r 10 -stop 10 vImp4. l.fam vImp4ir-t.fam -.............------......-.-..* se,.. Compute Vaid States of PSM Lod fm... doue. St-teVa: 23. Axiome: 1. Asseot 1: +[1101 -o101 0 +[1022 O +[1023l 0 +[1024 0 +1021 0 1026]111] + [1010l +[101 -[1022 0 +[1023 0 +10214 0 +1102 0 102]]] +11018 -[1022 0 + 11023 0 +[1024 0 +11025 0 1024]]n +[1019 -[102 0 +1102 0 +11024 0 +[102l 0 10261]]m +11020 -[1022 0 +1023 0 +11024 0 +[1021 0 10241]]] +11021 - [1022 0 +11023 0 +11024 0 +[1028 0 1020]1] ln]]]M (101 101i 1017 1018 1019 1020 1021 1022 1023 1024 1025 1020) Ther. mr 1 %sertious! StateVsarl: dir'0/1002, dir'l/1003, ct '0/1004, ct'l/100%, pi'eoe'mcu'liU[e.ct..l'iater_ _un'b'mem/101, p%'hypo'mc'Ugnedir..'it.ter. a._.b'm.m/101I, p'coc'mcuipe e.m out.'ister.-l..u'b'mem/101?, pi %cou*mcu'line:m.out.J'inter -.2ero'b'mem/1010, pI'p'mculeir.. *iner.. jrro*b'mem/1019, pl'hypo'mcugne.d.ir.'it er...ero*b*mem/1020, p%'hpom'euligne.Act..1 Jter.D.L.ubmem/1021, plhypeomcu'le.dirD.2i'jsr.% J.se*'b'mm/1022, phypo*m*line. c..*iter_ l d.cr'b*mm/1023, p1 1ypo'mcu'10e.A0s2 1.0 'i 1 1er0 1-.1. 1.'b'm-m/ 1024, pNrhypofmcu*lpe Prt J*iate r o - dcse*b'mem/1025, pl*hypo'mcu'Ua e.pr 1 - Le'itter.oJ. d_ re*bsmem/o02q, plehypo*mcu'lis.pr- J e'itero d s..s.- 'b'mem/1027, ptrhypo'mctm'S et tpra e tt.i er.e.s erob'mlm/102c, p llhs po'mune*gtravere.x.usiiv e r a.- Leao*b'meom/derr, pls*.ird/.103/0, pl*s.prDl.0/1031, p%'sm.out.1L/1032, plm't ir;-/1033, Dim: 23 (1002 1002 1004 1008 1015 1010 101? 1015 1019 1020 1021 1022 1023 1024 1035 1020 102?7 10% 100 10%0 1031 102X 103>) hait.G: 2A Number of Stste8 o Quel que soit ce que l'on déduit d'une simulation, le champs de validité de ces déduc- tions est strictement limité par les tests. Les tables A.10 et A.11 montrent les traces com- plètes d'une traversée exhaustive du graphe d'état du système. L'algorithme de traversée est mis en oeuvre sur une représentation symbolique du système basée sur les diagrammes de décision [?]. curr- -at- -ci.tp- t- n..... per- ---eou -rat- 23 1 1.00 0.0 o/ 0/ 0 O 23 1 ( 0, 0123 1 23 1 t1. 00 131066(8.42 %) 0 23 1 1.00 0.01 1/ 0/ I 64 20 64 20 1 64, 20, 7781931 e4 20 l1 21 5." 13104"(12.9 %) 0 64 20 7.19 0.01 1/ 0/ 2 83 112 e91 92 1 43, 24,7927691 91 92 100 113 2.99 131o04(72.32) o 91 92 23.25 0.02 1/ 0/ 3 135 384 e1 272 [, o.,0,611 91 272 10 387 60.03 131066(4.73 %) 0 91 2:2 68.15 0.02 il/ 0/ 4 7 644 137 272 [ 0, 0.700411 13 272 202 6T7 74.81 13100d40.40 0%) 0 131 272 46. 66 0.04 1/ 0/ a 213 784 1 400 0. 0,760861] 11 400 22 1087 94.47 131068(13.04 %) 0 119 400 77.31 0.04 1/ 0/ o 220 784 97 272 [ 0. 0, 70861] 97 272 265 1329 116.36 H2136 -[1002 +11003 +11004 o-1100os o...] +1100o 1...j1 +1LO04 +1100 1...1 + DOS... 1.]] +[1003 +11004 +[100O 1...J 2] 1J] Write fam.. done. Memory Statue of TDGLIB. AUocated: 202136 bytes; Unused: 260048 bytes (99.43 %); Lost: 0 bytes Vertices: 0. Active: 0 Vertices actue&lly found: 0 -rigel. Table A.11: Les traces complètes (suite) de traversée symbolique Le détail de ces traces n'est pas important sinon qu'en y regardant de près on peut observer que les identificateurs de signaux du modèle VHDL ne sont pas perdus, ce qui est une porte ouverte à l'aide au diagnostic. La partie intéressante de ces traces est montrée sur la table A.12. L'algorithme de traversée symbolique marche selon un principe maintenant connu [?]: 1. prendre l'ensemble des états initiaux (InitG), c'est souvent un singleton, si InitG est vide alors aller au point 9; 2. calculer l'ensemble des états qui sont successeurs immédiats de l'un des états ap- partenant à Init.G, c'est l'ensemble des successeurs immédiats (next), si next est vide alors aller au point 9; 3. créer le complémentaire de InitG dans next, cet ensemble est l'ensemble des états nouveaux (nev), si nev est vide alors aller au point 9; 4. créer l'union de next et de Init.G, cet ensemble est l'ensemble des états atteints (ail); 5. calculer l'ensemble des états successeurs immédiats de nev, c'est le nouveau next, si next est vide aller au point 9; 6. créer le complémentaire de next dans all, c'est le nouveau nev, si nev est vide alors aller au point 9; 7. créer l'union de next et de all, c'est le nouveau all; 8. aller au point 5. 9. sortir. La table A.12 montre que la traversée exhaustive du graphe d'état du modèle s'est faite en sept tours de boucle. Pour chaque tour de boucle sont affichés les cardinaux des ensembles créés. L'ensemble curr est une simple copie de l'ensemble nev qui sert pour calculer le nouveau next. L'ensemble test est l'ensemble des nouveaux états atteints qui violent la propriété. La colonne correspondante donne donc le nombre d'états nouveaux atteints qui violent la propriété. Pour l'aide au diagnostic, des outils d'exploration de l'ensemble test peuvent être développés; l'ensemble test peut être très gros. Compute Valid States of FSM Load fsm... done. StateVars: 23. Axioms: 1. There are 1 assertions! Dim: 23 Number of States of InitG: 1 curr step next new test all 1 0 0 1 0 1 1 1 20 20 20 21 2 112 92 24 113 92 3 384 272 0 385 272 4 544 272 0 657 272 5 784 400 0 1057 400 6 784 272 0 1329 272 7 544 O O 1329 Write fsm... done. Table A.12: Morceaux choisis des traces de traversée symbolique À un état du modèle à valider est associé plusieurs états dans le nouveau modèle, le modèle à valider augmenté des vérifieurs. Les états obtenus pour un état du modèle initial dépendent des chemins qui y mènent, dans le nouveau modèle. Ceci doit permettre de construire un outil d'aide au diagnostic basé sur l'analyse de l'ensemble test. Annexe B Un Exemple de génération SVHDL B.1 La génération du code Le compilateur génère des vérifieurs, encore appelés observateurs ou analyseurs de traces. Dans les environnements VHDL et SIGNAL, ces vérifieurs peuvent, et doivent, être con- nectés au modèle à valider. Le schéma-bloc de la figure ?? comprend trois vérifieurs qui prennent chacun en entrée des signaux d'une des trois capsules et émettent chacun un signal booléen. Ces vérifieurs auraient pu être encapsulés complètement dans les capsules. Ce nouveau modèle ainsi construit a des propriétés très intéressantes pour la validation du modèle initial du point de vue de la ou des propriétés représentées par les vérifieurs. La validation peut se faire soit par simulation soit par des techniques de preuve formelle. Nous allons ici donner un exemple de génération de code VHDL pour une propriété de sûreté du système présenté dans l'annexe A Voici le chronogramme correspondant à cette propriété: [. ,d [. i [ [ [v de _ _____ * " l'hypothèse library d;s-paris-lib; use ds parislib p.parispack. all; l'hypothèse- lirr dl...arsjb us ds..pais.s.pai..akal entity XHMLI is port ( ck: in bit; SIG: in bit; ZSIG: in bit; OKI: in bit; OKO: out bit ); Attribute clock of ck: signal is true; end XH_MLI; Architecture ZERO_1 of XHMLI is begin b:block signal MEM: bit:= '1'; begin b:block(not ck'stable) begin OK_O ≤ MEM; end block; process (ck'stable, SIG, Z_SIG, OK_I) begin if not ck'stable then if OKI = '1' then MEM ≤ not SIG; else EME ≤ '0'; end if; end if; end process; end block;end ZERO_1; Architecture DCARE_1 of XHMLI is begin b:block signal HEM: bit:= '1'; begin b:block(not ck'stable) begin OKO ≤ MEM; end block; process (ck'stable, SIG, Z_SIG, OK_I) begin if not ck'stable then MEM ≤ OKI; end if; end process; end block; end D_CARE_1; Architecture UN_1 of XHMLI is begin b:block signal MEM: bit:= '1'; begin b:block(not ck' stable) begin OKO ≤ MEM; end block; process (ck'stable, SIG, Z_SIG, OK_I) begin if not ck'stable then if OKI = '1' then HEM ≤ SIG; else MEM ≤ 'o'; end if; end if; end process; end block; end UN_1; B.3 Le code SVHDL pour les lignes de l'hypothèse library dlsparislib; use dlsparislib.parispack.all; entity XHML is port ( ck: in bit; SIG: in bit; ZSIG: in bit; OKSTART: in bit; OKEND: out bit ); Attribute clock of ck: signal is true; end XH_ML; Architecture dir_1_1 of XHML is component XHMLI port ( ck: in bit; SIG: in bit; ZSIG: in bit; OKI: in bit; OKO: out bit ); end component; for INTEROlZERO: XHMLI use entity work.XHMLI(ZERO_1); signal OKEND_1: bit:= '1'; for INTER_1_2_DCARE: XHMLI use entity work.XHMLI(DCARE_1); begin INTERO__.1ZERO: XHMLI port map (ck, SIG,ZSIG,OKSTART, OKEND_1); INTER_1_2_DCARE: XHMLI port map (ck, SIG,ZSIG,OK_END_1, OK_END); end dir_1_1; Architecture dir_0_2 of X_H_ML is component XHNLI port ( ck: in bit; SIG: in bit; ZSIG: in bit; OKI: in bit; OKO: out bit ); end component; for INTERO__1ZERO: XHMLI use entity work.XHMLI(ZERO_1); signal OKEND_1: bit:= '1'; for INTER_1_2_DCARE: XHMLI use entity vork.XHMLI(DCARE_1); begin INTER_0_1ZERO: XHMLI port map (ck, SIG,ZSIG,OKSTART, OKEND_1); INTER_1_2_DCARE: XHMLI port map (ck, SIG,ZSIG,OKEND_1, OKEND); end dir_O_2; Architecture actO_3 of XHML is component XHMLI port ( ck: in bit; SIG: in bit; ZSIG: in bit; OKI: in bit; OKO: out bit ); end component; for INTERO_1_ZERO: X-_HMLI use entity vork.XHMLI(ZERO_1); signal OKEND_1: bit:= '1'; for INTER_1_2_DCARE: XHMLI use entity work. XHHLI(DCARE_1); begin INTER.01__ZERO: XHMLI port map (ck, SIG,ZSIG, OKSTART, OKEND_1); INTER_1_2_DCARE: XHMLI port map (ck, SIG,ZSIG,OKEND_1, OKEND); end actO_3; Architecture actl_4 of XHML is component XHHMLI port ( ck:in bit; SIG:in bit; ZSIG:in bit; OKI:in bit; OKO:out bit ); end component; for INTERO_1_UN: XHMLI use entity work.XHM. LI(UN_1); signal OKEND_1: bit:- '1'; for INTER_1_2_DCARE: XHMLI use entity vork.XHN_L_I(D_CARE_1); begin INTERO_1_UN: XHMLI port map (ck, SIG,ZSIG,OKSTART, OKEND_1); INTER_1_2_DCARE: XHMLI port map (ck, SIG, ZSIG,OKEND_1, OKEND); end act_1_4; Architecture prin_0_5 of XHML is component XHMLI port ( ck: in bit; SIG: in bit; ZSIG: in bit; OKI: in bit; OKO: out bit ); end component; for INTERO_1_ZERO: XHMLI use entity vork.XHH_ML_I(ZERO_1); signal OKEND_1: bit:- '1'; for INTER_1_2_DCARE: XHNLI use entity work.XHMLI(DCARE_1); begin INTER_01. _ZERO: XHMLI port map (ck, SIG,ZSIG,OKSTART, OK_END_1); INTER_1_2_DCARE: X_HMLI port map (ck, SIG,ZSIG,OK_END_I, OK_END); end prin_0_5; Architecture prin_1_6 of X_H_M_L is component XH_M_LI port ( ck: in bit; SIG:in bit; ZSIG:in bit; OKI: in bit; OKO: out bit ); end component; for INTER_0_1_UN: XHM_L_I use entity work.XHMLI(UN_1); signal OKEND_1: bit:- '1'; for INTER_1_2_DCARE: XH_M_L_I use entity vork. XHM_L_I(D_CARE_1); begin INTER_01__UN: XHMLI port map (ck, SIG,ZSIG, OKSTART, OKEND_i); INTER_1_2_DCARE: XHMLI port map (ck, SIG,ZSIG,OKEND_1, OKEND); end prin_1_6; B.4 Le code SVHDL pour la zone de l'hypothèse library dlsparislib; use dlsparislib.paris_pack.all; entity XHM is port ( ck: in bit; dirl,Zdir_.l,dir_O,Z_dirO,actO,Z_actO,act_1,Zact_1, pr_in_O,ZprinO,pr_inl.,Zprin_1: in bit; OKSTART: in bit; OKEND: out bit ); Attribute clock of ck: signal is true; end X_H_M; Architecture ARC of XHM is component XHML port ( ck: in bit; SIG: in bit; Z._SIG: in bit; OKSTART: in bit; OKEND: out bit ); end component; for LIGNEdir_1_1: XHML use entity vork.X.HHL(dir_1-1); signal OKENDdir_1_1: bit: '1'; for LIGNEdir_0_2: XHHL use entity vork.XHHL(dirO_2); signal OKENDdir_0_2: bit: '1'; for LIGNEactO_3: XHML use entity work.XH_- _L(actO_3); signal OKENDactO_3: bit: '1'; for LIGNEact_1_4: XHML use entity vork.X_H_H_L(act_1_4); signal OKENDact_1_4: bit:= '1'; for LIGNEprinO_5: XHML use entity work.X_H_M_L(pr_in_0_5); signal OKENDprin_0_5: bit:= 1'; for LIGNEprin_1_6: XHML use entity vork. XHML(prin_1_6); signal OKENDprin_1_6: bit:= '1'; begin b:block(not ck'stable) begin OKEND ≤ OKENDdir_1_1 AND OKENDdirO_2 AND OKENDact_0_3 AND OKENDact_1_4 AND OKENDprinO_5 AND OKENDprin_1_6; end block; LIGNEdir_1_1: XHML port map (ck, dir_1,ZdirI,OKSTART, OKENDdir_1_1); LIGNEdir_0_2: XHML port map (ck, dir_O,Z_dir_O,OK_START, OKENDdirO0_2); LIGNEactO_3: XHML port map (ck, act_O,ZactO,OK_START, OK_ENDactO0_3); LIGNEact_1_4: XH__ML port map (ck, act1_l,Zactl,OK_START, OK_END_act_1_4); LIGNEprinO_5: XHML port map (ck, pr_inO,ZprinO,OKSTART, OKEND_pr_in_0_5); LIGNEprin_1_6: XHML port map (ck, pr_in_1,Z_pr_in_l, OKSTART, OKENDprin_1_6); end ARC; B.5 Le code SVHDL pour la scène de l'hypothèse library dlsparislib; use dlsparislib.parispack.all; entity XH is port ( ck: in bit; dir_,Z_dir_l,dirO,Z_dir_O,actO,ZactO,actl1, Z_act_1, prinO,ZprinO,prinl,Zprin_1: in bit; OKSTART: in bit; OKEND: out bit Attribute clock of ck: signal is true; end XH; Architecture ARC of XH is component XHM port ( ck: in bit; dir_1,Zdir_ l,dir_O,Z_dirO,act_O,Z_actO,act_1,Zact_1, prinO,ZprinO,prinl,Zpr_in_l: in bit; OKSTART: in bit; OKEND: out bit ); end component; for all: XHH use entity vork.XHM(ARC); signal OKEND_1: bit:= '1'; begin b:block(not ck'stable) begin OKEND ≤ 0KEND_1; end block; MCU: XHM port map (ck, dirl,Z_dirl,dir_O,Z_dir_O,actO,ZactO, actl,Z_act_l, prinO,ZprinO,prinl,Z_pr_in_1, OKSTART, OK_END_1); end ARC; B.6 Le code SVHDL pour les intervalles de la con- clusion library dls_parislib; use dlsparislib.parispack.all; entity XCMLI is port ( ck: in bit; SIG: in bit; ZSIG: in bit; OKI: in bit; OKO: out bit Attribute clock of ck: signal is true; end X_C_M_L_I; Architecture DCARE_1 of XCMLI is begin b:block signal MEM: bit:= '1'; begin b:block(not ck'stable) begin OKO ≤ MEM; end block; process (ck'stable, SIG, Z_SIG, OK_I) begin if not ck'stable then HEM ≤ OKI; end if; end process; end block; end D_CARE_1; Architecture ZERO_1 of XCMLI is begin b:block signal HEM: bit:= '1'; begin b:block(not ck'stable) begin OKO end block; process (ck'stable, SIG, ZSIG, OKI) begin if not ck'stable then if OKI = '1' then MEM MEM ≤ '0'; end if; end if; end process; end block; end ZERO_1; Architecture UNI1 of XCMLI is begin b:block signal HEM: bit:= '1'; begin b:block(not ck'stable) begin OKO ≤ MEM; end block; process (ck'stable, SIG, ZSIG, OK_I) begin if not ck'stable then if OKI = '1' then MEM ≤ SIG; else HEM ≤ 'O'; end if; end if; end process; end block; end UN_1; B.7 Le code SVHDL pour les lignes de la conclusion library dlsparislib; use dlsparislib. parispack.all; entity XCML is port ( ck: in bit; SIG: in bit; ZSIG: in bit; OKSTART: in bit; OKEND: out bit Attribute ock of ck;signa is true; Attribute clock of ck: signal is true; end X_C_M_L; Architecture dir_1_1 of XCML is component XCMLI port ( ck: in bit; SIG: in bit; ZSIG: in bit; OKI: in bit; OKO: out bit ); end component; for INTERO_1_DCARE: XCMLI use entity vork.XCMLI(DCARE_1); signal OKEND_1: bit:= '1'; for INTER_1_2_ZERO: XCMLI use entity work. X_C_M_L_I(ZERO_1); begin INTERO01__DCARE: XCMLI port map (ck, SIG,ZSIG, OK_START, OK_END_1); INTER_1_2_ZERO: XCMLI port map (ck, SIG,ZSIG, OKEND_1, OKEND); end dir_1_1; Architecture dir_0_2 of XCML is component XCMLI port ( ck: in bit; SIG: in bit; ZSIG: in bit; OKI: in bit; OKO: out bit ); end component; for INTERO_1_DCARE: XCMLI use entity vork.XCMLI(DCARE_1); signal OKEND_1: bit: '1'; for INTER_1_2_ZERO: XCMLI use entity work.XCMLI(ZERO_1); begin INTERO_1_DCARE: XCMLI port map (ck, SIG,ZSIG,OKSTART, OKEND_1); INTER_1_2_ZERO: XCMLI port map (ck, SIG,ZSIG, OKEND_1, OK_END); end dirO_2; Architecture actO_3 of XCML is component XCMLI port ( ck: in bit; SIG: in bit; ZSIG: in bit; OKI: in bit; OKO: out bit ); end component; for INTERO_1_DCARE: XCMLI use entity vork.XCMLI(DCARE_1); signal OKEND_1: bit:= '1'; for INTER_1_2_UN: XCMLI use entity vork.XCMLI(UN-1); begin INTERO_1_DCARE: XCMLI port map (ck, SIG,ZSIG,OKSTART, OKEND_1); INTER_1_2_UN: XCMLI port map (ck, SIG,ZSIG, OKEND_I, OKEND); end act_O_3; Architecture act_1_4 of XCML is component XCMLI port ( ck: in bit; SIG: in bit; ZSIG: in bit; OKI: in bit; OKO: out bit ); end component; for INTERO_1_DCARE: XCMLI use entity vork.XCMLI(DCARE_1); signal OKEND_1: bit:= '1'; for INTER_1_2_UN: XCNLI use entity work.XCMLI(UN_1); begin INTERO_1_DCARE: XCHLI port map (ck, SIG,ZSIG,OKSTART, OKEND_1); INTER_1_2_UN: XCMLI port map (ck, SIG,ZSIG, OKEND_I, OKEND); end act_1_4; Architecture cmoutO_5 of XCML is component XCMLI port ( ck: in bit; SIG: in bit; ZSIG: in bit; OKI: in bit; OKO: out bit ); end component; for INTERO_1_DCARE: XCMLI use entity vork.XCMLI(DCARE_1); signal OKEND_1: bit:= '1'; for INTER_1_2_UN: XCMLI use entity work.XCMLI(UN_1); begin INTER_0_1_DCARE: XCMLI port map (ck, SIG,ZSIG,OKSTART, OKEND_1); INTER_1_2_UN: X_C_M_L_I port map (ck, SIG, ZSIG,OKEND_I, OKEND); end cmoutO_5; Architecture cmout_1_6 of XCML is component XC_MLI port ( ck: in bit; SIG: in bit; ZSIG: in bit; OKI: in bit; OKO: out bit end component; for INTER_0_1_DCARE: XCMLI use entity work.X_CML_I(D_CARE_1); signal OKEND_1: bit:= '1'; for INTER_1_2_ZERO: XCMLI use entity vork.X_C_M_L_I(ZERO_1); begin INTERO_1_DCARE: XCMLI port map (ck, SIG,ZSIG,OKSTART, OKEND_1); INTER_1_2_ZERO: XCMLI port map (ck, SIG,ZSIG,OKENDI, OKEND); end cmout_1_6; B.8 Le code SVHDL pour la zone de la conclusion library dlsparislib; use dlsparislib.parispack.all; entity XCM is port ( ck: in bit; dirl,Z_dir_ l,dir_O,Z_dirO,actO,ZactO,act_l,Zact_1, cm_outO, Z_cm_out_O,cm_out_l,Z_cm_out_1: in bit; OKSTART: in bit; OKEND: out bit ); Attribute clock of ck: signal is true; end X_CM; Architecture ARC of XCM is component XCML port ( ck: in bit; SIG: in bit; ZSIG: in bit; OKRSTART: in bit; OKXEND: out bit ); end component; for LIGNEdir__11: XCHL use entity vork.XCML(dir.1_1); signal OKENDdir_1_1: bit:= '1'; for LIGNEdir_0_2: XCML use entity vork.XCML(dirO_2); signal OKENDdirO_2: bit:'1'; for LIGNEactO_3: XCML use entity vork. X_C_M_L(act_0_3); signal OKENDact_0_3: bit:- '1'; for LIGNEact_1_4: XCML use entity vork.XC_-_L(act_1_4); signal OKENDact_1_4: bit:- '1'; for LIGNEcaoutO_5: XCML use entity work.X.CML(caoutO_5); signal OKENDcaout_0_5: bit:- '1'; for LIGNEcmout_1_6: XCML use entity vork. X_C_N_L(cm_out_1_6); signal OKENDcaout_1_6: bit:= '1'; begin b:block(not ck'stable) begin OKEND ≤ OKENDdir_1_1 AND OKENDdirO_2 AND OKENDact_0_3 AND OKENDact_1_4 AND OKENDcmoutO_5 AND OKEND_cm_out_1_6; end block; LIGNEdir_1_1: XCML port map (ck, dir_l, Z_dirl,OKSTART, OK_END_dir_1_1); LIGNEdir_0_2: XCML port map (ck, dir_O, Zdir_O,OK_START, OK_ENDdir_0_2); LIGNEact_0_3: XCML port map (ck, actO, Zact_O,OK_START, OK_END_actO_3); LIGNEact_1_4: XCML port map (ck, act_1, Zact_1,OK_START, OK_END_act_1_4); LIGNEcmoutO_5: XCML port map (ck, cm_out_O,Z_cm_out_O,OKSTART, OKENDcmaoutO0_5); LIGNEcmout_1_6: XCML port map (ck, cm_outl,Zcmoutl,OKSTART, OKENDcmout_1_6); end ARC; B.9 Le code SVHDL pour la scène de la conclusion library dlsparislib; use dlsparislib.parispack.all; entity XC is port ( ck: in bit; dir_,Z_dir_l, dir_O,Zdir_O,actO,Z_actO,act_1,Z_act_1, cmout_O,Z_cm_out_O,cmoutl, Z_cmout_1: in bit; OKSTART: in bit; OKEND: out bit ); Attribute clock of ck: signal is true; end XC; Architecture ARC of XC is component XCM port ( ck: in bit; dirl,Z_dirl,dir_O,Z_dir_O,actO,ZactO,actl, Z_act_l, cm_out_O,Z_cm_out_O,caoutl,Z_ coutl: in bit; OKSTART: in bit; OKEND: out bit ); end component; for all: XCM use entity vork. XCM(ARC); signal OKEND_1: bit:= 1'; begin b:block(not ck'stable) begin OKEND ≤ OKEND_1; end block; MCU: XCM port map (ck, dirl1,Zdirl,dirO0,ZdirO,actO0,ZactO,act_1,Zact_1, cm_out_O,Zcm_ z-o_0,cout_1,Zcmout_1, OKSTART, OKEND_1) end ARC; B.10 Le code SVHDL pour la propriété library dlsparislib; use dlsparislib.parispack.all; entity X is port ( ck: in bit; dir_l,dir_O,act_O,act_l,pr_in_O,pr_in_1: in bit; dirl,dir_O, act_O,act_l,cm_out_O,cm_out_1: in bit; OKEND: inout bit ); Attribute clock of ck: signal is true; end X; Architecture ARC of X is component XH port ( ck: in bit; dirl,Z_dirl,dl,dirO,Zdir_O,actO,ZactO, act_l,Z_act_1, prinO,ZprinO,prinl,Zpr_in_1: in bit; OKSTART: in bit; OKEND: out bit ); end component; for all: XH use entity vork. XH(ARC); component XC port ( ck: in bit; dir_l,Z_dirl,dir_O,Z_dir_0, actO,ZactO,actl,Zact_1, cm_out_O,ZcmoutO,cm_outl,Zcmout_l: in bit; OKSTART: in bit; OKEND: out bit ); end component; for all: XC use entity work.XC(ARC); signal Zdirl: bit: '1'; signal Zdir_0: bit:= '1'; signal ZactO: bit:= '1'; signal Zact_1: bit:= '1'; signal ZprinO: bit:= '1'; signal Zprin_1: bit:= '1'; signal ZcmoutO: bit:= '1'; signal Zcmout_1: bit:= '1'; signal OKHYPO: bit: = 1'; signal OKCONC: bit: '1 '; signal OKSTART: bit:= '1; begin bl:process(ck'stable,dirl,dirO,act_O, act_l,pr_in_O,pr_in_1, dir_l,dir_O,actO,act_l,cm_outO,ca.-out_1) begin if (not ck'stable) then Zdir_1 ≤ dir_1; Zdir_0O ≤ dirO; ZactO ≤ actO; Zact_1 ≤ act_1; ZprinO ≤ prinO; Z_prin_1 ≤ prin_1; Z_cmoutO ≤ cmout_O; Zcmoutl ≤ cmout_1; end if; end process; b:block(not ck'stable) begin OKEND ≤ not OKHYPO or OK_CONC; OKSTART ≤ 1); end block; HYPO: XH port map (ck, dir_l,Z_dir_l,dirO0,Z_dir_O,act_0, ZactO,act_l,Zact_l, prinO,ZprinO,prinl,Z._prin_l, OK_START, OK_HYPO); CONC: XC port map (ck, dirl,Zdirl,.dirO,ZdirO,actO,ZactO,act_-,Zact_1, cm_out_O,Z_cm_out_O,cm_out_l,Z_cm_out_1, OKSTART, OKCONC); APROP: assert (OKEND = '1' or ck'stable) report "PROP is violated! " severity varning; end ARC; Annexe C Introduction sur les langage rationnels Dans cette annexe, nous rappelons sommairement les définitions et résultats de théorie des langages dont nous aurons besoin dans la définition des chronogrammes. Ces rappels sont destinés à fixer les notations employées mais ne sauraient se substituer à un ouvrage traitant de ces questions. Le lecteur désirant des compléments d'information pourra consulter les livres [Eil74, Per84] C.1 Mots Un alphabet est un ensemble fini dont les éléments sont appelés des lettres. Dans cet article, nous utiliserons l'alphabet binaire B = {O, 1}. Un mot est une suite finie de lettres, que l'on note par simple juxtaposition de ces lettres. Le mot vide, noté e, est le seul mot ne contenant aucune lettre. Par exemple, e, O, 001, 1011 sont des mots sur l'alphabet B. L'ensemble de tous les mots (respectivement l'ensemble de tous les mots non vides) sur un alphabet A est noté A (respectivement A+). Si u = ai... a et v = b-... bq sont deux mots de A*, la concaténation (ou produit) de u et de v est le mot uv = a, . abl... bq...DTD: L'opération de concaténation est associative: il est en effet immédiat de vérifier que si u, v et w sont des mots, on a (uv)w = u(vw). En revanche, elle n'est pas commutative dès que l'alphabet contient au moins deux lettres, puisque par exemple, ab # ba. De plus, le mot vide est élément neutre pour cette opération: en effet, pour tout mot u de A', on a eu = Uc = u. Si n est un entier positif, la notation us désigne la concaténation de n copies du mot u. Par convention, u est égal au mot vide. La longueur d'un mot u, notée lul, est égale au nombre de lettres figurant dans u, chaque lettre étant comptée autant de fois qu'elle apparaît. Ainsi 10100101 = 6, et 10010101111 = 9. Le mot vide est le seul mot de longueur 0. L'application qui à un mot associe sa longueur possède une propriété qui s'apparente à celle des logarithmes: si u et v sont des mots, et n un entier, on a *luvl = ui + lv et lul = nui. On notera A[',n] l'ensemble des mots de A de longueur supérieure ou égale à n et in- férieure ou égale à m. Un mot z E A' est un facteur d'un mot u s'il existe des mots v et w tels que u = vzw. De la même façon, on dit que z est un facteur gauche, ou préfize, de u, s'il existe un mot w tel que u = zw, z est un facteur droit, ou suffize de u, s'il existe un mot v tel que u = vz. Par exemple, e, 1111, 011 et 10 sont des facteurs de 111101101. Notons que le mot vide c est facteur de tous les mots. C.2 Mots infinis Un mot infini sur l'alphabet A est une suite infinie de lettres de A et donc une application de IN dans A, que l'on note également par juxtaposition u = aoal.. an.. Cette notation représente donc l'application de IN dans A définie, pour tout n E IN, par u(n) = a,,. On note AlN l'ensemble des mots infinis sur l'alphabet A. Le produit d'un mot fini u = aoa *.. a, de A et d'un mot infini v = bob. À de AN est le mot infini uv = aoal...* abobl*... Les mots infinis que nous considérons sont des mots 'infinis à droite". On pourrait également considérer des mots 'infinis des deux côtés", définis formellement comme des applications de 7Z dans A, ce qui, intuitivement, correspond à ne pas donner de temps d'origine. L'utilisation de tels mots dans l'étude des chronogramrnes fera l'objet d'une étude ultérieure. Nous poserons donc l'hypothèse de l'existence d'un état initial. Les notions de facteur, de préfixe et de suffixe s'étendent sans difficulté aux mots infinis: un mot z E A' est un facteur d'un mot infini u s'il existe un mot fini v et un mot infini w tel que u = vxw. On dit que z est un facteur gauche ou préfize, de u, s'il existe un mot infini w tel que u = zw. Enfin, un mot infini z est un facteur droit, ou suffize de u, s'il existe un mot fini v tel que u = vz. C.3 Langages rationnels Un ensemble de mots de A est appelé un langage sur A*. Par exemple, les ensembles {010, 1010, 11} et {0"10" | n > 0} sont des langages sur l'alphabet B. On définit sur les langages plusieurs opérations. Les opérations boolennes regroupent les opérations d'union, de complémentation (par rapport à l'ensemble A' de tous les mots), d'intersection et de différence. Ainsi, si L et L' sont des langages de A, on a les formules: LUL' ={uE A IuELouuEL'} LnL' ={uEA*IuELetuEL'} L' =A*\L={uEAlIuCL} L\L' =L nLc ={uE A IuE Let u L}. Le produit (de concaténation) de deux langages L et L' est le langage LL'= {uu'l u E L et u E L'}. Par exemple, si L = {01, 10,100} et L' = {1, 01}, on a LL' = {011,101, 1001, 0101,10001}. Notons que pour tout langage L, OL = LO = 0 (o 0 désigne l'ensemble vide), alors que L{e} = {e}L = L. Le produit défini sur l'ensemble des langages sur un alphabet fixé est une opération associative et distributive par rapport à l'union (i.e. L(L1 U L2) = LL1 U LL2, quels que soient les langages L, Ll et L2). En revanche, le produit n'est pas distributif par rapport à l'intersection. Ainsi, on a ({1} n {o10}){0, 0oo} = 0{0,o00} = 0 mais {1}{0, 00} n {10}{0, 00} = {10, 100} n {100, 1000} = {100}. Comme pour les mots, on peut définir les puissances d'un langage en posant L = {e}, L1 = L, L2 = LL, et par récurrence, Ln = L"-'L, pour tout n > 0. L'étoile d'un langage L, notée L-, est l'union de toutes les puissances finies de L: L = U L. n>o Par exemple, si L = {01,10,100}, on a L = {E}, L' = {01,10, 100}, L2 = {0101,1001, 10001, 0110,1010, 10010, 01100,10100, 100100}, etc. L'opérateur L+ est une variante de l'opération étoile, obtenu en ne considérant que l'union de toutes les puissances non nulles d'un langage: L+= U L n>O Autrement dit L contient toujours le mot vide, alors que L+ necontient le mot vide que si L le contient déjà. On remarquera en particulier que les notations A' et A+ introduites précédemment sont compatibles avec les définitions des opérations L et L+. L'ensemble des langages rationnels sur A* est le plus petit ensemble de langages R vérifiant les conditions: (a) R contient les langages finis. (b) R est fermé pour les opérations.union, produit et étoile (autrement dit, si L et L' sont des langages de R, alors les langages L U L', LL' et L sont aussi éléments de R). Autrement dit, les langages rationnels s'obtiennent à partir des langages finis en utilisant les opérations union, produit et étoile. Les langages rationnels étant aussi fermés par intersection et par complémentation, on peut donc modifier sans dommage la définition précédente: les langages rationnels s'obtiennent à partir des langages finis en utilisant les opérations union, intersection, complémentation, produit et étoile. C.4 Langages w-rationnels Dans cette section, on s'intéresse aux ensembles contenant uniquement des mots infinis. La notion d'ensemble w-rationnel étend aux mots infinis la notion d'ensemble rationnel usuelle pour les mots finis. Le produit peut être étendu à A x As, en posant, pour X C A' et Y C AIN, XY = {zy 1 z E X et y E Y}. On a alors, quels que soient X, Y C A' et Z C AIN, (XY)Z = X(YZ), ce qui est une forme restreinte d'associativité. L'itération infinie est l'opération définie, pour toute partie X de A+ par Xw={z0ozi... pour tout i > O, zi EX} Autrement dit, Xw' est l'ensemble des mots infinis obtenus 'en mettant bout à bout une suite infinie de mots de X". En particulier, si u = a0al...a,, et si X = {u}, on a X' = {u aoai1 aÀaoa * 1 anaoaÀ... anaoa1.. obtenu en répétant u une infinité de fois. Par définition, une partie de AZ est w-rationnelle si et seulement si elle est union finie de parties de la forme XY' o X et Y sont des parties rationnelles non vides de A+. Prenons un exemple. L'ensemble X des mots infinis sur l'alphabet {a, b} ne comportant qu'un nombre fini d'occurrences de la lettre b est donné par l'expression w-rationnelle X = (a + b)a'. Le complémentaire Y de X dans A]N, c'est-à-dire l'ensemble des mots infinis comportant un nombre infini d'occurrences de la lettre b est donné par l'expression Y = (ab)'. L'ensemble Y est donc lui aussi w-rationnel. L'ensemble des parties wrationnelles de AiN est fermé par toutes les opérations booléennes. Si X C AIN est un ensemble de mots infinis et si L est une partie de A*, on pose L-'X = {u E AIN { il existe v E L tel que vu E X} On peut montrer que si X est une partie w-rationnelle de AN, il en est de même de L-1X quel que soit le langage L. C.5 Langages sans-étoile Puisque les langages rationnels sont fermés pour les opérations booléemnnes finies (union, intersection, complémentation, différence), il est naturel d'inclure ces opérations dans les opérations de base sur les rationnels. L'une des sous-classes des rationnels les plus étudiées est celle que l'on obtient en excluant l'opérateur étoile. De façon plus précise, on obtient alors la définition suivante: L'ensemble des langages sans- étoile sur A* est le plus petit ensemble de langages S vérifiant les conditions suivantes: (a) S contient les langages finis, (b) S est fermé pour les opérations booléennes et pour le produit (autrement dit, si L et L' sont des langages de S, alors les langages A \ L, L u L', L n L' et LL' sont aussi éléments de R). En d'autres termes, un langage est sans-étoile si on peut l'obtenir à partir des langages finis en utilisant uniquement les opérations booléennes et le produit. nl n'est guère facile de dire, en partant de cette définition, si un langage rationnel est ou n'est pas sans-étoile. Les exemples qui vont suivre risquent même de décourager le lecteur de recourir à son intuition. Première surprise, l'ensemble A' de tous les mots est lui-même sans-étoile: c'est en effet le complémentaire de l'ensemble vide, qui est un langage fini. Formellement, on a A = 0' Deuxième exemple: si X est une partie de l'alphabet A, X* est sansétoile. En effet, X est le complémentaire de l'ensemble des mots qui contiennent au moins une lettre de Xi = A \ X, ce qui se traduit par la formule X = A' \ A(A \ X)A = O' \ 0'(A \ X)O' et cette dernière expression est bien sans-étoile. De même, le langage X+ = X* \ {e} est sans-étoile. Plus difficile, le langage (01)* est une partie sans-étoile de B*, o B = {O, 1}. En effet (0l)* est l'ensemble de tous les mots ne comnmençant pas par 1, ne finissant pas par O et ne contenant ni le facteur 00, ni le facteur 11. Ce qui s'écrit formellement (01)* = B \ (0B' u B1 u B*OOB* u B11lB*) = 0' \ (00' U 0'1 u 0'000' u 0'110') C.6 Parties sans-étoile de mots infinis La définition des langages sans-étoile peut être étendue aux mots infinis. Par définition, l'ensemble des parties sans-étoile de A est le plus petit ensemble S de parties de parties de AN tel que (1) S est fermée pour les opérations booléennes (union, intersection, complément dans AN) (2) Si X E S et si Y est une partie sans-étoile de A*, alors YX E S On démontre qu'une partie de AN est sans-étoile si et seulement si elle s'écrit comme union finie de parties de la forme XYw, o X est une partie sans- étoile de A+ et Y est une partie sans-étoile de A+ telle que YY c Y. C.7 Hiérarchies de langages sans-étoile Les langages sans-étoile sont fabriqués à partir des langages finis en utilisant deux types distincts d'opérations: les opérations booléennes et le produit de concaténation. En alternant l'usage de ces deux types d'opérations, on obtient une hiérarchie de langages dont voici la définition récursive. Soit A un alphabet. (1) Les langages de niveau O sont 0 et A', (2) Pour tout entier n > O, les langages de niveau n + 1/2 sont les unions finies de langages de la forme LoalLla2" a*L& o Lo, Li,..., L" sont des langages de niveau n et al,.., a, sont des lettres (3) Pour tout entier n > 0, les langages de niveau n + 1 sont combinaisons booléennes finies de langages de niveau n + 1/2. Notons qu'un langage de niveau m est également de niveau n pour tout n > m. Les langages de niveau 1/2 sont les unions finies de langages de la forme A*alAa2... aiA', les langages de niveau 1 sont les combinaisons booléennes finies des mêmes langages, etc. Voici quelques exemples de langages de niveau 1 sur l'alphabet A: a* = A \ Uw. A'bA pour tout a E A {E] = A \ U.eA A'aA a+ = a\ {E} Nous admettrons le théorème suivant, qui regroupe plusieurs résultats relatifs à cette hiérarchie de langages. Théorème C.1 (1) Les langages finis sont de niveau 1. (2) Pour tout entier n > O, les langages de niveau n sont fermés par union, intersection, et complément. (3) Pour tout entier n > O, les langages de niveau n + 1/2 sont ferrmés par union, intersection, et produit. (4) Soit p: A' -- B- un morphisme de monoide et n un entier positif ou nul. Si L est un langage de niveau n (resp. n + 1/2), p-'(L) est également de niveau n (resp. n + 1/2). (5) La hiérarchie est stricte pour tout n: il existe des langages de niveau n + 1 qui ne sont pas de niveau n + 1/2 et des langages de niveau n + 1/2 qui ne sont pas de niveau n. C.8 Hiérarchies de parties sans-étoile La hiérarchie des langages sansétoile s'étend elle aussi aux mots infinis. En voici la définition récursive. Soit A un alphabet. (1) Les ensembles de niveau O sont 0 et AU, (2) Pour tout entier n > O, les langages de niveau n + 1/2 sont les unions finies de langages de la forme Loal La2 ' akLk o L0, L1,..., Là,-1 sont des langages de A de niveau n, Lk est une partie de AN de niveau n et al,..., ai sont des lettres. (3) Pour tout entier n > 0, les langages de niveau n+ 1 sont des combinaisons booléennes finies de langages de niveau n + 1/2. Annexe D Introduction à la logique temporelle CTL Dans cette section, nous allons rappeler brièvement la syntaxe et la sémantique de la logique temporelle branchée appelée COMPUTATION TREE LOGIC (CTL) [CG871. Cette logique utilise un modèle temporel en temps discret et arborescent sur un graphe d'état fini. Chaque état correspond à l'état de toutes les variables du programme à chaque période d'horloge. Ils pourront avoir plusieurs successeurs et plusieurs prédécesseurs. C'est un bon outil pour la spécification et la preuve de propriétés de haut niveau sur des machines séquentielles. La logique CTL utilise les opérateurs de la logique propositionelle, parmi lesquels "not", "A"et a ==>", avec de nouveaux opérateurs; X (l'instant suivant), A (quelque soit), E (il existe), et U (jusqu'à). La syntaxe formelle de CTL est la suivante: Soit AP l'ensemble des propositions atomiques du langage. 1. Toute proposition atomique p appartenant à AP est une formule CTL. 2. Soient P et Q deux formules CTL alors les formules suivantes le sont aussi: notP PAQ P =Q AX P EX P A(P U Q) E(PUQ) Les symboles not et A ont leur sens habituel. Pour les nouveaux symboles on a: * X est l'opérateur 'futur". la formule AX P signifie que P est vrai pour tous les états suivant immédiatement l'état courant du programme. la formule EX P signifie que P est vrai pour au moins un des états suivant immédi- atement l'état courant du programme. * U est l'opérateur 'jusqu'à'. la formule A( P U Q) signifie que pour tout chemin partant de l'état courant du programme, il existe dans ce chemin un état tel que Q soit vrai, et P est vrai pour tous les états le précédant depuis l'état initial. la formule E( P U Q) signifie qu'il existe un chemin partant de l'état courant du programme, o il existe un état tel que Q soit vrai, et P est vrai pour tous les états le précédant dans ce chemin. Une structure CTL est un 4uplet M=(S,R,P,so) appelée structure temporelle o 1. S est un ensemble fini d'états. 2. R est une relation binaire totale sur S (R C S x S) qui donne les transitions possibles entre les états. 3. P est une fonction sur les propositions atomiques P: S - 2'P. 4. so est l'état sur lequel est appliqué la formule. La sémantique des différentes formules CTL est définie de la manière suivante: * so J= p ssi p E P(so) ie p est égal à 1 en so. * so J= not P ssi not(so J= P). * 3 l= P A Q ssi 3o J= P et so J= Q * So J= AXP ssi pour tout état t tel que (Co, t) E R, alors t l= P * so l= EXP ssi pour au moins un état t tel que (so,t) E R, alors t = P * so J= A(PUQ) ssi pour tout chemin (so, s,....), 3 i, tel que si j= Q A Vj,j état o P est vrai, P est inévitable. - EF (P) =def E[true U P], c'est-à-dire qu'il existe un état dans un chemin o P est vrai. - AG (P) =def not EF (not P), c'est-à-dire que P est vrai dans tous les états de tous les chemins, P est invariable. - EG (P) =def not AF (not P), c'est-à-dire qu'il existe un chemin o P est vrai pour tous les états le composant. Annexe E Introduction au langage par contraintes Signal Nous allons ici, donner les principales applications ainsi que les principaux opérateurs du langage SIGNAL[BCHG91]. La traduction des propriétés dans ce langage permettra dans un deuxième temps, la preuve de cohérence entre ces propriétés, la vérification de ces propriétés sur un système [Le 89] ainsi que la spécification par contraintes. Comme nous l'avons vu dans la définition des chronogrammes primitifs les signaux que nous manipulons pour l'instant sont des signaux booléens (logical en SIGNAL), ce qui est une limitation par rapport au langage complet qui manipule aussi des signaux numériques. L'extension de CHLOE au type numérique permettrait une augmentation de la puissance d'expression du langage, mais limiterait dans l'état actuel des compilateurs leur manipulation pour la preuve formelle. Les chronogrammes primitifs spécifient des propriétés logiques, o l'hypothèse et la conclusion sont simultanées. Ils utilise alors les opérateurs de la logique standard. Par exemple, le "et logiquen sera défini de la manière suivante dans le langage SIGNAL: les signaux y et z fournissent simultanément leurs valeurs, et la valeur du signal x est alors équivalent au "et logique" de ces deux valeurs, i.e. (Vt zt = yt A zt), ce qui est définie en SIGNAL par l'équation suivante: [:= and z (1) Les chronogrammes permettent une représentation dans le temps de différents états des signaux, ils nécessitent donc la possibilité de mémorisation d'états ou plus exacte- ment l'ouverture de fenêtres sur le passé de certains signaux. L'opérateur 'S', appelé aussi retard, permet de faire référence aux valeurs passées d'un signal. Il est aussi pos- sible d'initialiser le signal a une valeur précise. SIGNAL inclut en fait une logique tem- porelle avec opérateur vers le passé et instant initial. Par exemple, si nous voulons que la valeur du signal zx soit égale à la valeur précédente du signal x, i.e. les équations zz_0 = vO et Vt # 0 zzt = zt - 1, sont traduites en SIGNAL par zx t zz init vO zz:= x $1 Il existe aussi un moyen d'échantillonnage des signaux, c'est-à-dire un booléen filtrant les valeurs d'un signal pour déterminer par exemple à quel instant une propriété définie par un signal, porte la valeur "true". L'opérateur d'échantillonnage est le when. Dans l'expression (3), lorsque pl porte la valeur vrai, alors h porte la valeur vrai, dans tous les autres cas c'est-à-dire pl porte la valeur faux ou est absent, h est absent et ne porte aucune valeur. I h:= when pl (3) Il est aussi possible dans le langage SIGNAL d'expliciter la synchronisation de deux signaux: les deux signaux sont présents exactement aux mêmes instants. L'opérateur synchro réalise cela pour x et y dans l'équation (4). Ceci est indispensable dans les chronogrammes synchrones o tous les signaux sont synchronisés sur le signal définissant l'horloge: I synchro z y (4) 1 Cet ensemble d'opérateurs que nous venons de présenter est une partie du langage noyau de SIGNAL, il est nécessaire et suffisant pour la traduction en un processus SIGNAL unique des propriétés ne possédant que des StaSynArea [Ant91a]. Mais dans les générateurs de code, nous avons essayé de hiérarchiser le code SIGNAL en utilisant la puissance du langage utilisateur de SIGNAL dans l'organisation d'un système en sous-systèmes utilisables sous plusieurs contextes. Le modèle d'un processus établit une désignation entre un nom et un ensemble d'équations paramétrables. Toute référence à ce nom dans d'autres processus est formelle- ment remplacée par les équations désignées. L'interface du processus est composée si be- soin de la déclaration de paramètres, ainsi que de la déclaration des entrées et des sorties du processus. process PROCESS = (integer PARAMETRE1; ) { ? logical ENTREE1; ! logical SORTIE } (. J Ensemble des équation... I) where Déclaration des variables locales au processus end; Nous avons aussi été amenés à utiliser une extension de l'opérateur retard qui permet de manipuler non pas la seule valeur au temps passé, mais une fenêtre de valeur dans le passé. Cette opérateur appelé "window", permettra de paramétrer les différents types d'intervalles en vectorisant le signal observé suivant la longueur des intervalles. I VECTEUR:=Signal S BJINF window LONGUEUR La manipulation de ces signaux vectorisés se réalise alors grâce a ce qui est appelé en SIGNAL un MOTIF et qui construit un processus par itération d'une même cellule élémentaire. [ array boucle to LONG of Corps duMOTIF with Initialisation des signauz utilises dans la boucle end Annexe F Introduction sur la forme TSD Dans cette annexe, nous allons donner un rapide aperçu des différents éléments que l'on peut dessiner sous la forme de TSD (TYPE- STRUCTURE DIAGRAMS): F.1 Définition de types Type principal: Le type principal d'un module est représenté par un rectangle avec une double ligne sur le haut. Il ne doit y avoir qu'un seul type principal par module. Le type principal pourra être exporté pour être utilisé dans la définition d'autres types comme type importé. ?yp. pàbKipd Type local: Les types locaux participent localement à la définition du type principal représentant le module. Ils ne pourront en aucun cas être ni des types principaux ni importés. F.2 Définition de types terminaux Type importé: Un type importé est un type qui est défini dans un autre module comme type principal. C'est pourquoi on réutilise le même symbole que pour les types principaux avec des lignes en pointillés. Type de base: Ce sont les mêmes que les types de base de VDM: rationnel, entier, booléen..... La représentation choisie pour ces types de base est un cercle avec le nom de type comme étiquette. Littéraux: Ce sont des valeurs symboliques données dans un losange. F.3 Définition de types non terminaux Type composé: La définition d'un type composé se fait en ajoutant un arc pour chaque champ. Ces arcs sont des fièches libellées par le nom du champ pointant sur la définition du type du champ ainsi spécifié. à * a& / I\ I I Type de base: Ce sont les mêmes que les types de base de VDM: rationnel, entier, booléen....La représentation choisie pour ces types de base est un cercle avec le nom de type comnre étiquette. Littéraux: Ce sont des valeurs symboliques données dans un losange. F.3 Définition de types non terminaux Type composé: La délfinition d'un type composé se fait en ajoutant un arc pour chaque champ. Ces arcs sont des fl;èches libellées par le noma du champ pointant sur la défruition du type du champ ainsi spécifié. Ensemble: Les ensembles sont représentés par une ellipse, avec une flèche pointant sur la définition de type des éléments composant cet ensemble. Liste: Pour une liste, c'est un parallélogramme qui est utilisé avec une flèche pointant sur la définition de type des éléments composant cette liste. Une liste non vide est spécifiée par un "+" dans le parallélogramme. Union de type: Le symbole pour l'union de type est un triangle renversé (réalisant le symbole VDM du "or") avec des flèches pointant sur plusieurs noms ou définitions de types. Produit: La même chose que l'union de type mais avec un triangle pointant vers le haut (réalisant le symbole VDM du "AND'). Type optionnel: Les types optionnels sont représentés en remplaçant dans un type composé la flèche pleine par une flèche en pointillées. p o z- -"e A _ A,....dws ANNEXE 1 Class BASICINTERV exporte emplacement, statut, génération, décompilation, modification, changer_statut, repeter GRAPHIC_NODE hérite NOEUD interface de la classe BASICINTERV ANNEXE 2 feature A ttributs: emplacement: SEGMENT; statut: STATUT, Actions d'édition: génération (env:ENVIRONNEMENT;pere_lig:CHAINE; borneinf:CHAINE; bonesup:CHAINE; statut: CHAINE) exécute fin; décompilation (env:ENVIRONNEMENT;pere_Iig:CHAINE) exécute fin; change_statut(env:ENVIRONNEMENT;statut:CHAINE) exécute fin; modification(env:ENVIRONNEMENT; borneinf:ENTRER; bornesup:ENTRER) exécute fin; Méthodes et attributs associés à la classe BASICINTERV REVENDICATIONS: 1. Procédé de description de chronogramme à l'aide d'un arbre syntaxique consistant à définir le chronogramme par des objets comportant des types et des attributs, et des objets de type différent étant reliés entre eux par une logique arborescente comportant des noeuds ET ou OU entre les ramifications. 2. Procédé de description de chronogramme, selon la revendication 1 caractérisé en ce que l'arborescence comporte à sa base la définition d'un objet de type "scène" qui se compose d'objets de type "terme" d'objets de type "liste"; d'objets de type "aire de synchronisation"; et 15. d'objets de type "horloge". 3. Procédé de description de chronogramme selon la revendication 2, caractérisé en ce que la liste d'aire de synchronisation est dynamique. 2o 4. Procédé de description de chronogramme selon la revendication 2, caractérisé en ce que la liste d'aire de synchronisation est statique. 5. Procédé de description de chronogramme selon la revendication 4, caractérisé en ce que la liste d'aire de synchronisation comporte un emplacement relatif et une configuration (pattern) qui est une liste non vide. 6. Procédé de description de chronogramme selon la revendication 5, caractérisé en ce que ladite configuration est formée d'une ligne de base qui comporte un terme, un objet de type terme et la configuration des intervalles de base. 7. Procédé de description de chronogramme selon la revendication 5, caractérisé en ce que la configuration des intervalles de base comporte l'emplacement d'un segment dont le type est l'union d'un objet de type événement binaire, d'un objet de type valeur stable binaire et d'un objet statut dont le type est un segment. 8. Procédé de description de chronogramme selon la revendication 7, caractérisé en ce que les objets de type segment ont des attributs qui permettent la définition de la longueur et la position du segment. 9. Procédé de description de chronogramme selon la revendication 7, caractérisé en ce que les objets de type événement binaire (B event) définissent un filtre de configuration par rapport aux transitions possibles des articles (item) associés avec la ligne à laquelle l'intervalle appartient. io 10. Procédé de description de chronogramme selon la revendication 7, caractérisé en ce que les objets de type valeur stable binaire (B stabel Val) définissent un filtre de configuration par rapport aux valeurs possibles des articles associés avec la ligne à laquelle l'intervalle appartient. il. Procédé de description de chronogramme selon l'une des revendications 1 à , caractérisé en ce qu'il permet la description de chronogramme simple ou de chronogramme évolué. 12. Procédé de description de chronogramme selon la revendication 11, caractérisé en ce qu'un chronogramme simple comporte deux scènes dont une première constitue l'hypothèse et une deuxième la conclusion. 13. Procédé de description de chronogramme selon la revendication 11, caractérisé en ce qu'un chronogramme évolué comporte une scène et autorise la création des liens logiques entre les différentes lignes de la scène et/ou les différents intervalles d'une ligne. 14. Dispositif permettant la mise en oeuvre d'un procédé de description de chronogramme à l'aide d'un arbre syntaxique sur un système informatique comportant au moins un écran, un clavier et une souris, caractérisé en ce qu'il comporte un contrôleur d'édition d'une part autorisant la création de préfixe d'arbre valide, et d'autre part associant à chaque objet composant l'écran une fonction contrôleur syntaxique qui filtre les actions réalisées par l'association, à chaque objet, d'une liste de méthodes correspondant aux différentes actions que l'utilisateur effectue à l'aide de la souris ou du clavier, cette liste de méthodes permettant pour chaque objet d'interpréter différemment les stimuli fournis par la souris et/ou le clavier; 15. Dispositif selon la revendication précédente, caractérisé en ce qu'une interface souris et clavier permet de reconnaître le stimulus appliqué et l'objet sur lequel est appliqué le stimulus pour éliminer le stimulus non acceptable pour un objet et pour les autres d'envoyer vers le contrôleur un message qui sera interprété suivant l'objet et le stimulus envoyés. 16. Dispositif selon la revendication précédente, caractérisé en ce que le contrôleur d'édition traduit chaque entité graphique en une succession de noeuds selon le procédé des revendications 1 à 13 et à chaque noeud est associé une table de méthode valide, le contrôleur comporte une fonction permettant d'une part d'associer à chaque objet sur lequel un stimulus est io appliqué, un message destiné à un noeud unique de l'arbre syntaxique et d'autre part de vérifier que la méthode associée au stimulus correspond à une méthode valide pour le noeud puis à exécuter la méthode pour mettre à jour l'arbre syntaxique et effectuer la mise à jour de l'affichage. i 17. Dispositif selon la revendication précédente, caractérisé en ce que chaque message est un couple composé par un identificateur de l'objet graphique et par un type d'actions à exécuter. 18. Dispositif selon la revendication précédente, caractérisé en ce qu'un préfixe est associé à chaque noeud de l'arbre, ledit préfixe permettant d'effectuer la mise à jour de l'image graphique en définissant le statut de l'édition. 19. Dispositif selon une des revendications précédentes caractérisé en ce qu'il comporte un éditeur monomode dont l'état est définit par l'arbre syntaxique ou préfixe d'arbre contenu en mémoire, le préfixe d'arbre représentant un mot du language de chronogramme et pouvant être décompilé, ou affiché comme tel, le préfixe d'arbre représentant également une palette de bouton formant un menu, chaque bouton étant le résultat de la décompilation, de l'affichage d'un noeud de préfixe d'arbre et permettant par l'exitation de ce bouton d'activer les méthodes associées à l'objet noeud. 20. Dispositif selon la revendication 19 caractérisé en ce que un même bouton à plusieurs excitation possible (par des organes différents du dispositifs, exemple: bouton gauche souris, lettre "A" du clavier) et à chaque excitation est activé une méthode définie. 21. Dispositif selon l'une des revendications précédentes caractérisé en ce qu'il comporte une grammaire constituant une définition finie de l'ensemble des objets graphiques possibles et permettant à partir de cette définition la création d'un ensemble infini de préfixe d'arbres syntaxiques, formé d'un ensemble de neouds dans lequel chaque noeud d'un tel préfixe d'arbre correspond à un objet graphique parfaitement défini, le préfixe d'arbre représentant l'automate de s pilotage de l'édition dont les entrées sont les excitations des boutons et les sorties constituent un nouvel automate représentatif d'un nouvel arbre syntaxique qui représente le chronogramme en construction après les modifications faite. io 22. Dispositif selon la revendication précédente caractérisé en ce que les excitations des boutons activent un interprète pour exécuter des fonctions définissant les objets graphiques à détruire, créer et modifier.