• Aucun résultat trouvé

Dans ce chapitre, nous avons présenté le principe des mémoires non volatiles, et en particulier la STT-MRAM. Nous avons vu que cette technologie possède des caractéris- tiques différentes de la SRAM qui soulèvent des questions quant à son intégration dans une hiérarchie de caches. En effet, malgré une diminution intrinsèque du courant de fuite, l’asymétrie en matière de latence et d’énergie et les coûts élevés en écriture sont un frein à son adoption. Pour répondre à ce problème, nous avons présenté plusieurs niveaux sur lesquels il est possible d’agir.

Modifications et utilisation des propriétés des cellules MTJ

La modification de la cellule MTJ permet d’atténuer certains désavantages de la STT- MRAM. En jouant sur la taille ou l’épaisseur de la couche magnétique, on peut diminuer la latence et l’énergie nécessaire aux transactions. Cependant, les mécanismes de contrôle ajoutés pour limiter la perte d’informations nécessitent de migrer des données. Cela gé- nère un coût supplémentaire en matière d’énergie, de latence, et affectent de manière négative l’endurance des cellules.

De plus, notre approche vise à évaluer l’impact des STT-MRAM et à trouver une so- lution au niveau architectural et non technologique. Nous sommes utilisateurs de cette nouvelle technologie et nous ne cherchons pas à l’améliorer mais à trouver comment l’in- tégrer dans une hiérarchie mémoire.

Gestion de la mémoire par le compilateur

Les approches logicielles pour gérer la technologie STT-MRAM se basent sur la modi- fication du compilateur. Ce dernier est utilisé pour analyser le comportement des appli- cations et détecter les données majoritairement lues ou écrites. Le placement des données est alors guidé par le compilateur durant l’exécution par l’insertion d’instructions spéci- fiques. Bien que portable sur toutes les architectures supportées par le compilateur, cela nécessite d’ajouter des instructions spécifiques dans le processeur pour le placement des données. Enfin, cette approche s’affranchit de la couche d’abstraction qui existe entre le compilateur et la technologie sous-jacente. En effet, ces approches nécessitent de la part du compilateur la connaissance de la technologie mémoire utilisée pour les caches.

Approches architecturales

Les approches architecturales présentées en section 3.3 ne proposent aucune explo- ration architecturale au niveau de la construction de la mémoire cache. Les auteurs pro- posent d’utiliser une technologie non volatile et se servent d’un simulateur de NVM, en

général NVSim, pour extraire des latences d’accès et des valeurs énergétiques. Aucun dé- tail n’est donné sur la façon d’obtenir ces valeurs et sur les possibilités de design.

Or, il existe un espace d’exploration conséquent lors de la conception d’une mémoire cache. Beaucoup de paramètres architecturaux existent avec une influence certaine sur les caractéristiques de la mémoire cache. Afin d’exploiter au mieux une optimisation archi- tecturale, il convient de sélectionner une configuration la plus pertinente selon des critères définis par le concepteur.

Dans cette thèse, nous proposons une méthode simple permettant de visualiser un ensemble de configurations de mémoires non volatiles et d’extraire la meilleure configu- ration selon des caractéristiques précises. Les discriminants sont à la charge de l’architec- ture, ce qui permet d’adapter cette méthode aux différentes contraintes d’intégration.

Validation expérimentale

Que cela soit pour la simulation de mémoires, d’architecture ou de l’évaluation de consommation énergétique, l’écosystème des outils présenté aux sections 2.3 et 3.4 est large et propose une multitude de possibilités pour répondre aux besoins.

Néanmoins, ces outils sont indépendants et aucune communication n’existe entre eux. De fait, l’évaluation de propositions de conception pour des architectures utilisant des mé- moires non volatiles nécessite des étapes manuelles pour i) la configuration caches NVM ii) l’intégration des ces caches dans un simulateur iii) la configuration de la plateforme à simuler et iv) le post-traitement pour une évaluation énergétique.

Ces différentes étapes empêchent le passage à l’échelle des explorations architectu- rales par la quantité de travail nécessaire en amont. Le chapitre suivant sera consacré à la définition d’un cadre d’exploration architecturale passant à l’échelle. On présentera en- suite deux implémentations automatiques et semi-automatiques respectant ce schéma et combinant un simulateur de mémoires non volatiles, un simulateur d’architecture et un framework d’évaluation de consommation énergétique.

Chapitre 4

Définition et implémentations d’un

cadre d’exploration architecturale

4.1 Cadre générique d’exploration . . . 66 4.1.1 Simulateur d’architecture . . . 66 4.1.2 Estimation des caractéristiques de mémoire émergentes . . . 66 4.1.3 Estimation de consommation d’une architecture classique . . . . 67 4.2 MAGPIE : un framework d’exploration au niveau système . . . 67 4.2.1 Présentation générale . . . 67 4.2.2 Mise en œuvre . . . 68 4.2.3 Optimisations de simulation . . . 69 4.2.4 Application sur une architecture réelle . . . 70 4.3 Explorations spécifiques pour la gestion de la mémoire . . . 73 4.3.1 Présentation générale . . . 73 4.3.2 Flot d’exécution . . . 74 4.3.3 Estimation de la consommation énergétique de la hiérarchie mé-

moire . . . 74 4.4 Résumé . . . 76

Dans ce chapitre, nous présentons un schéma de principe du cadre d’exploration né- cessaire à nos travaux. Ensuite, nous illustrons ce schéma avec deux implémentations réa- lisées à travers différents simulateurs d’architectures et modèles énergétiques.

4.1 Cadre générique d’exploration

Pour nos travaux, nous avons choisi le niveau d’abstraction logiciel. C’est la solution la plus simple à mettre en place si l’on veut évaluer l’effet de mémoires émergentes sur une hiérarchie de caches. Elle ne nécessite pas de descendre au niveau du circuit. De plus, cette thèse ne propose pas d’optimisation à un tel niveau. On se contente d’être utilisateur de ces technologies en se plaçant d’un point de vue architectural.

Le modèle générique présenté dans cette section est une version étendue d’un modèle de précédents travaux au sein de l’équipe du laboratoire [95].

4.1.1 Simulateur d’architecture

La pièce centrale de nos travaux est le simulateur d’architecture. Nous avons besoin de modèles de cœurs avec différentes caractéristiques de performance pour explorer plu- sieurs types d’architectures. L’outil doit aussi modéliser une hiérarchie mémoire complète (caches + mémoire principale) et flexible ainsi que le système d’interconnexion. Enfin, l’utilisation d’un système d’exploitation complet est un plus qui permet d’approcher la réalité d’exécution des applications via l’ordonnanceur du système.

L’outil doit être suffisamment précis pour fournir des statistiques détaillées sur les composants : nombre d’instructions exécutées, nombre de cycles nécessaires, nombre de lectures et écritures, temps d’attente du au miss etc. Nous devons également avoir des informations sur les échanges entre les blocs de l’architecture, comme la quantité de tran- sactions sur les bus.

4.1.2 Estimation des caractéristiques de mémoire émergentes

On cherche à évaluer l’impact de l’intégration de NVM dans une hiérarchie mémoire. A un niveau architectural, ces technologies influent sur trois leviers : les latences d’accès, les coûts énergétiques (dynamiques comme statiques) et la surface de silicium occupée. On a donc besoin d’un simulateur de NVM nous donnant au minimum ces trois caracté- ristiques.

Les latences d’accès sont les principales informations nécessaires à nos simulations. La flexibilité de l’architecture mémoire nous permet de changer facilement ce paramètre. Ainsi, notre modélisation comportementale des NVM se limite à une modification des latences d’accès en lecture et en écriture. Le principe de non volatilité n’est pas simulé ici car il ne nous est pas nécessaire. On considère une cellule éteinte dès lors que l’accès mémoire est terminé.

Pour l’estimation de consommation énergétique, nous devons adopter une approche analytique. Le simulateur de NVM fournit les coûts unitaires d’accès en lecture et écriture.

Le simulateur d’architecture fournit leur nombre. On peut donc calculer la consommation dynamique de la hiérarchie de caches en combinant ces valeurs. Le modèle de consom- mation de l’énergie statique utilise la puissance statique renvoyée par le simulateur de NVM et le temps d’exécution donné par le simulateur d’architecture.

4.1.3 Estimation de consommation d’une architecture classique

A la différence des travaux précédents [95], nous étendons le flot générique par l’ajout d’une estimation de la consommation énergétique de la totalité de l’architecture. Nous considérons ici la perspective de la mémoire cache où est intégrée la STT-MRAM comme trop réductrice car elle ne permet pas de mesurer pleinement l’impact total de cette tech- nologie. En effet, ses aspects négatifs en matière de latences influent sur le temps d’exé- cution des applications, et donc sur l’énergie statique de toute la hiérarchie mémoire. Il est donc important de considérer les caches SRAM lors des évaluations.