• Aucun résultat trouvé

Le Flux de Conception de la Méthode de Synthèse MPSoC proposée

Dans cette section, nous décrivons notre méthodologie relative aux synthèses de multiprocesseurs d’applications spécifiques hétérogènes avec des extensions SIMD programmables. Le flux de conception est montré dans l’image 8. Notre processus de conception commence avec le développement de l’application. Pour chaque application, ou le graphique de tâches peut être extrait par profilement ou alternativement une application peut être développée comme une chaîne de différentes tâches dans laquelle chaque tâche représente un opérateur spécifique de différente taille. Nous avons effectué nos expériences sur des applications de traitement d’images, donc nos tâches représentent un opérateur de traitement d’images et la totalité de l’application peut être vu telle une chaîne d’opérateurs de traitement d’images. Dans cette chaîne de traitement d’images, chaque opérateur de traitement d’images représente un certain nœud d’entrée et de sortie d’images alors que la communication entre opérateurs est représentée par des bords entre les nœuds. Le problème des synthèses MPSoC avec des extensions de jeu d’instruction programmables peut être vue comme une association et une programmation de tâches sur une plateforme de multiprocesseur tel que :

1. Le temps global d’exécution pour l’application est réduit et les contraintes de performance sont rencontrées.

2. Chaque processeur est étendu d’une façon appropriée avec des instructions programmables selon les tâches à associer pour réduire les coûts d’espace.

3. L’architecture de réseau sur puce est simplifiée en raison des améliorations de performance au niveau des nœuds individuels résultantes de l’insertion d’instruction programmable au sein d’un processeur à but général.

Figure 1-8 Méthodologie de Conception MPSoc pour un Processeur SIMD étendu avec un NoC sous- jacent

Au-delà du développement de l’application, nous avons aussi conçu une plateforme de référence au début de l’étape de conception. Le choix d’une Plateforme de référence dépend de la complexité des applications et des contraintes de performance en temps réel et ceci est

défini intuitivement par le concepteur de système. Cependant, il convient de noter que notre algorithme pour les synthèses de multiprocesseur est par nature itératif de sorte que la plateforme de référence est mise à jour à chaque itération de haut niveau, ce qui garanti des résultats optimaux même si le concepteur de système choisi une plateforme sous optimale dans le processus de démarrage et que la sélection d’une mauvaise plateforme de référence prolonge le processus de synthèse en raison du nombre important d’itérations en jeu.

 Problème de Mapping:

Après le développement de la plateforme de référence, différentes tâches des applications sont associées sur le réseau. Comme mentionné dans la section précédente, le problème de mapping affecte deux aspects de la conception système adressée : l’architecture de processeur étendue et le trafic de réseau. Par exemple, si deux tâches consécutives T1 et T2 ont un nombre important de données à transférer entre elles, la décision de mapping devrait ou essayer d’associer ces deux tâches sur un même élément de calcul ou associer deux éléments de calcul qui sont voisins dans le réseau de telle sorte que les données n’aient pas besoin de traverser l’ensemble du réseau pour atteindre l’élément de traitement requis. De la même manière, des tâches contenant des instructions similaires devraient être associées sur un processeur étendu avec des instructions SIMD afin de réduire le coût d’espace d’implémentation de l’instruction étendue.

Dans notre algorithme, notre plateforme de référence n’inclue pas de processeurs SIMD étendus, aussi le mapping initial est effectué en premier afin de distribuer effectivement les tâches sur le MPSoC hétérogène visant à réduire les temps de calcul des éléments de traitement et les temps de communication du NoC sous-jacent. Une fois le mapping réalisé pour l’application donnée et la plateforme, des simulations sont réalisées afin d’obtenir des résultats de performance pour la configuration donnée. D’un autre côté, les résultats de consommation d’espace et d’énergie sont obtenues par la synthèse de tâches individuelles utilisant des outils de synthèses comportementales. Nous utilisons l’outil de compilateur “Celoxica's agility” mais n’importe quel outil de synthèse comportementale ou SystemC pourrait être utilise afin d’obtenir des estimations d’énergie et d’espace pour la plateforme.

 Génération de Processeur Etendu de Jeu d’Instruction SIMD Programmable: Comme mentionnée précédemment, le problème de synthèse de jeu d’instruction induit deux sous problèmes : la sélection du jeu d’instruction et l’association d’instruction. Nous simplifions le problème de sélection du jeu d’instruction en prenant l’intégralité du standard SIMD en tant que jeu d’instruction sélectionné. Par ailleurs, l’association d’instruction est réalisée par un compilateur qui vectorise chaque tâche automatiquement ou par un programmeur de logiciel qui écrit manuellement le code vectorisé efficient. Notre idée principale est de commencer à partir d’une totale implémentation d’unité SIMD connectée en parallèle au Pipeline principal d’un processeur à but général et ensuite de supprimer le matériel relié aux instructions qui n’ont pas été utilisées pour les tâches implémentées sur le processeur. La décision concernant les instructions à supprimer dépend des résultats de profilement qui donnent un type et une fréquence aux instructions utilisées pour un certain programme. En conséquence, notre processeur personnalisé comprend uniquement les instructions dont le programme a besoin pour réduire la consommation d’espace et de puissance au niveau du processeur étendu. Dans notre flux complet, nous définissons aussi le concept de classe d’équivalence pour éliminer les instructions de vecteur qui prennent plus d’espace mais qui ne fournissent pas suffisamment d’accélération à cause de leur faible fréquence dans le programme. Ces instructions de faible fréquence sont éliminées en les remplaçant avec un ou plusieurs scalaires ou avec une instruction de vecteur sachant exécuter la même fonctionnalité. Plus de détails sur la classe d’équivalence et la sélection de jeu d’instruction est hors sujet dans ce chapitre, mais si les lecteurs sont souhaitent plus d’informations sur ce sujet, ils peuvent consulter [22] .

 Simplification Réseau:

Notre algorithme d’exploration itératif peut reconfigurer la plateforme de référence après chaque itération de haut niveau. Si les contraintes de performance ne sont pas satisfaites, des noeuds complémentaires sont ajoutés dans NoC et le processus de programmation de SIMD est répété une nouvelle fois pour observer les améliorations de performance. Toutefois, si les

contraintes de performance sont satisfaites alors l’algorithme essai de réduire la complexité du réseau en supprimant certains nœuds et en répartissant les fonctionnalités implémentées à partir de ces nœuds jusqu’aux tâches SIMD implémentées au sein du processeur étendu

Une fois que les contraintes de performances sont satisfaites et que la complexité du système est suffisamment réduite, la configuration est finalisée et le concepteur peut procéder au processus d’implémentation du système à des niveaux inférieurs d’abstraction.

Documents relatifs