Les Architectures Multiprocesseurs

Les Architectures Multiprocesseurs 

Classification des architectures multiprocesseurs

Il existe deux grandes classes d’architectures multiprocesseurs, suivant que les processeurs partagent ou non l’espace d’adressage entre les différentes tâches qui s’exécutent sur les unités de traitement.

Les architectures à mémoire distribuée

Dans une architecture multiprocesseurs à mémoire distribuée, chaque processeur possède son propre espace d’adressage et dispose donc d’une mémoire privée dans laquelle il est le seul à pouvoir lire et écrire. Les tâches s’exécutant sur deux processeurs distincts, communiquent entre elles par passage de message.

Les architectures à mémoire partagée

Dans les architectures à mémoire partagée, tous les processeurs accèdent au même espace d’adressage. La mémoire est logiquement partagée, cependant elle peut être physiquement distribuée sur la puce : il s’agit des architectures NUMA (Non Uniform Memory Access).

Dans ce cas l’architecture est souvent décomposée en sous systèmes, appelés clusters, où chaque cluster contient un petit nombre de processeurs et un contrôleur mémoire permettant d’accéder à une tranche de l’espace adressable. Dans le cadre de cette thèse, nous visons particulièrement les architectures manycore à mémoire partagée clusterisées de type NUMA pour deux principales raisons :
– Le caractère régulier de ces architectures facilite la modélisation énergétique. En effet on admet que modéliser une architecture clusterisée revient à modéliser un cluster et le réseau qui relie les différents clusters entre eux.
– La plupart des machines multiprocesseurs généralistes (ordinateurs personnels, serveurs de calculs) utilisent un modèle basé sur la mémoire partagée. Pour comprendre comment modéliser la consommation énergétique au sein d’une architecture manycore à mémoire partagée de type NUMA, il faut d’abord comprendre les sources et l’évolution de la consommation dans de telles architectures.

Consommation énergétique dans les systèmes manycore

la consommation énergétique a toujours été un facteur important dans la conception des circuits intégrés aussi bien pour les systèmes fixes que pour les systèmes mobiles. Dans le cas des systèmes mobiles, minimiser l’énergie consommée permet d’augmenter la durée de vie des batteries et donc leur autonomie. Dans le cas des systèmes fixes, la performance du système est plus importante que son autonomie. Cependant, la performance et la consommation sont étroitement liées puisqu’augmenter la vitesse de traitement revient à augmenter la fréquence de fonctionnement et donc la puissance consommée ce qui augmente le coût du système de refroidissement. L’énergie consommée est la somme de deux parties : une partie dynamique et une partie statique. La consommation dynamique est due à l’activité du circuit plus précisément au changement d’états des transistors tandis que la consommation statique est reliée aux courants de fuites. Les courants de fuites circulent entre la grille et le substrat dès que le circuit est alimenté indépendamment du changement d’état du transistor.

Contrôle de la consommation énergétique 

Au sein d’une puce, la puissance thermique dissipée par un transistor, lorsqu’il change d’état, se propage vers tous les transistors voisins. De ce fait, la température d’une unité ne dépend pas seulement de la puissance dissipée par cette unité, mais également de celle dissipée par les unités voisines. Quand la température de la puce augmente, ceci favorise la circulation des courants de fuites. On se retrouve ainsi dans un cercle vicieux qui lie la température aux courants de fuites. De plus le phénomène de dissipation thermique ne se produit pas de la même façon au centre et sur les bords de la puce. En effet il est plus facile de dissiper la chaleur des unités qui se trouvent en périphérie. Au regard de toutes ces complications liées à la consommation des circuits intégrés, comment les architectures manycore peuventelles nous offrir à la fois de meilleures performances et une basse consommation ? L’avantage des architectures manycore est qu’elles présentent généralement une régularité dans leur structure (exemple : découpage en clusters identiques). Elles offrent la possibilité de gérer le voltage et la fréquence de fonctionnement de chaque processeur ou de chaque cluster indépendamment des autres. Ainsi, il est possible d’éteindre les processeurs qui ne sont pas utilisés ou baisser leur fréquence de fonctionnement. Une telle technique s’appelle DVFS (Dynamic Voltage Frequency Scaling). Elle permet de diminuer la consommation des circuits intégrés pendant leur exécution. Une autre façon de diminuer la consommation consiste à inhiber le signal d’horloge de certains composants lorsqu’ils ne sont pas utilisés : il s’agit du «clock gating». Les deux méthodes DVFS et «clock gating» agissent sur la consommation du circuit pendant son fonctionnement «on line».

Évaluation précoce de la consommation énergétique

L’estimation de la consommation d’un système embarqué peut être réalisée à plusieurs niveaux d’abstraction. La précision de cette estimation est meilleure quand elle est réalisée sur une description du circuit proche de la réalisation physique telle que le niveau porte logique et le niveau RTL. Au niveau porte logique, la puissance dynamique est dissipée suite à un changement de valeur d’un signal c’est à dire d’un fil physique entre deux portes. Il suffit donc de détecter tous les événements de ce type pour évaluer la valeur totale de l’énergie consommée. L’estimation obtenue est très précise puisque l’on utilise une description du circuit fidèle à l’implémentation finale. Cette proximité du système final constitue à la fois un avantage et un inconvénient puisque elle permet d’avoir une bonne précision en contre partie d’un temps de simulation très long. Pour gagner en vitesse d’estimation, on peut utiliser une description plus gros grain du système tel que la description RTL (Resgister Transfer Level). Au niveau RTL le système est composé de registres. Pour modéliser la consommation à ce niveau il suffit de considérer le changement de l’état d’un registre comme source de dissipation d’énergie. Ce second type d’évènement étant
plus abstrait, on perd cependant de précision. De plus, au niveau RTL, les temps de simulation et les efforts de codage restent importants. Avec l’arrivée des MPSoC, la nécessité d’une étude à des niveaux d’abstraction plus hauts de la puissance dissipée est devenue une évidence. La figure 2.5 montre que le plus tôt on intervient dans le cycle de fabrication des circuits intégrés pour minimiser la consommation, meilleurs sont les résultats. En effet, selon L’ITRS (International Technology Roadmap for Semiconductors), intervenir au niveau comportemental permet de réduire la consommation totale du système final de 40% contre 20% au niveau physique. L’étude de la consommation électrique au niveau comportemental relève du prototypage virtuel. Il existe plusieurs niveaux d’abstraction pour le prototypage virtuel suivant la précision avec laquelle on décrit les différents types de contention dans le matériel qui affectent les temps d’exécution : MISS sur les mémoires caches, bande passante limitée des bus, etc. A ce niveau les évènements significatifs du point de vue énergétique sont encore plus abstraits. Il s’agit par exemple de l’exécution d’une instruction par un processeur ou d’un MISS sur le cache processeur. Les descriptions comportementales les plus précises dites « Cycle Accurate » modélisent précisément les caches et différents bus du système. Il est possible de simplifier encore plus la description comportementale du système considéré en se passant de la dimension temporelle. Il s’agit du niveau comportemental qui ne décrit pas les contentions.

SoCLib

SoCLib [2] est une plate-forme de prototypage virtuel permettant la modélisation et la simulation efficace de plate-formes multiprocesseurs à espace mémoire partagé. Le coeur de la plate-forme SoCLib est une bibliothèque de modèles de simulation pour les composants matériels (IP cores) constituant les briques de base de ces systèmes. Les modèles de simulation sont écrits en utilisant le langage SystemC. La plate-forme SoCLib fournit deux types de modèles de simulation
– Les modèles de niveau CABA (Cycle-Accurate and Bit-Accurate) [3], qui permettent une évaluation précise des performances.
– Les modèles de niveau TLM-T (Transaction Level Model with Timing) [4] qui permettent une réduction des temps de simulation au prix d’une légère perte de précision temporelle.

En plus de cette bibliothèque, la plate-forme SoCLib fournit des outils logiciels aux concepteurs d’applications embarquées : accélérateurs de simulation, systèmes d’exploitation embarqués temps réel, outils de configuration, outils de déverminage et outils de qualification des modèles. Tous les composants matériels disponibles dans SoCLib respectent le protocole de communication VCI [5]. La plate-forme SoCLib possède deux caractéristiques qui nous intéressent particulièrement :
– La plupart des modèles sont génériques et il est donc possible d’ajuster différents paramètres matériels tels que la taille des caches, la capacité des bancs mémoires, ou bien la latence et le débit de l’infrastructure de communication. Tous ces paramètres jouent à la fois sur la performance et la consommation énergétique.
– Tous les composants matériels disponibles possèdent un modèle RTL synthétisable, ce qui permet donc la synthèse physique sur FPGA, ou sur ASIC.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport-gratuit.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

1 Introduction
2 Problématique
2.1 Les Architectures Multiprocesseurs
2.2 Classification des architectures multiprocesseurs
2.2.1 Les architectures à mémoire distribuée
2.2.2 Les architectures à mémoire partagée
2.3 Consommation énergétique dans les systèmes manycore
2.4 Contrôle de la consommation énergétique
2.5 Évaluation précoce de la consommation énergétique
2.6 SoCLib
2.7 Le projet TSAR
2.8 Conclusion
3 État de l’art
3.1 Les différentes approches d’estimation de la consommation des systèmes embarqués
3.2 Estimation de la consommation bas niveau
3.2.1 Estimation de la consommation au niveau transistor
3.2.2 Estimation de la consommation au niveau portes logiques
3.2.3 Estimation de la consommation au niveau RTL (Register Transfer Level)
3.2.4 Conclusion
3.3 Estimation haut niveau
3.3.1 WATTCH
3.3.2 AVALANCHE
3.3.3 PowerViP
3.3.4 MCPAT
3.3.5 HSL (Hybrid System Level Power Consumption Estimation)
3.4 Conclusion
4 EDPE : Méthode d’estimation précoce de la consommation des architectures MPSoCs
4.1 EDPE : Principe
4.2 Plate-forme d’étude
4.2.1 Le processeur : MIPS32
4.2.2 Le cache : XCache
4.2.3 L’Interconnect : Ring
4.2.4 La mémoire : VCI-Simple-RAM
4.3 Les modèles de consommation
4.3.1 Le modèle du processeur
4.3.2 Le modèle du Cache
4.3.3 Le modèle du Bus
4.3.4 Le modèle des mémoires : RAM/ROM
4.3.5 Le modèle énergétique de la plate-forme
4.4 Instrumentation de la plate-forme
4.5 Mesure de la puissance consommée
4.5.1 Mesures physiques sur FPGA
4.5.2 Mesure de la consommation avec PowerPlay
4.5.3 Comparaison entre les deux méthodes
4.6 Les Modes de fonctionnement
4.6.1 Mode 0 : STATIC
4.6.2 Mode 1 : DCACHE-RING-RAM
4.6.3 Mode 2 : PROC-ICACHE
4.6.4 Mode 3 : RING-ROM
4.6.5 Mode 4 : ICACHE-RAM
4.6.6 Mode 6 : DCACHE
4.6.7 Mode 7 : RAM-READ
4.6.8 Mode 8 : DCACHE-RAM-WRITE
4.6.9 Mode 9 : RAM-WRITE
4.6.10 Mode 10 : DCACHE-RAM-READ-AND-WRITE
4.6.11 Mode 11 : PROC-STUTTER
4.7 Conclusion
5 Conclusion

Rapport PFE, mémoire et thèse PDFTélécharger le rapport complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *