Modifications du RAC

Pour le temps-réel

Le RAC doit avoir un comportement prédictible et permettre la maîtrise de ses temps d’exécution pour supporter une utilisation sous des contraintes temps-réel. Cependant, dans sa version actuelle [210], la construction des cellules intervient de manière aléatoire et a une durée indéfinie. Pour résoudre ce problème, il faut respecter quatres dispositions complémentaires.

Premièrement, la taille des divergences et des convergences doit être limitée pour majorer le temps de construction. Dans le cas contraire, il faut considérer, lors de chaque extension du graphe, que la cellule feuille ait la possibilité de créer des liens vers toutes les autres cellules. Le pire temps de construction serait donc beaucoup trop important.

Deuxièmement, les demandes d’exécution et de construction doivent être traitées dans l’ordre en fonction de leur date d’arrivée. Pour cela, il faut sélectionner toutes les demandes à un instant donné et empêcher la prise en compte de nouvelles demandes tant qu’elles n’ont pas toutes été traitées. Une mise à jour doit être prévue en cas d’initialisation ou de libération des cellules.

Troisièmement, pour limiter les constructions inutiles, il est préférable d’attendre que les cellules feuilles aient un jeton d’exécution. Dans ce cas, la construction des cellules suivantes a lieu pendant l’exécution de la tâche.

Enfin, il faut être capable d’effectuer des combinaisons d’évènements afin de limiter le nombre de cellules intermédiaires. Pour l’instant, un seul évènement est associé à une cel- lule. Pour prendre en compte un deuxième évènement lors de la propagation du jeton, il faut ajouter une cellule supplémentaire qui n’active aucune tâche. Avec un dispositif de type PAL (Programmable Array Logic), la construction de chaque cellule utile nécessite au plus la construction d’une cellule intermédiaire.

Une fois toutes ces solutions mises en œuvre, le temps de création d’une cellule (quel que soit le nombre de destruction) peut être borné. Le cas le plus défavorable lors de la construc- tion d’une cellule est obtenu lorsqu’une divergence de taille maximale tente de se construire et échoue lors de la dernière connexion. Alors, il faut annuler les constructions réalisées et attendre la libération de suffisamment de cellules avant de recommencer. D’autre part, il faut prendre en compte le fait que d’autres constructions concurrentes peuvent avoir lieu.

Dans l’état actuel des développements du RAC, la construction d’une cellule nécessite 12 cycles et la libération 26 cycles (soit respectivement 60 et 130 ns à 200 MHz dans le cadre d’une réalisation en technologie CMOS 0,13 µm). Nous avons donc pu estimer le pire temps de propagation des jetons à environ 1,6 µs pour une divergence d’au plus 8 cellules. Pour un fonctionnement transparent du RAC, il faut donc que la durée d’exécution d’une tâche soit supérieure ou égale à ce temps. Dans ce cas, les mécanismes internes du RAC liés à l’exécution des tâches n’ont pas d’incidence majeure puisque l’exécution est concurrente à la construction de la tâche suivante. Il faut en effet seulement 6 ns à une cellule du RAC pour autoriser la propagation des jetons et faire une nouvelle demande de configuration.

Pour la configuration avant l’exécution

L’étude du principe d’exécution de l’architecture SCMP-LC a montré que l’exécution de chacune des tâches nécessite préalablement une configuration. Celle-ci prépare les mémoires partagées et configure le réseau d’interconnexion. Le cas échéant, elle pourrait configurer la ressource de calcul correspondante si des ressources reconfigurables sont utilisées. Toutes ces configurations induisent des coûts non négligeables sur les temps d’exécution. Par conséquent, la possibilité de configurer une tâche pendant l’exécution de ses tâches précédentes permettrait un gain de temps significatif.

L’intégration de cette nouvelle propriété nécessite de légères modifications de la structure actuelle du RAC. Il suffit de mettre en œuvre un mécanisme de double jeton pour autoriser la configuration des ressources avant l’exécution des tâches. La réception du jeton d’exécution requiert l’exécution de la tâche correspondante, tandis que le jeton de configuration envoie une requête de configuration au PMAU afin de préparer une mémoire libre à recevoir les instructions ou les configurations. Le jeton de configuration est propagé aux cellules suivantes lorsque les configurations des cellules précédentes sont terminées et qu’elles possèdent un jeton d’exécution. Le jeton d’exécution est quant à lui transmis lorsque les demandes d’exécution des tâches précédentes ont été validées. L’exécution d’une tâche n’est possible que si la cellule correspondante a été préalablement configurée et qu’elle possède un jeton d’exécution. Par ailleurs, la fin d’exécution d’une tâche a lieu lorsque tous les traitements et tous les transferts de données ont été effectués. La figure 4.5 illustre ce fonctionnement.

Au début de l’exécution d’un graphe d’application, la tâche initiale contient un jeton de configuration et d’exécution. Les demandes d’exécution et de configuration sont prises en compte par niveau. Ceci signifie que chaque ensemble de demandes est traité avant d’en ac- quérir un nouveau. Ceci ne garantit cependant pas que les demandes d’exécution arrivent après les configurations. En effet, si la durée de configuration est supérieure à la durée d’exé- cution des tâches précédentes, la tâche peut devoir attendre sa configuration. Les jetons de configuration et d’exécution doivent être pris en compte dès leur arrivée quel que soit l’état des cellules. Pour éviter des configurations inutiles ou prématurées, les configurations ne doivent pas avoir lieu en avance lors de convergence en ET et de divergence en OU.

Pour la création dynamique des applications

Le RAC est capable de construire dynamiquement de nouveaux graphes d’application, mais il ne peut pas en créer ou en supprimer au cours de l’exécution. Néanmoins, les modifications nécessaires sont relativement simples à mettre en œuvre. Tout d’abord, il faut intégrer une cellule supplémentaire capable de détruire les jetons de configuration et d’exécution pour permettre la fin de l’exécution des différents graphes présents dans le RAC.

demande d’exécution (start) fin d’exécution (fin) demande de configuration (config) fin de configuration (fin_config) acquisition transmission traitement configuration / instructions jeton d’exécution jeton de configuration

Fig. 4.5 – Gestion de l’exécution et propagation des jetons de configuration et d’exécution. La configuration est requise au début de l’exécution de la tâche précédente. Une cellule peut contenir deux jetons. Le jeton de configuration est propagé vers les tâches suivantes dès que le jeton d’exécution est reçu.

Ensuite, l’identification des tâches doit permettre de dissocier des tâches n’appartenant pas à la même application. En effet, on doit identifier les tâches à supprimer lors de la réception d’une demande de fin d’exécution d’une application. Pour cela, il faut mettre en œuvre un système d’identification des tâches permettant d’associer chaque tâche à une instance d’ap- plication.

L’utilisation du RAC existant n’est pas envisageable pour un système temps-réel. Néan- moins, la mise en œuvre de quelques modifications permet d’obtenir un élément de contrôle mieux adapté à nos besoins. En effet, il est capable de prendre en charge la gestion des dépendances entre les tâches, les synchronisations et les préséances d’exécution. Il est parti- culièrement bien adapté à notre modèle d’exécution. Nous allons maintenant détailler dans la section suivante sa mise en œuvre dans l’architecture OSoC.