Index: trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/article-07sympa/fr/root.tex
===================================================================
--- trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/article-07sympa/fr/root.tex	(revision 59)
+++ trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/article-07sympa/fr/root.tex	(revision 63)
@@ -1,13 +1,136 @@
-TODO : begin reformuler
-L'augmentation de la finesse de gravure des transistors a pour conséquence une augmentation du nombre de transistors par unité de surface. Donc pour une même surface, un composant matériel peut être de plus en plus complexe. 
-TODO : end   reformuler
+% objectif
+% * utilisation de l'outil
+%  -> exploration architecturale
+%     -> sur 2 composants, parler du compromit performance/surface.
 
-Concevoir des System On Chip (SOC) devient de plus en plus complexe. Le concepteur doit utiliser des librairies de composants existants et les inter-connectés entre eux. Ces composants sont des boîtes noires et les concepteurs n'ont aucune garantie d'absence de chevaux de troie.
+\begin{abstract}
+\end{abstract}
 
-De plus ce sont des composants pour la plupart commerciaux, et il n'y a pas de garantie d'approvisionnement ou de maintient de protocole de communication.
+%===================================================================================
+\Section{Introduction}
 
-TODO : begin reformuler
-Pour cela utiliser des composants ouverts permet de s'abstraire de ces problèmes.
-TODO : end   reformuler
+L'approche actuelle pour dévelloper des systèmes embarquées est fondée sur le secret. Les composants matériels et/ou logicielle sont fermés. Les concepteurs utilisant ces Intellectual Proprity (IP) ne sont pas assuré d'absence de chevaux de troie, de la pérénité de ce composant (arrêt de la production ou changement de protocole de communication).
 
-Le nombre de processeurs ouverts sont assez restreint : l'OpenRISC 1200, le LEON, l'OpenSPARC, \dots. De plus, aucun n'exploite l'Instruction Level Paralellism (ILP). 
+La nouvelle approche se base sur l'utilisation de composant ouvert. Ceci engendre la disponibilité du code source et rendre plus facile l'intégration sur FPGA. Ceci permet d'avoir des systèmes sur puces (SOC).
+
+De telle systèmes ont des contraintes varié en terme de la performance nécessaire à l'application et à la surface disponible pour la plate-forme matérielle.
+
+Pour cela, le processeur doit exploiter tout les formes de parallélisme disponible.
+
+Une implémentation superscalaire permet d'exploiter le parallélisme des instructions en lançant 
+et exécutant plusieurs instructions indépendantes simultanément. 
+Pour cela, il faut que le processeur puisse charger depuis la mémoire plusieurs instructions, 
+les décoder simultanément, détecter les dépendances (de données et de ressources) et les lancer 
+vers les unités d'exécutions disponibles. 
+Les ressources matérielles internes de ce type d'architecture sont complexes (\cite{1997_palacharla}).  
+
+Cette complexité rend difficile l'implantation sur FPGA ({\it Field-Programmable Gate Array}) d'un processeur 
+sueprscalaire. 
+Sur un tel support technologique, le processeur va être placé dans les ressources prédéterminées du FPGA. 
+Les ressources mémoires sont limitées par leur nombre et par leur accès, de même pour les blocs logiques
+ qui sont limités par le nombre d'entrées pour les fonctions booléennes implémentées.
+
+La difficulté pour un concepteur de système intégré est de bien dimensionner 
+sa plateforme matérielle pour les applications logicielles.
+
+Pour les applications qui ont besoin de performance, le concepteur ne peut pas 
+sélectionner un softcore libre. Ces derniers n'exploitent pas le parallélisme 
+d'instruction (Instruction Level Parallelism (ILP)). 
+
+\TODO{citer OPENRISC, LEON, OPENSPARC ...}
+
+Le concepteur devra choisir entre une solution multiprocesseurs et paralléliser 
+les applications, par exemple l'architecture Piranha (\cite{2000_barroso}) 
+qui consiste en 8 processeurs alpha scalaire in-order, ou encore l'architecture de 
+l'Hydra (\cite{2000_hammond}) qui instancie 4 processeurs de type mips scalaire. 
+Une autre solution pour le concepteur est d'utiliser des processeurs exploitant l'ILP 
+mais dont le composant est fermé.
+
+Disposer d'un processeur exploitant l'ILP et synthétisable sur FPGA permet 
+d'augmenter le nombre de solutions disponibles pour le concepteur de systèmes intégrés.
+
+L'exploration architecturale va indiquer au concepteur le nombre de processeurs, 
+le déploiement de l'application et les ressources internes nécessaires pour satisfaire 
+les contraintes de performances du système. 
+De plus, durant la phase exploratoire, le concepteur va définir ces impératifs de 
+performance en suivant les contraintes de surface.
+
+Dans cette article nous allons montrer une partie du processeur MORPHEO. Ce composant 
+à pour vocation de fournir un modèle haut niveau (systemC CABA) et bas niveau (VHDL RTL) 
+d'un processeur haute performance. La partie examinée est la boucle d'exécution. Dans 
+la section suivante, nous expliquons ce qu'est la boucle d'exécution et des difficultés 
+pour l'implémenter sur FPGA. Dans la section \ref{section_3}, nous allons analyser 
+la complexité de 3 blocs fonctionnelles : le banc de registres, l'unité mémoire et
+ la station de réservation. Ensuite dans la section \ref{section_4}, nous allons poser
+ nos hypothèses de simulations, les résultats seront discuter dans la section suivante. 
+Enfin nous finirons par une conclusion et quelques perspectives.
+
+%===================================================================================
+\Section{Boucle d'exécution}\label{section_2}
+
+Un processeur à exécution désordonnée peut être décomposé en 3 parties logiques :
+\begin{description}
+\item [Front end           : ] Cette première partie consiste à charger depuis la mémoire des paquets d'instructions. Une unité de prédiction va calculer l'adresse du prochain paquet. Ensuite chaque instruction du paquet va être décodé et placer dans une file d'attente.
+\item [Out Of Order Engine : ] Cette unité s'occupe de dés-ordonnancer et de réordonnancer les instructions. Pour cela les registres vont être renommés et les instructions vont être stockées dans une file de ré-ordonnancement. Le numéro d'entrée de cette file permettra d'accéder à la bonne case une fois que l'instruction aura été exécutée. Les instructions sont enlevées de cette file dans l'ordre du programme. C'est ce composant qui vérifie les exceptions ou les erreurs de spéculations.
+\item [Execution Loop      : ] La boucle d'exécution s'occuper de lire les opérandes cibles, exécuter l'opération et écrire le résultats dans le bancs de registres. C'est également dans cette partie que les accès à la mémoire de données vont être effectués. Si l'instruction n'a pas toute ces opérandes sources, alors elle les attendra dans la station de réservation. 
+\end{description}
+
+Dans ce document, nous nous centrons sur la boucle d'exécution. Celle-ci contient des structures associatives : les stations de réservation, des bancs de registres multi ports et de la logique de routage : entre les stations de réservations et les unités d'exécutions. 
+Ces types de structures se retrouvent dans les autres parties du processeur : structure associative pour le buffer de reordonnancement, les bancs de registres multi-ports pour le renommage de registres (en particulier le Register Address Translation (RAT)).
+
+\printgraph{MORPHEO_micro_architecture-execute_loop}{0.5}{MORPHEO : Execution loop}
+
+\TODO{refaire le graphe avec un schéma plus explicite}
+
+Comme le montre le graphe \cite{MORPHEO_micro_architecture-execute_loop}, notre modèle de la boucle d'exécution est décomposé en 4 parties : l'unité de lecture, l'unité d'exécution, l'unité d'écriture et enfin le banc de registres.
+
+\TODO{parler maintenant des implémentations de la boucle d'execution ou alors dans chaque partie séparée ?}
+
+%===================================================================================
+\Section{Complexité}\label{section_3}
+
+%-----------------------------------------------------------------------------------
+\subSection{Banc de registres}
+A chaque cycle plusieurs instructions doivent accèder au banc de registres afin de soit lire leurs opérandes, soit écrire leurs résultats. Le banc de registres doit être multi-accès.
+Dans le mips R10000 (\cite{1996_yeager}), le banc de registres entier possède 7 ports de lectures et 3 ports d'écritures. Alors que l'itanium 2 (\cite{2003_mcnairy} possède un banc de registres à 12 ports de lectures et 8 ports d'écritures.
+
+Si tout les ports de lecture et d'écriture peuvent accèder à tous registres, alors le banc de registre à une implémentation monolithique. La surface et le temps d'accès aux registres augmentent avec le nombre ports.
+
+Pour diminuer le nombre de ports, le banc de registres peut être composer de plusieurs bancs ayant localement moins de ports que nécessaire. Dans l'alpha 21264 (\cite{1999_kessler}), les unités entières sont placées dans l'un des deux clusters, et dans chaque cluster il y a une copie de banc de registres. 
+
+Une autre méthode consiste à réaliser un cache de banc de registres : le cache de niveau 1 contient peu de registres et avec beaucoup de registres alors que le niveau 2 contient peu de port (voir être mono port) et contient une copie de tout les registres. Cette méthode est décrite dans \cite{2000_cruz}.
+
+
+.................
+
+
+%-----------------------------------------------------------------------------------
+\subSection{Unité mémoire}
+L'unité mémoire a pour but de réaliser les accès mémoires. Cette unité doit aussi ordonner les accès mémoires suivant le modèle de consistance mémoires. Dans un modèle relâché, les lectures peuvent être lancées dans n'importe quel ordre. Toutefois, l'unité mémoire doit garder la mémoire cohérente. C'est à dire que les écritures mémoire ne peuvent être exécuter que quand celle-ci ne sont plus spéculative et que toute instructions précèdent ne font pas d'exception. Un accès mémoire arrivant en tête du buffer de ré ordonnancement satisfait ces contraintes.
+
+Afin d'accélérer les accès en lecture, l'unité peut faire de la spéculation : faire des accès en lecture à la mémoire instruction et écrire la donnée lut dans le banc de registres avant même d'avoir vérifier que cette lecture n'a pas une dépendance d'adresse avec une écriture antérieure. Dans \cite{1998_chrysos}, Chrysos et Emer ajoute de la spéculation pour détecter les accès en écriture qui sont susceptible d'avoir des dépendances avec des accès en lecture ``proche''.
+
+L'implémentation de l'unité mémoire ce fait par l'intermédiaire de deux files circulaires : la store\_queue contient tout les écritures en attentes ainsi que la load\_queue contenant quant à elle les lectures en attente d'accès au cache et en attente d'arrivé de la réponse.
+
+Les pointeurs d'écritures de ces deux files sont gérés dans l'étage de renommage. C'est dans ce même étage que les instructions sont placées dans le buffer de réordonnancement. Si les files sont pleines alors le pipeline est arrété.
+
+
+
+%-----------------------------------------------------------------------------------
+\subSection{Station de réservation}
+La station de réservation est une structure associative (CAM). Après que les instructions ont accédées au banc de registres, elles sont placées dans les stations de réservations. Une instruction doit avoir la totalité de ces opérandes pour pouvoir être éxecutée. Toute destination d'une instruction peut être la source d'autres instructions. Pour cela toute les écritures dans le banc de registres doit être propagées vers chaque opérande de chaque entrée de chaque station de réservations. 
+
+
+
+%===================================================================================
+\Section{Simulations}\label{section_4}
+
+Les simulations sont réalisée avec les benchmarks SPECINT 2000. 
+
+%===================================================================================
+\Section{Résultats}\label{section_5}
+
+%===================================================================================
+\Section{Conclusion}\label{section_6}
+
+\bibliography{\dircommon/bibliographie}
