Environnement de simulation

Afin de simuler le fonctionnement du pipeline sur une architecture embarquée le simu- lateur de l’architecture Scalable Chip MultiProcessor (SCMP), SESAM a été choisi, car il permet de modifier aisément les paramètres de l’architecture (nombre de processeurs, taille des mémoires, etc.). De plus, un grand nombre de mesures peut être extrait des simulations. L’architecture SCMP étant une architecture concue pour l’embarqué, elle permet ainsi de mettre en avant les contraintes de ce domaine.

L’environnement de simulation utilisé permet de reproduire le comportement de l’ar- chitecture multi-cœurs SCMP. L’architecture SCMP [29] est une architecture multi-cœurs paramètrable en termes de nombre et type de processeurs, de mémoires et de réseau d’in- terconnection. Elle est basée sur une structure de type Chip MultiProcessor (CMP) 3.16 et utilise des mécanismes permettant d’accélérer les préemptions et migrations de tâches. Le modèle d’exécution est de type Chip MultiThreading (CMT). Il amène des pénalités de changement de tâches mais aussi une grande flexibilité et une grande réactivité pour des systèmes de type temps réel. L’architecture SCMP est vue par le CPU comme un coprocesseur sur lequel le CPU peut exécuter des applications très calculatoires.

La Figure 3.16 montre l’architecture [29] dans l’aquelle chaque processeur est relié a des memoires d’instructions et de données (scratchpads), chaque processeur est aussi relié au réseau d’interconnection de données qui relie tous les processeurs aux bancs mémoires partagés. L’unités de de gestion et de configuration de la mémoire s’occupe du partage des données et de l’addressage des bancs mémoires.

Les processeurs sont aussi reliés via un second réseau d’interconnection à l’ordonnan- ceur. Celui-ci s’occupe de la gestion et de l’allocation des tâches sur les processeurs, il peut être un processeur dédié ou cablé matériellement.

Les ressources de calcul peuvent être hétérogènes, comme par exemple des processeurs généralistes ou dédiés. Les communications entre les processeurs s’effectuent au travers de mémoires locales et d’un réseau qui connecte tous les processeurs et les mémoires. Un contrôleur dédié permet de supporter efficacement ces modèles d’exécution. Il s’occupe de la gestion des ressources distribuées (calcul et mémoire) et de l’ordonnancement des tâches. Quand le contrôleur reçoit un ordre d’exécution, il ordonne à l’unité de gestion et de configuration de la mémoire (MCMU) d’allouer l’espace mémoire pour le contexte, la pile et le code binaire de chaque tâche. Ensuite, il charge le code binaire de chaque tâche et initialise le contexte.

Dès qu’une ressource est libre ou exécute une tâche moins prioritaire, l’OSoC lui envoie un ordre de lancement de la tâche. Si la ressource exécutait une tâche, alors le contexte d’exécution est sauvegardé et la tâche est suspendue pour pouvoir lancer une nouvelle tâche. Le processeur ayant reçu la requête de lancement de tâche demande alors à la MCMU la table de translation mémoire afin de pouvoir accéder au code binaire de la tâche qui sera exécutée (ainsi qu’au contexte et à la pile). Afin de partager efficacement les données, toutes les ressources sont partagées et les mémoires sont distribuées. Les latences des différents blocs sont estimées en fonction de résultats de synthèses logiques et les communications sont temporisées suivant un model approximate-timed Transactional Level Modeling (TLM) [67]. Les processeurs modélisés sont de type MIPS32.

54 CHAPITRE 3. ETUDE D’UN PIPELINE GRAPHIQUE

Figure 3.16 – L’architecture SCMP.

Le simulateur de l’architecture SCMP est appelé SESAM [68] (Environnement de Simu- lation pour Multiprocesseur Asymétrique Scalable). Il est décrit avec le langage SystemC et utilise l’outil ArchC [69] afin de générer des simulateurs de jeux d’instructions pour les processeurs. Le simulateur SESAM propose deux types de contrôleurs :

— un contrôleur matériel : l’OSoC,

— un contrôleur programmable, ce qui permet de modifier facilement le fonctionnement de la gestion des tâches qui s’exécutent sur l’architecture.

Ainsi, chaque application doit être parallélisée et découpée en tâches. En particulier, les parties calculatoires sont séparées des parties de type contrôle. Chaque tâche devient alors un programme autonome. La tâche de contrôle s’occupe de l’ordonnancement des tâches calculatoires ainsi que d’autres fonctionnalités telles que les synchronisations ou la gestion des ressources partagées. L’application est présentée sous la forme d’un graphe de contrôle (CDFG) comme sur la Figure 3.17, qui représente les dépendances de contrôle et de données entre les différentes tâches.

Deux modèles d’exécution sont supportés, un modèle tâche contrainte et un modèle flot de données, les deux pouvant être mélangés au sein d’une même application. Le premier modèle permet l’exécution de tâches lorsque toutes les tâches précédentes ont fini leur exécution et ont donc produit leurs données intermédiaires. Dans le deuxième modèle, les tâches peuvent partager les données avec d’autres tâches concurrentes. Dans ce modèle, une tâche peut attendre une donnée produite par une autre tâche du pipeline.

Ce deuxième modèle convient donc pour supporter un modèle d’application pipeline puisque les différentes tâches restent en fonctionnement en permanence et qu’elles se trans- mettent des données via des zones mémoire partagées. Ces dernières peuvent être de type First In First Out (FIFO), ce qui permet de relâcher les contraintes sur les tâches et ainsi d’absorber une partie des variations des temps de calcul.

3.4. IMPLÉMENTATION PARALLÈLE 55

Figure 3.17 – Exemple de graphe décrivant les dépendances entre les tâches d’une applica- tion.