Projet : CAPS - caps

<body bgcolor="#FFFFFF" text="#000000" link="#9944EE" vlink= "#0000FF" alink="#00FF00"> <h2><a name="SECTION00033000000000000000" id= "SECTION00033000000000000000">Simulation de processeurs et collecte de traces</a></h2> <a name="CAPS_fondements_module-8" id= "CAPS_fondements_module-8"></a> <p><strong>Mots clés :</strong> <i>collecte de traces, simulation .</i></p> <h3>Résumé :</h3> <div class="ABSTRACT"> <i>La validation des nouvelles idées en architecture de processeurs passe par la simulation la plus précise possible du microprocesseur et de tout son environnement. Cette simulation doit être faite cycle par cycle et doit tenir compte de l'ensemble des interactions à l'intérieur du processeur. De plus cette simulation doit être faite sur des applications si possible représentatives de la charge d'un processeur dans son environnement potentiel d'utilisation.</i> <p><i>Deux approches sont utilisées, la simulation dirigée par l'exécution et la simulation dirigée par les traces. Nous décrivons ici ces deux approches, leurs intérêts et limitations réciproques.</i></p> </div> <p>Afin de valider, au niveau performance, les architectures de processeurs, la simulation est le seul outil accepté aussi bien par l'industrie que par la communauté de recherche. Cette simulation doit être faite avant le début de la conception matérielle.</p> <p>Cette simulation doit être la plus précise possible et tenir compte de l'ensemble des interactions à l'intérieur du processeur. Deux approches peuvent être utilisées : la simulation dirigée par les traces et la simulation dirigée par l'exécution.</p> <p>La simulation d'architecture dirigée par les traces présente l'avantage de décorréler la simulation de l'architecture de la collecte de traces [<a href= "bibliographie_Toc.html#Uhlig97" target="contents">UM97</a>]. Ainsi on pourra simuler une architecture en lui fournissant la trace de l'exécution d'une application c'est-à-dire par exemple la liste des instructions exécutées et des adresses accédées en mémoire. Cette approche a été utilisée depuis très longtemps en architecture de processeurs. Les traces peuvent être collectées soit par matériel, soit par logiciel.</p> <p>La collecte de traces d'exécution par matériel (analyseur logique) a été utilisée tant que les données et instructions circulaient sur les pattes d'entrées/sorties des processeurs. Sur les processeurs actuels, la collecte de traces ne peut plus être faite de cette manière. Ce qui explique que la collecte de traces par instrumentation logicielle soit la plus utilisée par la recherche en architecture (et aussi par l'industrie). Des outils adaptés à chaque jeu d'instructions sont aujourd'hui disponibles (Pixie, Atom, spy, <small>EEL</small>,...). Ces outils présentent le défaut de ne pouvoir tracer qu'une seule application et ne permettent pas en général de tracer l'activité système du processeur. Enfin le ralentissement des applications tracées est considérable (facteur 10-100) et ne permet pas d'envisager le traÇage réaliste d'applications de grande taille (plusieurs centaines de milliards d'instructions). Enfin, elle est inappropriée pour la simulation réaliste de processeurs permettant l'exécution spéculative (c'est-à-dire prédisant les branchements et exécutant dans le désordre) : l'exécution spéculative requiert l'accès (en lecture) aux instructions de la fausse branche ainsi qu'aux données en mémoire de l'application tracée.</p> <p>La simulation dirigée par l'exécution nécessite <i>l'exécution</i> par le simulateur de l'application tracée elle-même. Cette approche permet contrairement à la simulation dirigée par les traces de simuler l'impact des instructions exécutées spéculativement. Cependant cette approche peut s'avérer extrèmement lourde puisqu'il faut être capable de simuler non seulement le code directement écrit par le développeur, mais aussi les appels à des bibliothèques dynamiques et les appels systèmes, c'est-à-dire toutes les opérations susceptibles de modifier le contenu de la mémoire associée à l'application tracée. Cette approche a été suivie dans le simulateur SimOS. SimOS [<a href= "bibliographie_Toc.html#Rosemblum95" target= "contents">RHWG95</a>] est le simulateur complet d'une station <small>MIPS</small> ``bootant'' le système Irix. L'avantage de <small>S</small>im<small>OS</small> est ainsi de permettre de simuler un processeur avec l'ensemble de son système d'exploitation. Par contre, les performances de la simulation restent très limitées et ne permettent pas d'envisager la simulation des ``grosses'' applications (plusieurs centaines de milliards d'instructions).</p> <p>Le constat global est que la majeure partie des études pour les architectures de <i>demain</i> sont faites sur des traces d'applications dont on a souvent réduit le volume pour permettre des temps de simulation acceptables. Ceci peut conduire à des erreurs majeures pour le dimensionnement de structures telles que prédicteurs de branchement, antémémoire ou <small>TLB</small>s (cache de traduction d'adresses). Le challenge en recherche pour la simulation réaliste d'architectures de processeurs est en fait, aujourd'hui, de parvenir à simuler le comportement des applications en vraie grandeur et dans leur environnement système.</p> </body>