OBJECTIF

Ce stage vise l'amélioration d'un outil de conception conjointe (matériel / logiciel) de systèmes multiprocesseurs intégrés sur puce utilisant un espace d'adressage partagé. L'environnement de conception DSX (Design Space eXplorer) a été développé au LIP6 par Nicolas Pouillon, et permet au concepteur du système d'évaluer rapidement les performances de différentes réalisations architecturales d'une même application multi-tâches intégrée sur puce. Plus précisément, DSX fournit au concepteur un langage unifié pour

• décrire l'architecture matérielle multi-processeurs
• décrire la structure de l'application parallèle multi-tâches
• spécifier les directives de déploiement de l'application sur le matérie

DSX impose au concepteur de définir explicitement le parallélisme « gros grain » de l'application multi-tâches embarquée, sous la forme d'un TCG (Task & Communication Graph), ce qui suppose que le nombre de tâches et le schéma de communication sont définis de façon statique, et ne varient pas en cours d'exécution. Chacune des tâches peut être implémentée soit en « logiciel » (la tâche est écrite en C et s'exécute sur un des processeurs programmables de l'architecture), soit en « matériel » (la tâche est écrite dans un langage de description de matériel permettant de synthétiser un coprocesseur spécialisé). Pour la communication entre les tâches (matérielles et/ou logicielles), DSX fournit au programmeur d'application - à travers l'API SRL (Système ressource Layer) - un intergiciel de communication unifié utilisant des canaux de communication se comportant somme des FIFOs logicielles. 

On souhaite modifier trois caractéristiques de DSX :

1. Pour contrôler l'ordonnancement des tâches logicielles lors de l'éxécution sur les processeurs programmables du MPSoC, DSX s'appuie sur le système d'exploitation MutekH, qui fournit l'API des threads POSIX. Comme la plupart des applications conçues avec DSX sont statiques, on n'utilise pas les services de création dynamique des tâches de POSIX. On souhaite donc que DSX puisse utiliser un OS embarqué plus simple, tel que le GIET (Gestionnaire d'Interruptions Exceptions et Trappes) qui ne fournit aucun support pour la création/destruction dynamique des tâches, mais possède l'avantage d'être extrêmement compact.
2. Pour contrôler le placements des objets logiciels (code des tâches, piles d'exécution de chaque tâche, canaux de communication, verrous) sur les différents bancs mémoire de l'architecture matérielle, DSX ne fait pas l'hypothèse que l'architecture matérielle fournit un mécanisme de mémoire virtuelle. DSX utilise donc une technique consistant à intervenir lors de la génération du code binaire embarqué, et précisément dans la phase d'édition des liens de GCC. Or, la plupart des processeurs embarqués dans les architectures MP-SOC fournissent maintenant un support pour la mémoire virtuelle paginée (MMU), ce qui est une méthode plus naturelle pour contrôler le placement des objets logiciels dans l'espace d'adressage physique. La mémoire virtuelle permet également d'utiliser des techniques de réplication de code, qui sont plus difficiles à mettre en oeuvre en intervenant dans la phase de compilation.
3. Pour charger le code binaire de l'application embarquée dans la mémoire d'un MPSoC sans mémoire virtuelle paginée, DSX utilise actuellement un « raccourci » fourni  par le  modèle de mémoire disponible dans la plate-forme SoCLib : le code binaire est directement chargé dans la mémoire du prototype virtuel SystemC (ou du prototype matériel FPGA) aux adresses définies dans la phase d'édition de liens, AVANT de lancer l'exécution du code de boot. Autrement dit, le chargement en mémoire du code binaire (à partir d'un périphérique de stockage externe) n'est pas réalisé par la machine elle-même. Si on veut utiliser le mécanisme de mémoire virtuelle paginée pour contrôler le placement des objets en mémoire physique, il faut que le code de boot se comporte comme un véritable « boot-loader » : Il faut qu'il commence par construire les tables de pages pour les différentes tâches de l'application, puis utilise ces tables de pages pour effectuer le chargement du code binaire en mémoire.  

TRAVAIL PROPOSE 

Le langage DSX/L est en pratique une ensemble de classes PYTHON. Le stage porte donc sur une re-écriture partielle de l'outil DSX consistant à introduire les trois modifications décrites ci-dessus. Une étape préalable consiste à introduire dans le GIET un service de création - statique - des tables de pages associées à chacune des taches logicielles définies dans le TCG. La MMU de référence est la MMU générique de SoCLib, utilisée en particulier par l'architecture many-cores TSAR.

Ce stage se déroulera suivant les étapes suivantes :

1. analyse détaillée de l'architecture logicielle de DSX
2. analyse de l'architecture et des APIs du GIET
3. analyse l'architecture de la MMU générique
4. intégration dans le GIET d'un service de création des tables de pages
5. définition d'un boot-loader générique
6. portage de l'API SRL de DSX sur le GIET
7. Modification de la partie de DSX responsable de la génération du code embarqué.
8. validation de l'ensemble sur une application existante.

ENCADREMENT

Ce stage sera encadré par Alain Greiner : Alain.Greiner@lip6.fr