Notes et questions

• Remarque [AR] : Les définitions générées à partir d'une description Esterel (en utilisant la chaîne de compilation ".strl"->".sc"->".dc") sont ordonnées dans le sens de dépendances entre les flots (entrée -> sortie).
• Remarque [MS] : Toutefois, le fait que les définitions DC soient ordonnées n'est pas important pour la traduction vers SynDEx. Par exemple, une spécification DC obtenue avec une chaîne de compilation qui n'ordonne pas les définitions doit être également acceptée par le traducteur.

• Question [MS] : Quelle est la sémantique d'une condition d'activation sur un appel de procédure ? Toutes les flots de sorties de la procédure sont contrôlés par l'horloge du "at" ?
• Réponse [CL] : La condition d'activation conditionne "l'exécution" de la fonction (ou de la procédure), c'est-à-dire la mise à jour du(des) flot(s) défini(s).

DC définit un ensemble de types, constantes et fonctions prédéfinis. Par exemple, pour les valeurs et les opérations booléennes.

• Question 1 [AG,MS] : Quelles sont les opérations offertes par SynDEx pour implémenter la bibliothèque prédéfinie de DC ? Il faudra spécifier le type de l'opération SynDEx pour chaque constante et fonction DC.
• Réponse [CL] : Il n'y a pas de bibliothèque rigidement prédéfinie en SynDEx, mais en général on fournit avec l'exécutif générique un ensemble de macros pour les opérations arithmétiques et logiques "habituelles" (add, sub, mul, div, and, or, not, eq, lt) sur les types "habituels" (bool, int, float, double, array) ; mais l'utilisateur SynDEx peut définir tout autre type d'opération et de donnée ; cependant. [A VOIR] : Il faudra définir un équivalent SynDEx de la bibliothèque prédéfinie par DC.
• Question 2 [AG,MS] : Exite-t-il une bibliothèque commune aux différentes architectures (ou un sous-ensemble commun) ? Il serait utile d'avoir ces informations pour définir la partie < characteristics >.
• Réponse [CL] : Hors de propos, car les caractéristiques sont spécifiques autant à une opération qu'à l'opérateur (processeur ou ASIC) qui l'exécute, elles ne peuvent donc être fournies qu'avec la description de l'architecture.
• Question 3 [AG,MS] : Comment sont traitées les constantes prédéfinies, par exemple, TRUE et FALSE ?
• Réponse [CL] : En SynDEx, les constantes sont traitées sous forme symbolique;: la connexion avec la valeur de la constante se fait en fonction de la machine cible.

[CL] : La version 5.0 de SynDEx n'a pas de conditionnement (si ce n'est des "conditionnelles" qui sont considérées comme des opérations "normales" avec une sortie et trois entrées dont une booléenne, comme en Mustig par ex.), c'est-à-dire correspond à du DC sans autre "horloge d'activation" que l'horloge "la plus fine" (qui est implicite).

La version 5.1 de SynDEx, en cours de préparation, permettra de spécifier des horloges d'activation et, par étapes progressives, saura faire des optimisations sur les horloges d'activation (évaluation "paresseuse"/"demand-driven" des opérations "safe") qui permettront des spécifications plus légères (avec des horloges implicites).

En SynDEx 5.1, on ne "contrôlera" pas directement les connexions (les flots) mais on "conditionnera" une opération par l'intermédiaire de son port d'entrée "condition d'activation" (un nouveau port spécial introduit en SynDEx v5.1, en plus des ports d'entrée et sortie de l'opération de la v5.0). Il en va de même en DC où le "at" d'une "equ:" (ou d'un "proccall:") conditionne "l'exécution" de la fonction (ou de la procédure), c'est-à-dire la mise à jour du(des) flot(s) défini(s). En termes de génération d'exécutif, on conditionnera, au moyen d'un "jump conditionnel" (généré par une macro "if_" prenant en argument le tampon connecté au port d'entrée "condition d'activation"), l'exécution de la séquence d'instructions représentant l'opération (qui ne prendra en argument que les tampons représentant les ports d'entrée et de sortie).

• Remarque [MS] : il semble que les identificateur d'opérations doivent être uniques, car si un identificateur d'opération O est réutilisé, SynDEx génère une seule "boîte", contenant la définition de la dernière opération ayant l'identificateur O.
• Réponse [CL] : Chaque sommet, du graphe d'algorithme ou d'architecture, est désigné de manière unique ("identifié") soit à la souris par sa position graphique, soit textuellement par son nom ("identificateur") ; de même en DC chaque noeud est identifiable par l'index de sa position dans la table des noeuds. Les noms des sommets (et de leurs ports) sont utilisés en SynDEx pour générer un exécutif sans conflit de noms, composé d'identificateurs uniques. Deux définitions avec le même identificateur ne sont pas considérées par SynDEx comme une erreur, c'est une fonctionnalité permettant l'édition interactive (la modification d'un sommet par redéfinition) : seule la dernière définition est prise en compte.

• Remarque [MS] : Est-elle utile ? Si on donne des noms uniques aux ports, il n'est pas possible d'obtenir une connexion par défaut ? Exemple de code généré à partir une description DC :

	function 270.500 270.500 and__27 b__and {bool !LF_30 bool ?LF_27 bool ?AUX_11}
	function 271.500 271.500 not__27 b__not {bool !AUX_11 bool ?AUX_12}
	constant 272.500 272.500 cst__27 b__false {bool !AUX_12}

	connect not__27 AUX_11 and__27 AUX_11 
	connect cst__27 AUX_12 not__27 AUX_12

• Réponse [CL] : En DC (resp. en C), on déclare d'abord des flots (resp. variables) et des types de sommets (resp. prototypes de fonctions), puis on instancie les sommets (resp. appels de fonctions) en leur passant en argument des flots (resp. variables) ; passer le même flot (resp. variable) en argument de plusieurs instanciations de sommets (resp. appels de fonctions) correspond à faire une connexion. En SynDEx, on instancie d'abord des sommets (par création directe ou par copier/coller) puis on les connecte ; l'espace des noms d'un port est local au sommet (deux sommets peuvent avoir des ports de même nom, c'est le cas de tous les ports après une copie de sommet) ; on génère le nom de la variable de connexion en composant le nom (unique) du sommet et celui de son port à l'origine de la connexion ; il faut que ce nom n'interfère ni avec l'espace des noms de types de sommets (noms des macros générées), ni avec l'espace des noms de fonctions compilées séparément.

Ces solutions ont été proposées lors de la réunion TOLÈRE du 11 février 1999.

• Générer un correspondance "générique" de tous les sommets de contrôle vers un seul processeur.
• Générer un seul bloc contenant tous les sommets de contrôle.
• Adapter les heuristiques de répartition en SynDEx pour traiter d'une manière spéciale la granularité fine du contrôle.
• Générer des booléens d'activation des calculs externes au lieu d'appels de procédures dans le programme Esterel : ainsi le calcul est automatiquement séparé du contrôle ; mais il faut réussir à passer les paramètres des procédures.
• Utiliser des outils de minimisation pour les équations booléennes du format DC. Par exemple, traduire une description DC avec n opérations de calcul (n très grand) vers OC (format automate) et réduire le OC pour avoir uniquement k variables d'état (k plus petit, éventuellement égal au nombre de processeurs de contrôle) et obtenir une DC ainsi minimisé. Sur ce DC appliquer la traduction.

• Il ne contient pas une option "Reload"

DC	SynDEx
package XXXX	fichier "XXXX.sdx"
table types	rien (information sémantique)
table fonctions	rien (information sémantique)
table procédures	rien (information sémantique)
table constantes	rien (information sémantique)
table noeuds	description d'algorithme
définition	une liste d'opérations et une liste de connexions

Normalement, un package (DC) doit correspondre à un fichier (sdx). Le problème semble être l'importation de packages (DC).

• Question [MS] : Comment est faite l'importation de fichiers sdx ? L'importation est possible ? La compilation séparée est-elle permise ?
• Réponse [CL] : L'importation est interactive par copier/coller, pas d'équivalent textuel.

DC ne contenant pas d'informations sur la représentation graphique du graphe de l'algorithme, le traducteur DC2SDX devra générer des coordonnées pour chaque sommet.

• Question [MS] : Actuellement, DC2SDX génère une spécification SynDEx mal indentée. Exite-t-il un outil qui indente (graphiquement) les sommets SynDEx ?
• Réponse [CL] : Une solution triviale consiste à mettre les même coordonnées pour tous (ou un peu mieux des coordonnées aléatoires pour que tous les sommets ne "s'empilent" pas au même endroit), laissant à l'utilisateur le soin de réorganiser la topologie de son graphe. J'ai développé pour SynDEx v4 une solution un peu meilleure, qui consiste à placer topologiquement les sommets dans leur ordre partiel de précédence, soit pour un sommet s :

coordX(s) = max(coordX(pred(s))) + deltaX

• Réponse [CL] : la sémantique de cette définition est que F1 et F2 représentent le même flot, donc il faut "simplement" que tu substitues toute occurrence de F2 par F1 avant de procéder à la traduction.
• Remarque 1 [MS] : Bien que la condition d'activation est "true", je génère une opération de type "AT" ayant comme sortie (port "o") F1, comme entrée (port "i") F2 et comme condition la sortie de la constante "true".
• Remarque 2 [MS] : Pour les équations ayant la partie droite une expression et la condition d'activation "at: @$1", DC2SDX applique un algorithme optimisé qui ne génère pas l'opération "AT".

• Remarque [MS] : Pour un noeud, DC2SDX v0.2 connecte les flots d'entrée à des capteurs (opération de classe "extio") ayant une sortie et les flots de sortie à des devices (opération de classe "extio") ayant une entrée. Ceci permet d'identifier facilement les sorties et les entrées de l'algorithme.
• Réponse [CL] : l'interprétation ci-dessus est correcte.

Quelques caractéristiques de cette version (un rapport technique est en cours de préparation) :