Index: trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/document-cache-specification/fr/01_introduction.tex
===================================================================
--- trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/document-cache-specification/fr/01_introduction.tex	(revision 45)
+++ trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/document-cache-specification/fr/01_introduction.tex	(revision 45)
@@ -0,0 +1,83 @@
+\Section{Introduction}\label{introduction}
+\subSection{Motivations}
+Les processeurs haute performance lancent plusieurs instructions, de manière non ordonnée, spéculativement et provenant de plusieurs contextes matériels. Le processeur va donc exécuter plusieurs flots d'instructions contenant des accès mémoires et qui ne sont pas forcéments utiles (car spéculatif). Pour ces raisons, un défaut de cache (MISS) doit éviter de bloquer le processeur. Le cache doit être non bloquant, c'est à dire qu'il doit pouvoir accepter de nouvelles requêtes venant du processeur pendant le traitement d'un défaut d'une requête précédente.
+
+\subSection{Constitution du document}
+Le document axé accès en cinq parties :
+\begin{itemize}
+\item Section \ref{introduction}     : la section actuelle présente le comportement que doit avoir le cache, ainsi que les paramètres retenus.
+\item Section \ref{overview_partial} : dans un second temps, nous allons présenter une architecture qui satisfait les requêtes courantes (lectures / écritures, succès / échec) sur des adresses non conflictuelles. Cette première architecture est utilisable dans la majorité des cas.
+\item Section \ref{problem}          : dans cette section, nous allons analyser les problèmes arrivant lors d'accès à des adresses conflictuelles, et/ou dans un environnement multi contextes. Pour chaque problème, nous proposons plusieurs solutions et nous énumérons leurs avantages et inconvénients.
+\item Section \ref{overview_full}    : cette section est la synthèse des deux précédentes. Nous allons modifier l'architecture de départ afin d'introduire des solutions aux problèmes énumérés dans la section \ref{problem}.
+\item Section \ref{optimisation}      : cette dernière section présente quelques optimisations pouvant être apportées au modèle défini dans la section \ref{overview_full}.
+\end{itemize}
+
+\subSection{Paramètres}
+Dans cette sous section, nous allons définir les paramètres du cache ainsi que les paramètres de l'interface entre le cache et le processeur.
+
+Pour chaque paramètre, nous précisons :
+\begin{enumerate}
+\item Une courte description présentant le paramètre
+\item Un nom qui sera utilisé dans la suite du document
+\item Un intervale de valeurs que peut prendre le paramètre
+\item Un pas qui indique la fonction à appliquer pour passer d'une valeur à l'autre.
+\end{enumerate}
+
+\subsubSection{Paramètres interne du cache}
+
+\begin{center}
+  \begin{tabular}{|ll|ccc|}
+    \hline
+    Paramètres                   &             &                       Min &                            Max & Pas \\
+    \hline
+    Taille du mot                & SIZE\_WORD  &                   32 bits &                        64 bits &  *2 \\
+    Nombre de lignes par mot     & NB\_WORD    &                     1 mot &                        64 mots &  *2 \\
+    Nombre de lignes             & NB\_LINE    &                   1 ligne &                    1024 lignes &  *2 \\
+    Associativité                & ASSOC       & 1 banc de NB\_LINE lignes & 16 bancs de NB\_LINE/16 lignes &  *2 \\
+    Taille des files internes    & SIZE\_QUEUE &                    1 case &                       64 cases &  *2 \\
+    Nombre de requêtes pendantes & MAX\_REQ    &                2 requêtes &                    64 requêtes &  *2 \\
+    \hline
+  \end{tabular}
+\end{center}
+
+\printgraphonly{CACHE_parameters}{.8}
+
+La taille du cache est $NB\_LINE * NB\_WORD * SIZE\_WORD~bits$.
+
+\subsubSection{Paramètres de l'interface cache / processeur}
+
+\begin{center}
+  \begin{tabular}{|ll|ccc|}
+    \hline
+    Paramètres                              &             &     Min &     Max & Pas \\
+    \hline
+    Taille d'une donnée                     & SIZE\_DATA  & 32 bits & 64 bits &  *2 \\
+    Taille de l'adresse                     & SIZE\_ADDR  & 32 bits & 64 bits &  *2 \\
+    Taille de l'identifiant du propriétaire & SIZE\_TRDID &  0 bits &  4 bits &  +1 \\
+    Taille de l'identifiant de transaction  & SIZE\_PKTID &  0 bits &  4 bits &  +1 \\
+    \hline
+  \end{tabular}
+\end{center}
+
+\subSection{Comportement}
+\begin{description}
+\item[Hierarchie mémoire : ] La hierarchie mémoire consiste à placer plusieurs mémoires entre le processeur et la mémoire principale. Le niveau d'un cache représente sa localisation par rapport au processeur. Plus le niveau est bas, plus le cache est proche du processeur. Un défaut de cache demande l'envoye d'une requête vers le niveau suivant (le niveau supérieur). Ce cache est prévu pour être un cache de niveau 1 (communiquant directement avec le processeur) et est également le cache qui communique avec le bus système.
+\item[Write through      : ] L'ajout d'un cache dans un système va provoquer une duplication des données. Lorsque le processeur va effectuer une requête d'écriture, le cache à l'obligation de modifier également la mémoire. Soit il le fait à chaque écriture, soit il attend l'évincement de la ligne. Ce cache implémente la statégie des écritures simultanées (Write Through) : chaque donnée est à la fois écrite dans le bloc du cache et dans le bloc de la mémoire de niveau supérieur. Ce protocole provoque une augmentation du trafic sur le bus, mais rend le cache plus simple et permet une gestion de la cohérence mémoire plus simplement.
+\item[Write no allocate  : ] Nous avons vus précédement qu'à chaque écriture, le processeur va également provoquer une écriture au niveau mémoire suivant. Il y a également une mise à jour du cache si la ligne est présente. Mais en cas d'absence de la ligne, faut il la rappatrier dans le cache? Si oui, il s'agit d'une écriture alloué. Or ce cache fait des écritures non alloué (Write no allocate). C'est à dire que les échecs d'écriture n'affectent pas le cache, le bloc n'est modifié que dans le niveau mémoire supérieur. Ceci permet de limiter le traffic sur le bus et de ne pas évincer une ligne qui peut encore être utile au profint d'une ligne pouvant ne pas être utile (le processeur est une architecture load-store : quand le programme écrit une variable en mémoire c'est que la variable est en fin de vie).
+\item[Cache associatif   : ] Un cache peut stocker plusieurs lignes de cache. Mais où peut on stocker une ligne précise dans le cache? S'il n'y a qu'une place possible alors le cache est appellé {\it direct map}, si le ligne peut être stockée n'importe où dans le cache alors le cache est appellé {\it full associatif}. Entre ces deux extrêmes, il y a les caches {\it semi-associatif}. Le cache est alors découpé en N bancs contenant chacun un nombre de lignes identiques. Une ligne peut être placée dans n'importe quel banc, mais ne peut être stockée qu'à un seul endroit dans chaque banc. Selon cette définition, un cache {\it direct map} ne contient qu'un seul banc alors qu'un cache {\it full associatif} n'a qu'une seule ligne par banc. Le cache que nous spécifions est {\it semi-associatif} qui est un bon compromit entre la compléxité et la performance.
+\item[Non bloquant       : ] Il s'agit de la principal caractéristique de notre cache. Comme expliquer en introduction, le cache est partagé entre plusieurs contextes, et cache contexte execute leurs instructions de manières désordonnées et spéculative. Un défaut de cache ne doit pas bloquer le cache. 
+\item[Processeur avec consistance mémoires relachées : ] Du point de vue du programmeur, les accès mémoires doivent se faire dans l'ordre du programme et que chaque accès mémoire doivent être lancée après que toute les instructions précédents soient terminées. Ceci assure une consistance mémoire parfaite, mais la dégradation de performance est catastrophique. Pour cela les processeurs implémentes des modèles de consistances mémoires relachés. Dans notre cas, le cache doit gérer les problèmes de consistance mémoire.
+\end{description}
+
+\subSection{Hypothèse de travail}\label{hypothese}
+
+Nous allons supposer que le cache sera connecté à un processeur superscalaire d'ordre 4, que le code exécuté contient 20\% d'instructions de lectures et 10 \% d'instructions d'écritures. Nous avons donc en moyenne 4*30\%=1.2 accès mémoire par cycle. 
+Si nous ciblons un cache ayant au minimum 90\% de réussites, nous obtenons alors les ratios suivants :
+\begin{itemize}
+\item 60 \% de lectures qui réussissent.
+\item 30 \% d'écritures qui réussissent.
+\item 6,6\% de lectures qui échouent.
+\item 3,3\% d'écritures qui échouent.
+\end{itemize}
+
+On va supposer qu'un aller retour entre le processeur et la mémoire principal à une latence de 30 cycles en moyennes.
Index: trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/document-cache-specification/fr/02_overview_partial.tex
===================================================================
--- trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/document-cache-specification/fr/02_overview_partial.tex	(revision 45)
+++ trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/document-cache-specification/fr/02_overview_partial.tex	(revision 45)
@@ -0,0 +1,144 @@
+\Section{Vue d'ensemble du cache - Modèle simplifié}\label{overview_partial}
+
+\printgraphonly{CACHE_overview_basic}{.8}
+
+Dans un premier temps, nous allons montrer un modèle qui satisfait les cas de requêtes courantes : read hit, write hit, read miss et write miss, sur des adresses non conflictuelles.
+
+Afin de réaliser un cache non bloquant, nous avons séparé l'interface des requêtes (à gauche sur les schémas), de l'interface des réponses (à droite sur les schémas). Ces interfaces sont eux même décomposées en deux parties : ceux impliquant le processeur (en haut sur les schémas) et ceux impliquant le bus (en bas sur les schémas). Le cache est donc découpés en 4 sections différentes : 
+\begin{enumerate}
+\item {\bf SECTION\_DCACHE\_REQ :} Les requêtes émisent par le processeur.
+\item {\bf SECTION\_DCACHE\_RSP :} Les réponses à retourner au processeur.
+\item {\bf SECTION\_VCI\_REQ    :} Les requêtes à émettre au bus.
+\item {\bf SECTION\_VCI\_RSP    :} Les réponses retournées par le bus.
+\end{enumerate}
+
+Chaque partie est controlée par un automate et la communication entre deux sections ce fait par l'intermédiaire de files d'attentes (de type FIFO). Les ressources partagées sont les bancs mémoires contennant les lignes de caches ainsi que les informations sur les requêtes en cours de traitements.
+
+Nous allons maintenant voir les différents blocs internes :
+\begin{itemize}
+\item Quatre automates : 
+  \begin{description}
+  \item[FSM\_DCACHE\_REQ :] Cette automate gère la section {\bf SECTION\_DCACHE\_REQ}. Il gère l'écriture dans la QUEUE\_READ\_HIT, l'écriture dans la QUEUE\_REQ, l'allocation d'une entrée dans la RAM\_INFO et la lecture de RAM\_TAG et RAM\_DATA et enfin gère un porte d'écriture dans RAM\_DATA. 
+
+Pour chaque requête venant du processeur, l'adresse est envoyée au bloc RAM\_TAG. Ce dernier indique si la ligne contenant l'adresse demandée est dans le cache et, dans le cas d'un cache non direct map, retourne le numéro de banc contenant l'adresse. Si la requête est une lecture, alors avec le numéro de banc et le numéro de ligne, le cache va lire dans RAM\_DATA la donnée désirée. 
+
+Si la requête est une écriture qui fait un succès, alors la donnée est écrite dans le bloc RAM\_DATA.
+
+Quelque soit le type de la requête, si cette dernière est acceptée par la section {\bf SECTION\_DCACHE\_REQ}, nous allons allouer une entrée dans le bloc RAM\_INFO. Un identifiant sera retourné lors de l'allocation. Pendant l'allocation, nous allons également stocker dans le bloc RAM\_INFO toute les informations concernant la requête : type, adresse, donnée ... L'identifiant permettra d'accéder à ces informations dans les différentes sections du cache.
+
+L'automate ne peut plus accepter de requêtes si l'une des RAM est occupée ou si la file de destination est pleine (la file de destination dépends de la requête).
+  \item[FSM\_DCACHE\_RSP :] Cette automate gère la section {\bf SECTION\_DCACHE\_RSP}. Il gère la lecture du bloc QUEUE\_READ\_HIT, la lecture de QUEUE\_RSP, la désallocation d'une entrée dans la RAM\_INFO et la mise à jour des blocs RAM\_TAG et RAM\_DATA.
+
+La plupart des requêtes envoyées par le processeur, par l'intermédiaire de l'interface DCACHE\_REQ, ont besoin qu'une réponse soit retourné au processeur. Ceci se fait par l'intermédiaire de l'interface DCACHE\_RSP. Les réponses peuvent provenir de deux files d'attentes : soit QUEUE\_READ\_HIT dans le cas d'une lecture avec succès, soit ,pour tout les autres cas, QUEUE\_RSP. 
+
+Les informations étant stockées dans le bloc RAM\_INFO, les files d'attente contiennent un identifiant permettant d'adresser ce bloc. Lors d'une transaction réponse avec le processeur, le bloc RAM\_INFO va désallouer l'entrée concernée par la réponse. 
+
+Les requêtes provenant de la file QUEUE\_RSP vont modifier le cache : soit en écrivant une ligne complète (read - miss) soit en écrivant une donnée (write - miss). Les requêtes provenant de la file QUEUE\_READ\_HIT vont modifier le bit de validité contenant dans le bloc RAM\_TAG (par exemple : invalidate et flush).
+
+L'automate ne peut plus envoyer de réponses au processeur si l'une des RAM est occupée ou les files d'attente sont vides.
+  \item[FSM\_VCI\_REQ    :] Cette automate gère la section {\bf SECTION\_VCI\_REQ}. Il contrôle la consommation d'une requête dans la file QUEUE\_REQ, la lecture de l'information de la requête dans le bloc RAM\_INFO et l'envoye des requêtes sur l'interface VCI\_REQ.
+
+Toutes les requêtes d'écriture (car politique {\it write through}) et les échecs de lectures transitent par cette section. Les requêtes d'écritures et les accès mémoires non cachés vont provoquer l'envoye d'un paquet requête sur le bus (la section {\bf SECTION\_VCI\_RSP} devra recevoir un paquet réponse). Une lecture cachée va provoquer l'envoye de (NB\_WORD * SIZE\_WORD) / SIZE\_WORD\_VCI paquets requêtes. (SIZE\_WORD\_VCI représente la largeur d'une donnée transitant sur VCI. De plus il faut que SIZE\_WORD soit multiple de SIZE\_WORD\_VCI)
+
+\printgraphonly{CACHE_bloc_COUNTER}{.8}
+
+Comme le montre le graphe \ref{CACHE_bloc_COUNTER}, l'adresse envoyée est la concaténation entre un compteur et l'adresse de la requête (plus précisement c'est le Tag et l'Index de l'adresse qui est nécessaire).
+La consommation d'une entrée dans la file QUEUE\_REQ ce fait lorsque l'intégralité des paquets sont envoyés.
+
+L'automate ne peut plus envoyer de requête au bus VCI si la RAM\_INFO est occupée et/ou si la file d'attente QUEUE\_REQ est vide.
+  \item[FSM\_VCI\_RSP    :] Cette automate gère la section {\bf SECTION\_VCI\_RSP}. Il contrôle la réception des réponses par le bus VCI et les stocke dans la file QUEUE\_RSP.
+
+Chaque paquet requête VCI provoque la réception d'un paquet de réponse. Seul les échecs de lecture cachée vont avoir plus d'un paquet réponse. La ligne en cours de réception est stockée dans un tampon. Une fois le paquet de fin reçu, le contenu du tampon ou la réponse sera stocké dans la file QUEUE\_RSP. 
+
+L'automate ne peux plus accepter de réponse VCI si QUEUE\_RSP est plein.
+  \end{description}
+\item Trois files d'attentes :
+  \begin{description}
+  \item[QUEUE\_READ\_HIT :] Toute requête provenant du processeur et qui n'accède pas au bus VCI passe par cette file. Elle contient les requêtes de lectures cachés ayant fait un succès. 
+
+Les informations sont stockés dans le bloc RAM\_INFO, cette file ne contient qu'un index permettant d'adresser le bloc RAM\_INFO.
+  \item[QUEUE\_REQ       :] Toutes les requêtes qui ne sont pas stocké dans la file QUEUE\_READ\_HIT sont alors stockés dans la QUEUE\_REQ. Il s'agit des écritures ou des lectures ayant fait un MISS ou réalisant un accès non cacheable. 
+
+Cette file est à la frontière entre les sections {\bf SECTION\_DCACHE\_REQ} et {\bf SECTION\_VCI\_REQ}.
+  \item[QUEUE\_RSP       :] Chaque paquet requête émit sur l'interface VCI\_REQ provoque l'émission par la cible d'un paquet réponse. Une fois que la réponse entière est revenu au cache, elle est stockée dans la file QUEUE\_RSP. A la différence des deux autres files d'attente, elle ne contient pas qu'une adresse vers une entrée du bloc RAM\_INFO. Chaque entrée contient une ligne de cache provenant d'un échec de de lecture, ainsi que le code d'erreur envoyé par la cible. 
+
+L'automate {\bf FSM\_DCACHE\_RSP} donne la priorité au réponse car le processeur à effectué depuis plusieurs cycle l'accès et attend une éventuelle réponse. Cette file n'a pas besoin d'avoir beaucoup d'entrées.
+  \end{description}
+\item Trois blocs mémoires : 
+  \begin{description}
+  \item[RAM\_DATA :] Cette ram contient toute les données du cache. Elle est décomposé en autant de banc que le degré d'associativité du cache (ASSOC). Pour indexer une ligne particulière, il faut donc le numéro de la ligne (l'index) et le numéro de banc. Chaque ligne contient plusieurs mots. Un mot particulier est adressé par le déplacement contenu dans l'adresse (l'offset). Enfin un mot est composé de plusieurs octects, qui est l'unité la plus petit que peut modifier le processeur.
+
+ Cette ram possède un port d'écriture : il est accédé lors de la section {\bf SECTION\_DCACHE\_RSP} et va écrire, dans le cas d'un échec de lecture, une ligne complète dans la RAM\_DATA. Ce port est accèder lors de la section {\bf SECTION\_DCACHE\_RSP}.  La section {\bf SECTION\_DCACHE\_REQ} va soit lire un mot dans le cas d'un read-hit, soit écrire un mot dans le cas d'un write-hit. Pour cela, il y a un port pour réaliser ces deux accès.
+  \item[RAM\_TAG  :] Ce bloc mémoire contient les informations du contrôle du cache. Pour chaque ligne du cache contenus dans RAM\_DATA, nous sauvegardons deux informations : un bit de validité, qui indique si la ligne correspondante contient des données valide ou non, et un champ Tag qui contient l'étiquette de la ligne de cache. 
+
+Le bloc RAM\_TAG possède 2 ports : le premier est un port de lecture contrôlé par la section {\bf SECTION\_DCACHE\_REQ}. Une requête provenant du  processeur accède aux informations de la ligne de cache, le bloc RAM\_TAG va lire simultanément tous les tag de chaque banc et indiquer si l'accès réalise un succès. Si c'est le cas, il fournit le numéro de banc le réalisant. Le deuxième port est un port d'écriture accèdé lors de la section {\bf SECTION\_DCACHE\_RSP}. Après avoir choisit une victime (donc un numéro de banc pour la ligne de cache), nous allons enregistrer dans cette mémoire son étiquette et placer le bit de validité à 1.
+  \item[RAM\_INFO :] Ce bloc contient toute les informations des requêtes en cours de traitement (requêtes pendantes). Nous avons centralisé toutes les informations des requêtes dans une seule mémoire. Ceci permet de ne pas dupliquer les informations. Le nombre d'entrée de cette mémoire représente le nombre maximales de requêtes pendantes. 
+
+    Il y a 3 ports à cette mémoire : le premier est utilisé lors de la section {\bf SECTION\_DCACHE\_REQ} qui consiste à demander au bloc RAM\_INFO d'allouer une case et enregistrer les informations fournit par la requête. La requête provenant du processeur ne peux pas être accepter si aucune entrée n'est disponible. Le deuxième port est utilisé par la section {\bf SECTION\_VCI\_REQ} pour récuper les informations de la requête pour envoyer un paquet de requête : l'adresse, la commande, la donnée à écrire ainsi qu'un masque concernant les octects de la donnée. L'identifiant du paquet VCI sera le numéro d'entrée de la RAM\_INFO. Un paquet réponse revoye l'identifiant contenu dans le paquet requête. Ceci permet à la section {\bf SECTION\_DCACHE\_RSP} d'accèder au bloc RAM\_INFO pour récuperer les informations afin de constituer la réponse pour le processeur : identifiant de requête, erreur, ... Si la réponse est envoyée avec succès au processeur, le bloc RAM\_INFO va désallouer l'entrée utilisé lors de cette section.
+  \end{description}
+\end{itemize}
+
+\subSection{Chemin des requêtes}
+Dans cette section, nous allons voir le chemin des requêtes en fonction de leur type et de leur succès ou échec dans le cache.
+
+\begin{description}
+\item[Read - cached - Hit  :] Une requête de lecture provenant du processeur va accèder au bloc RAM\_TAG afin de définir si le cache fait un hit sur cette accès. En cas de cache associatif, le bloc RAM\_TAG va également retourner le numéro de banc dans lequel la ligne est stockée. Dans le même temps, la requête va demander une allocation d'une entrée dans le bloc RAM\_INFO, et y stocker les informations de requêtes ainsi que la donnée lut.
+
+L'identifiant retournée par le bloc RAM\_INFO est enregistré dans la file d'attente QUEUE\_READ\_HIT. Cette file est de type First In First Out. Une fois que la requête arrive en tête de file, alors elle sera traité par la section {\bf SECTION\_DCACHE\_RSP}. L'automate FSM\_DCACHE\_RSP donne la priorité à la file QUEUE\_RSP. La requête sera selectionnée une fois que la file QUEUE\_RSP est vide. Ensuite avec le numéro d'identifiant, nous adressons le bloc RAM\_INFO afin de lire les donnée utile pour une réponse : donnée à lire, identifiant de requête ...
+
+La requête de lecture est terminé dès que le processeur renvoie accepte la requête de réponses.
+
+\item[Read - cached - Miss :] Lors de l'accès au bloc RAM\_TAG, ce dernier indique que la ligne contenant l'adresse demandé n'est pas dans le cache. Dans ce cas nous avons un échec de lecture. Les informations concernant la requête est enregistré dans une ligne nouvellement alloué du bloc RAM\_INFO. L'identifiant retournée par ce bloc est enregistré dans la file d'attente QUEUE\_REQ. C'est également un file de type FIFO. 
+
+Une fois que la requête arrive en tête de cette file, l'automate FSM\_VCI\_REQ va lire les informations à partir de RAM\_INFO. Avec ces informations l'automate va provoquer (NB\_WORD * SIZE\_WORD) / SIZE\_WORD\_VCI paquets requêtes. Les adresses des paquêts sont les adresses de la ligne de cache. Suivant la norme VCI seul le dernier paquet aura le champ EOP (End Of Packet) à 1.
+
+Une fois tous les paquets de requêtes envoyés, l'entrée contenue dans la file QUEUE\_REQ est supprimée. 
+
+La section {\bf SECTION\_VCI\_RSP} attend les paquets réponses. A réception de la première réponse, nous allons remplir un buffer qui va contenir la ligne demandée. Suivant la norme VCI, les réponses sont atomiques, c'est à dire que lors de la réception d'une réponse, nous ne pouvons pas recevoir un paquet d'une autre réponse. Une fois le dernier paquet de réponse, nous enregistrons la ligne ainsi que le code d'erreur dans la file d'attente QUEUE\_RSP. 
+
+La section {\bf SECTION\_DCACHE\_RSP} va lire l'entrée de la file QUEUE\_RSP. Comme l'identifiant de requête VCI sert aussi d'adresse pour le bloc RAM\_INFO, nous pouvons récupérer les informations de la requêtes mémoire. Si la requête n'a pas fait d'erreur, le cache sera mise à jour : choix d'un banc victime, écriture de la ligne dans le bloc RAM\_DATA et écriture de l'étiquette dans RAM\_TAG. Le bit de validité de la ligne est placé à 1.
+
+Dans tous les cas, la requête est envoyé sur le port DCACHE\_RSP du processeur. Dès que la réponse est accepté par le processeur, l'entrée contenue dans la file QUEUE\_RSP est supprimée.
+\item[Read - uncached : ] Un accès en lecture non caché est identique à un accès en lecture caché réalisant un échec d'accès au cache. Néanmoins il y a 2 changements :
+\begin{itemize}
+\item Le premier est que SIZE\_WORD / SIZE\_WORD\_VCI paquets requête sera émis sur l'interconnect VCI. Ils ne contiendront que l'adresse désirée. Il y a un nombre équivalent de paquets réponses attendus.
+\item Le cache ne sera pas mise à jour, c'est à dire pas d'écriture dans les blocs RAM\_DATA et RAM\_TAG.
+\end{itemize}
+
+{\it {\bf Remarque :} Nous faisons l'hypothèse qu'une requête non cachable ne peut jamais être dans le cache. C'est à dire que si l'adresse cible ne peut changer de status en cours d'éxecution et que c'est toute la ligne qui la contient qui est cachable ou non. Si cette hypothèse n'est plus vrai, alors lors de l'émission de la requête, il faut que le cache invalide l'entrée la contenant.}
+
+\item[Write - cached - Hit  :] Lors d'une requête d'écriture caché, nous accèdons au bloc RAM\_TAG. Ce dernier indique que la ligne contenant l'adresse demandé est dans le cache : c'est donc un succès. La ligne contenant l'adresse envoyée par le processeur doit être mise à jour. Pour cela, la requête accède au bloc RAM\_DATA et écrit la donnée envoye par le processeur.
+
+De plus les informations concernant la requête est enregistré dans une ligne nouvellement alloué du bloc RAM\_INFO. L'identifiant retournée par ce bloc est enregistré dans la file d'attente QUEUE\_REQ.
+
+Une fois que la requête arrive en tête de cette file, l'automate FSM\_VCI\_REQ va lire les informations à partir de RAM\_INFO. Avec ces informations l'automate va envoyer (SIZE\_WORD) / SIZE\_WORD\_VCI paquets requêtes avec les données à écrire. Suivant la norme VCI seul le dernier paquet aura le champ EOP (End Of Packet) à 1.
+
+Une fois tous les paquets de requêtes envoyés, l'entrée contenue dans la file QUEUE\_REQ est supprimée. 
+
+La section {\bf SECTION\_VCI\_RSP} attend les paquets réponses. Seul les codes d'erreurs sont récupérés car l'écriture ne récupére aucune information.  Une fois le dernier paquet de réponse, nous enregistrons le code d'erreur dans la file d'attente QUEUE\_RSP. 
+
+La section {\bf SECTION\_DCACHE\_RSP} va lire l'entrée de la file QUEUE\_RSP. Comme l'identifiant de requête VCI sert aussi d'adresse pour le bloc RAM\_INFO, nous pouvons récupérer les informations de la requêtes mémoire. Si la requête a un code d'erreur non nul, alors une réponses sera envoyer au processeur. Sinon aucune réponse n'est envoyée au processeur lors d'une écriture. Ensuite l'entrée contenue dans la file QUEUE\_RSP est supprimée.
+\item[Write - cached - Miss :] Un échec d'écriture est équivalent à une réussite d'écriture mais sans mise à jour du cache.
+\item[Write - uncached : ] Un accès en écriture non caché est équivalent à un accès en écriture caché réalisant un défaut de cache.
+\item[Prefetch :] La pré lecture (prefetch) est une technique qui consiste à anticipé l'accès à une adresse en pré-chargeant une ligne de chace. Comme cette ligne ne sera pas forcément utile, il ne faut pas qu'elle modifie le cache. La ligne est en général stocké dans un petit cache. Ce cache de pré lecture est accèdé en parralèle à l'accès au cache, ou après un MISS. Lors d'un hit dans le cache de prélecture, la ligne sera placée dans le cache. La décision de préchargé une ligne peut être aussi bien logiciel que matériel. La présence d'un type {\it PREFETCH} indique que le processeur (et le logiciel tournant sur le processeur) peut envoyer des directives de préchargements. 
+
+Dans l'implémentation de ce cache, nous n'avons pas inclue de mécanisme de pré-lecture. Pour cela, ces accès mémoires sont ignorées. Nous ne fournissons pas de réponses à ces requêtes.
+\item[Lock  :] Le verrouillage de lignes est une technique qui permet d'enlever une ligne de la politique d'évincement du cache. Le programmeur qui a une vision global de l'application peut avoir une variable très utilisé. Dans ce cas, il envoie une directive de verrouillage de ligne et possède la donnée dans le cache. Ce mecanisme peut ressembler au mot clé {\bf register} en C qui une directive pour le compilateur de tenter de placer la variable dans un registre du processeur.
+
+Le verrouillage ce fait jusqu'à une demande d'invalidation ou de flush de la ligne. C'est au cache de ne pas verrouiller l'intégralité d'un ensemble de ligne. C'est à dire que le cache doit au moins avoir pour chaque index, une ligne non verrouiller. Ceci impose que le cache soit au moins semi associatif. Dans un cas de conflit (c'est à dire lors d'une demande de verrouillage de la dernier ligne disponible d'un sensemble), le cache doit choisir une victime parmit les lignes verrouiller. 
+
+Dans l'implémentation de ce cache, nous n'avons pas inclue de mécanisme de verrouillage de ligne. Ces accès mémoires sont ignorés.  Nous ne fournissons pas de réponses à ces requêtes.
+\item[Invalidate :] Un accès mémoire de type {\it invalidation} est une directive qui va de supprimer la ligne correspondante dans le cache. L'invalidation ne va pas annuler les requêtes pendantes sur cette adresse. Mais à la fin de l'execution de cet accès mémoire, il ne doit avoir aucune instruction pendante sur l'ensemble de cette ligne de cache.
+
+D'après les hypothèse donnée en introduction de cette section, comme nous n'avons pas d'accès conflictuel. Si la ligne est dans le cache, la section {\bf SECTION\_DCACHE\_REQ} va placer le bit valide contenu dans le bloc RAM\_TAG. Sinon, cet requête n'aura aucun effet sur le cache.
+
+Le cache ne fournit pas de réponses à ces requêtes.
+
+\item[Flush :] Un accès de type {\it flush} consiste à rendre cohérent les caches locaux ainsi que la mémoire principal. Toute les modifications de la ligne contenant l'adresse fournit par la requête doit être envoyé à la mémoire principale. A la fin de l'execution de cette instruction, toute les écritures sur la ligne de cache ciblée doit être terminée.
+
+Pour notre implémentation de cache, celui-ci est write through. Il y a une cohérence entre le contenu du cache et le contenu de la mémoire. De plus, d'après les hypothèse donnée en introduction de cette section, comme nous n'avons pas d'accès conflictuel. Dans ce cas, cette commande est ignorée.
+
+\item[Synchronization :] Ce type spécial est intégralement géré par l'automate {\it FSM\_DCACHE\_REQ}. Après la réception de cette requête, le cache ne va accepter plus aucune requête provenant du processeur jusqu'a ce qu'il n'y ait plus aucune requête en cours de traitement. La condition de reprise du cache est que le bloc RAM\_INFO soit vide. Une fois la RAM\_INFO vide, alors toutes les lectures (succès ou échec) ont été retournée au processeur. De plus chaque requête d'écriture envoyé sur l'interconnect VCI retourne une réponse. Ce n'est qu'une fois la réponse VCI parvenue au cache que l'entrée dans le bloc RAM\_INFO peut être désalloué. Ceci garantie qu'il n'y a aucune requête (aussi bien de lecture que d'écriture) en cours d'éxecution.
+
+\end{description}
+
Index: trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/document-cache-specification/fr/03_problem.tex
===================================================================
--- trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/document-cache-specification/fr/03_problem.tex	(revision 45)
+++ trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/document-cache-specification/fr/03_problem.tex	(revision 45)
@@ -0,0 +1,180 @@
+\Section{Quelques problèmes du modèle simplifié}\label{problem}
+
+Cette section est une énumérations de problèmes fonctionnels du modèle de base. Pour chacun d'entre eux, nous allons présenter un exemple où le problème peut survenir, ensuite nous allons exposer la nature du problème et enfin nous allons apporter des solutions et débattre de chacune d'entre elles.
+
+Pour cela, nous enlevons toutes les hypothèses vut en introduction de section \ref{overview_partial}.
+
+\subSection{Requêtes multiples d'échec de lectures}\label{multiple_read_miss}
+
+\subsubSection{Contexte}
+
+Le processeur execute un appel de fonction. Le prototype est en 7 étapes :
+\begin{enumerate}
+\item Sauvegarde des registres utilisés dans la pile
+\item Modification du pointeur de pile
+\item Corps de la fonction
+\item Ecriture du résultat dans le registre de retour
+\item Restauration du pointeur de pile
+\item Restauration des registres
+\item Retour vers l'appellant
+\end{enumerate}
+
+Nous nous placons dans un envirronement 32 bits, de plus nous supposons que l'étape 6 est à une adresse de début d'une ligne de cache. Par exemple à l'adresse 0x100 avec un cache de 8 lignes de 4 mots.
+
+Nous allons supposer que la requête de lecture à l'adresse 0x100 fait un échec de lecture, alors les requêtes aux adresse consécutives suivante font également des échecs de lectures (les adresses 0x104, 0x108, 0x10C ...).
+
+\subsubSection{Problème}
+
+Deux problèmes ce présente :
+\begin{enumerate}
+\item Le premier étant la résolution par le cache de plusieurs échecs de lecture. Or la ligne concernée est identique pour toute les requêtes.
+\item Le premier point n'est pas vraiment un problème, car il va juste rendre plus long les accès mémoires. Or si le cache n'est pas direct-map, alors la duplication des requêtes concernant la même ligne de cache va impliquer que la ligne concernée va être logée dans plusieurs endront du cache. Donc une même ligne peut être dans deux emplacements de lignes de cache différents. Dans ce cas, quels lignes modifier en cas d'écriture ?
+\end{enumerate}
+
+Les causes sont les suivants :
+\begin{enumerate}
+\item {\it Le premier  problème est causé par la non sauvegarde par le cache de l'historique des requêtes.}
+\item {\it Le deuxième problème est causé par le non accès à la RAM\_TAG, au moment des réponses. }
+\end{enumerate}
+
+
+\subsubSection{Solutions}
+
+Il y a trois solutions pour remédier à ces problèmes :
+\begin{enumerate}
+\item Ajouter un port de lecture au bloc RAM\_TAG. Dans la section {\bf SECTION\_DCACHE\_RSP}, lors de la lecture du paquet réponse contenu dans la file QUEUE\_RSP, nous allons vérifier si l'accès au cache réalise toujours un MISS. Si c'est le cas alors on met à jour le cache. Sinon aucune mise à jour ne devra être effectué.
+  \begin{description}
+  \item[Avantages :] Coût minimum si on implémente le banc de registre TAG par un banc de registres multi-bancs (mais synchronisation entre les automates FSM\_DCACHE\_REQ et FSM\_DCACHE\_RSP).
+  \item[Inconvénients :] Accès à la mémoire inutile, les coût des miss deviennent plus long car on rappatrie une ligne entière à chaque fois
+  \end{description}
+\item La deuxième solution est d'empêcher ce cas d'arriver. Pour cela il faut avoir un historique des requêtes. Pour chaque ensemble (un ensemble est la totalité des destinations où une lignes de caches peut être stockées. Un ensemble est composé de ASSOC lignes et il y a NB\_LINE / ASSOC ensembles dans un cache) nous ajoutons un bit de verrouillage.
+
+Lors de l'allocation d'une ligne, le bit est positionné à 0. Lors d'un échec de lecture on verrouille la ligne en positionant le bit à 1. Lors de la résolution du miss , donc lors du retour des paquets réponses, ce bit est remis à 0. Nous n'acceptons une requête que si le bit de verrouillage est positionné à 0.
+  \begin{description}
+  \item[Avantages :] Pas de duplication des requêtes.
+  \item[Inconvénients :] Ajout d'éléments mémorisant : 1 bit par ensemble. Solution non scalable avec l'augmentation de l'associativité : le nombre d'élément mémorisant va diminué mais le nombre de ligne vérrouiller va inversement augmenter.
+  \end{description}
+
+\item La troisième solution reprends l'idée de verrouillage mais en l'appliquant non plus au niveau de l'ensemble mais au niveau de la ligne. Le nombre de ligne verrouiller sera toujours de 1. Or dans la solution précedente, nous avons verrouiller un ensemble car nous savons que la ligne récupérer par l'échec de lecture va être placé dans un ensemble. Or le choix de la victime de fait lors de la réception de la réponses.
+
+Ici la solution est de placer le choix de la victime lors de l'émission de la requête, c'est à dire dans la section {\bf SECTION\_DCACHE\_REQ}. 
+  \begin{description}
+  \item[Avantages :] Une seule ligne est vérrouillée.
+  \item[Inconvénients :] Coûte 1 bit par ligne de cache. De plus, entre l'allocation de la requête et l'écriture de la ligne dans le cache, le contenu de la ligne est indisponible. Nous avons potentiellement supprimé une ligne qui aurait put être utilisé durant cette tranche de temps.
+  \end{description}
+\end{enumerate}
+
+{\it Remarque : } Le cycle d'acceptation de la requête (c'est à dire le signal DCACHE.REQ\_ACK) ne dépends plus seulement de l'état des FIFOs (disponible au début du cycle) mais également de la requête elle même. La chaîne critique sera donc un aller / retour entre le processeur et le cache. A cause du besoin de ne pas bloquer les requêtes, pipeliner cette accès devient difficile car quand nous refusons une requête, il ne faut pas quel soit taggué comme lancer par le processeur. Sinon, des problèmes de consistance mémoires peuvent arriver. Pour plus de détails, voir les sections \ref{pipeline} et \ref{consistance}
+
+
+La différence principales entre les deux dernières solutions porte sur le nombre de lignes verrouillées. Ceci influe directement sur le coût en surface et sur la perte de performance. Dans la section \ref{consistance} nous allons voir que les solutions proposer sont basé sur le verrouillage de lignes de caches, donc afin d'uniformisé la solution retenue, nous n'allons pas choisir la première solution.
+
+%\subSection{Évincement précoce de ligne }
+%
+%\subsubSection{Contexte}
+%
+%\subsubSection{Problème}
+%
+%\subsubSection{Solutions}
+%
+%
+%Dans le cas d'un write HIT, lors de la requête, on détermine le numéro de ligne, et le numéro de banc où la donnée doit être écrite. L'écriture effective se fait lors de la réponse. La ligne cible peut pendant ce temps être évincer par une autre réponse (un Read MISS par exemple).
+%Les solutions apportés par ce problème sont presque les mêmes que pour le problème précèdent :
+%\begin{enumerate}
+%\item Ajouter un port d'écriture. Dans ce cas, l'écriture effective se fait lors de la requête. 
+%\item Verrouillage des lignes : ceci va empêcher l'évincement de la ligne concerné par l'écriture.
+%\item Verrouillage des index : ceci va empêcher les évincements des lignes de cache.
+%\end{enumerate}
+
+\subSection{Gestion de la Cohérence mémoire}
+
+La hierarchie mémoire doit assurer la cohérence mémoire (détermine quelle valeur est renvoyée par une lecture). Or les problèmes de cohérence mémoire ne surviennent que dans le cas d'un environnement avec un système multi-processeur et/ou avec des périphériques d'entrée/sortie. Nous n'aborderons pas ici les solutions matérielles pour résoudre ce problème. Le problème pouvant être résolu de manière logicielle en effectuant la séquence suivante présentée dans le graphe \ref{CACHE_coherence_memoire}
+
+\printgraphonly{CACHE_coherence_memoire}{.8}
+ 
+\subSection{Gestion de la Consistance mémoire}\label{consistance}
+
+La hierarchie mémoire doit également assurer la consistance mémoire (détermine quand une valeur écrite sera récupérée par une lecture).
+
+\subsubSection{Contexte}
+
+On suppose que le processeur effectue une requête de lecture à l'adresse 0x100 puis une requête d'écriture à cette même adresse. Nous supposons également que la ligne contenant l'adresse 0x100 n'est pas présente dans le cache. Dans ce cas, le cache peut alors lancer la requête de lecture sur l'interconnect VCI. Sans attendre la réponse de cette requête, le cache peut lancer la requête d'écriture.
+
+\subsubSection{Problème}
+
+La norme VCI n'impose pas à l'interconnect une garantie sur l'ordre d'acheminement des paquets. La norme VCI garantie seulement l'atomicité d'une réponse VCI (pas d'entrelacement de deux réponses VCI vers la même entité). Avec une telle propriété, les transactions de lecture et d'écriture entre en compétition pour l'accès à la zone mémoire. Ainsi ces requêtes peuvent accéder à la zone mémoire dans un ordre différent que dans l'ordre d'émission. 
+
+Ce problème est amplifié par le fait qu'une demande de lecture va lire une ligne de cache entière. Dans ce cas pour un cache de 4 mots de 32 bits par lire, un accès en écriture à l'adresse 0x100 et une lecture à l'adresse 0x104 sont conflictuelle : la lecture se fait sur les adresses 0x100, 0x104, 0x108 et 0x10C. Et contient donc l'adresse de l'écriture. Il y a donc des dépendances si les deux adresses  sont dans la même ligne de cache et que l'un des deux accès est une lecture.
+
+Les problèmes de consistances mémoires peuvent se résumer en énumérant les 4 types de dépendances possibles :
+\begin{description}
+\item[RaR (Read after Read)   :] Il s'agit de deux lectures successives vers la même ligne de cache.\\
+Dans le cadre d'une dépendance RaR, deux lectures concurentes ne posent de problèmes que si elles accèdent à une variable partagé par un autre processeur. Or ceci est résolue par les mécanisme de cohérence mémoire. Un autre problème a été vu à la section \ref{multiple_read_miss}, qui est la gestion de plusieurs échecs de lecture ciblant la même ligne de cache.
+\item[WaR (Write after Read)  :] Il s'agit d'une lecture suivit d'une écriture vers la même ligne de cache.\\
+Du point de vue du processeur et dans le cadre d'exception précise, une écriture n'a le droit de modifier le contexte visible du programmeur que si les instructions avant l'écriture sont terminée. Ceci inclue également les instructions de lecture mémoire. 
+Or les lectures sont bloquantes : tant que la donnée de la lecture n'est pas arrivé, la lecture ne peut se terminé. Donc au moment où la donnée arrive, le processeur peut savoir si la lecture à réaliser une exception. Le processeur gére alors les dépendances WaR.
+\item[WaW (Write after Write) :] Il s'agit de deux écritures successives vers la même adresse.\\
+Dans l'item précédent, nous avons vut que le processeur ne doit pas lancer une écriture si toute les instuctions précédentes ne sont pas terminées. Donc au moment où une écriture est lancée, toute les lectures précedentes ont leurs opérandes et n'ont pas réaliser d'exception (Sinon le processeur appel la routine d'exception). 
+Or les écritures ne sont pas bloquantes. C'est à dire qu'il n'y a pas d'acquittement. Donc au moment où le processeur envoye une requête d'écriture au cache, il peut avoir plusieurs requêtes d'écriture en cours d'éxecution. C'est alors au cache de gérer ces dépendances.
+\item[RaW (Read after Write)  :] Il s'agit d'une écriture suivit d'une lecture vers la même ligne de cache.\\
+Les dépendances RaW sont les moins triviaux. Le processeur ne peut pas gérer ces dépendances pour la même raison que dans l'item précédent : il ne reçoit pas de réponse lorsque l'écriture est effective. De plus, en cas d'échec lors de l'accès au cache, une lecture va chargé une ligne. Donc les dépendance se font au niveau de la ligne, or le processeur ne connaissant pas la taille de la ligne, c'est au cache de gérer ces dépendances.
+\end{description}
+
+\subsubSection{Solutions}
+
+Pour gérer ces différents problèmes, il y a deux solutions :
+\begin{enumerate}
+\item Gestion par le CPU : pour cela le processeur doit connaître la taille maximale d'une ligne de cache (nous définissons par taille maximale, la taille de la ligne de cache contenus dans le dernier niveau de cache avant la mémoire principal ou avant un cache possédant des mécanismes de gestions de consistance mémoires.)
+
+De plus, il faut aussi que toute les requêtes émisent par le processeur soit aquitter. Ceci inclue les requêtes d'écritures. 
+
+Avec ces deux conditions, l'unités de gestion mémoire du processeur peut connaître quand deux instructions mémoires sont en dépendances. Et peut alors agir en conséquence en interdisant leur envoie.
+
+Or le cache que nous définissons va être utilisé avec un processeur qui lance dans le désordre les instructions et lance également dans le désordre les instructions mémoires. Les instructions mémoires sont stoqués dans une file d'attente (généralement appelé la LSQ (Load Store Queue)). Chaque adresse de chaque accès mémoire sera comparé avec les adresses de tous les accès mémoires précédents. Ceci permet de vérifier si un accès mémoire est indépendant d'un autre. Ce mécanisme peut être utilisé pour détecter les dépendances.
+
+Pour une file de taille $N$, il y a $\frac{(N-1)*N}{2}$ comparateurs de 32 ou 64 bits.
+
+En prenant les hypothèses fournit dans la section \ref{hypothese}, nous avons 1 accès mémoire par cycle, 1 instruction d'écriture tous les 3 cycles et un aller retour processeur/mémoire de 30 cycles. Si les instructions d'écriture doivent être aquitter avant de libérer une case, alors chaque instructions d'écriture doivent attendre 30 cycles avant de libérer l'entrée qu'il occupe dans la load store queue. Et pendant se laps de temps, il y a eu 30*4 soit 120 instructions nouvellement chargés dont 120*10\% = 12 nouvelles instructions d'écritures. Le processeur doit également attendre la fin d'une écriture avant d'en éxécuter une nouvelle.
+
+Nous pouvons conclure que quelque soit la taille de la LSQ, le débit entrant d'instruction d'écriture est 12 fois plus important que le débit sortant de ces mêmes instructions.
+
+C'est pour ces raisons que la gestion de la consistance mémoire ne doit par être gérer par le processeur.
+\item Gestion par le Cache : 
+
+Dans la section \ref{multiple_read_miss}, nous avons vu une manière de gérer de multiples requêtes de lectures qui réalisent un accès sur une ligne de caches non présente. Nous pouvons voir ce problème de manière plus général comme étant un problème de dépendance RaR.
+
+Nous allons réutiliser la solution du verrouillage de ligne de cache et l'étendre à toute les requête. Le principe étant simple : lors d'une requête (lecture ou écriture), nous vérrouillons la ligne qui contient (ou va contenir) l'adresse envoyer par le processeur. Ensuite lors de la réception de la réponse, nous déverrouillons la ligne.
+
+Si entre temps il y a une requête qui accède à une ligne verrouillé alors elle n'est pas accepter par le cache.
+
+Tout comme la section \ref{multiple_read_miss}, nous pouvons soit faire du verrouillage de famille soit faire du verrouillage de ligne. Pour les même raisons de scalabilité, nous préférons la solution de verrouiller au niveau ligne. Donc nous devons faire de l'allocation précose de ligne. Pour cela, nous devons avoir dans le cache l'étiquette de la ligne qui va être envoyé sur l'interconnect VCI. Ceci concerne les échec de lecture ainsi que les succès d'écriture. Mais également les échec d'écriture. Ceci signifie que nous allons évincer une ligne de cache afin d'avoir l'étiquette de l'échec d'écriture dans le cache. Or le cache n'est pas write allocate donc lors de la réception du paquet réponses, nous ne rappatrions pas une ligne de cache. C'est pour cela que dans ce cas préçit nous devons invalider la ligne.
+
+
+\begin{tabular}{l|ll}
+Cas         & Action lors d'une requête du processeur & Action lors d'une réponse du bus \\
+\hline
+Read Hit    & Lecture de la donnée                    & Aucune réponse attendue          \\
+            & Pas de requête envoyée au bus           & \\
+Read Miss   & Allocation d'une ligne de cache         & Écriture de la ligne\\
+            & Verrouillage de la ligne de cache       & Déverrouillage de la ligne de cache\\
+Write Hit   & Ecriture de la donnée                   & \\
+            & Verrouillage de la ligne de cache       & Déverrouillage de la ligne de cache\\
+Write Miss  & Allocation d'une ligne de cache         & \\
+            & Verrouillage de la ligne de cache       & Invalidation de la ligne (write no-allocate)\\
+\end{tabular}
+\end{enumerate}
+
+\subSection{Multi-Contexte}
+
+Le cache que nous sommes en train de spécifier doit pouvoir être utiliser avec un processeur multi-contexte (par exemple qui implémente du SMT (Simultaneous Multi Threading). 
+Le cache que nous nous proposons de faire sera physiquement indéxé et physiquement tagué. C'est à dire que la traduction entre l'adresse virtuelle et l'adresse physique ce fait en amont du cache.
+Ceci à pour effet qu'il n'y a aucune difference entre la gestion d'un processeur mono contexte et d'un processeur multi contexte.
+
+Nous pouvons néanmoins montrer quelques effets de bords :
+
+Le cache est optimisé pour utiliser les propriétés de localité spatiale et temporelle d'un programme. Avec l'ajout du multi-contexte, le cache est soumi à plusieurs flot qui sont indépendant entre eux. 
+Ceci va entraîner des évincements de lignes en faveur d'un contexte, alors que la ligne victime pouvait être utilisée par un autre contexte. On appelle cette évènement le ``pourrissement du cache''. Afin de minimiser ces effets, le cache doit avoir un degré d'associativité qui est un multiple du nombre de contextes.
+
+Un autre effet de bord et la nécessité d'avoir un cache non bloquant. Si un contexte est bloqué à cause d'un évènement, les autres contextes ne sont pas forcément bloqués. 
+
+Pour les solutions sur la consistance mémoire : avec l'augmentation conseillé de l'associativité, ainsi que l'augmentation de probabilité de deux requête accédant à la même famille, la solution du verrouillage de ligne va être plutôt choisit par rapport à la solution de verrouiller les familles.
Index: trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/document-cache-specification/fr/04_overview_full.tex
===================================================================
--- trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/document-cache-specification/fr/04_overview_full.tex	(revision 45)
+++ trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/document-cache-specification/fr/04_overview_full.tex	(revision 45)
@@ -0,0 +1,190 @@
+\Section{Vue d'ensemble du cache - Modèle complet}\label{overview_full}
+Cette section à pour but de montrer les modifications par rapport au modèle de base.
+
+\printgraphonly{CACHE_overview}{.8}
+
+\subSection{Solution retenue}
+
+Dans cette section, nous allons montrer la solution retenue. Il s'agit de l'intégration dans la modèle de base vue dans la section \ref{overview_partial} des solutions données au problème vus dans la section \ref{problem}.
+
+Le problème principal est la gestion par le cache de la consistance mémoire. Nous allons implémenté la solution consistant à vérrouiller les lignes de cache. Comme nous verrouillons au niveau des lignes de cache, nous avons besoin que la section {\bf SECTION\_DCACHE\_REQ} réalise le choix de la victime.
+
+La solution abordé dans la section précédente prévoit un bit de verrouillage qui est positionné à un lorsque une requête va être émise sur le bus, et positionné à 0 lors que la réponse reviens du bus. Tous requête qui accède à cette ligne de cache n'est pas accepter. De plus nous pouvons noter lors de la selection d'une victime, le cache n'accepte pas la requête si la victime est vérrouillé.
+
+Le tableau suivant résume pour tous les cas possibles, ce que la théorie autorise, et ce que notre algorithme actuelle autorise.
+
+\begin{tabular}{l|cc}
+Cas                                                                       & théorie & algo actuel \\
+\hline
+2 lectures                     adressant la même adresse                  & oui & non \\ 
+2 lectures                     adressant la même ligne de cache		  & oui & non \\
+2 lectures                     adressant deux lignes de cache différentes & oui & oui \\
+2 écritures                    adressant la même adresse		  & non & non \\
+2 écritures                    adressant la même ligne de cache		  & oui & non \\
+2 écritures                    adressant deux lignes de cache différentes & oui & oui \\
+1 lecture  suivit d'1 écriture adressant la même adresse		  & non & non \\
+1 lecture  suivit d'1 écriture adressant la même ligne de cache		  & oui & non \\
+1 lecture  suivit d'1 écriture adressant deux lignes de cache différentes & oui & oui \\
+1 écriture suivit d'1 lecture  adressant la même adresse		  & non & non \\
+1 écriture suivit d'1 lecture  adressant la même ligne de cache		  & oui & non \\
+1 écriture suivit d'1 lecture  adressant deux lignes de cache différentes & oui & oui \\
+\end{tabular}
+
+La solution actuelle est très restrictive. Ceci est du au fait que quant le cache verrouille une ligne de cache, il ne sait pas si c'est un échec de lecture ou une écriture qui est la cause du verrouillage.
+
+Pour cela, nous modifions l'algorithme en ne proposant pas un bit de verrouillage mais deux bits de verrouillage :
+\begin{description}
+\item[Lock\_by\_read  : ] la ligne de cache à été verrouiller par une lecture. (Un échec de lecture de cette ligne de cache est en cours de traitement).
+\item[Lock\_by\_write : ] la ligne de cache à été verrouiller par une écriture. (Une écriture d'un mot de cette ligne de cache est en cours de traitement).
+\end{description}
+
+En terme d'implémentation, nous avons ajouter un banc de registre RAM\_LOCK contenant ces deux bits de verrouillage. De plus nous avons déplacer le bit de validité contenant dans RAM\_TAG jusque dans ce bloc.% Ce déplacement provoque un petit changement : précédement lors que RAM\_TAG indiqué que l'accès était un succès alors ceci signifie que l'adresse envoyé par le processeur est dans une ligne de cache ET que cette ligne de cache est valide. Maintenant RAM\_TAG ne peut plus vérifier cette deuxième condition.
+
+\subSection{Protocole}
+
+Dans cette section, nous allons voir le protocole de gestion de la consistance mémoire.
+
+\printgraphonly{CACHE_protocole}{.55}
+ 
+Lors de l'arrivé d'une requête, la section {\bf SECTION\_DCACHE\_REQ} connait le type et à partir de l'adresse accède au bloc RAM\_TAG pour obtenir le numéro de banc. Avec ce dernier, le cache accède aux blocs RAM\_DATA et RAM\_LOCK.
+\begin{itemize} 
+\item Si l'accès est une écriture, comme le cache est {\it write through}, cet accès va provoquer l'émission d'une requête sur l'interconnect VCI. 
+  \begin{itemize} % write
+  \item Si l'écriture fait un succès dans le cache (RAM\_TAG contient l'adresse envoyé par le processeur), alors nous testons s'il n'y a pas une requête (aussi bien de lecture que d'écriture) en cours de traitement et que l'entrée dans le cache est valide. 
+    \begin{itemize}  % write hit
+    \item Si c'est le cas, alors nous n'acceptons pas cette requête d'écriture (sinon la requête d'écriture que nous evoyons risque de doubler la requête en cours de traitement). 
+    \item Si aucun des bits de verrouillage n'est positionnée à 1, alors l'accès peut avoir lieu. Pour cela, nous indiquons qu'une requête d'écriture à lieu sur cette ligne de cache ({\it lock\_by\_write = 1}), puis nous chargeons les sections {\bf SECTION\_VCI\_REQ} et {\bf SECTION\_VCI\_RSP} d'effectuer la transaction avec la mémoire principale. La réception de la réponse par la section {\bf SECTION\_DCACHE\_RSP} va provoquer la mise à zéro du bit {\it lock\_by\_write}.
+    \end{itemize}
+  \item Si l'écriture fais un échec dans le cache, alors nous choisissons une victime.
+    \begin{itemize} % write miss
+    \item Si la victime n'est pas valide (les deux bits de verrouillage ne sont pas à 0), alors nous n'acceptons pas la requête d'écriture.
+    \item Si la victime est valide, alors nous verrouillons intégralement la ligne. Par intégrale, nous positionnons les bits {\it lock\_by\_write} et {\it lock\_by\_read} à 1. Le verrouillage intégrale empêche toutes lectures ultérieurs. Tous comme un succès d'écriture, la réception de la réponse va provoquer l'invalidation de la ligne de cache. Car comme le cache n'est pas write allocate, la ligne allouée ne sera pas remplit avec des données cohérentes.
+    \end{itemize}
+  \end{itemize}
+\item Si l'accès est une lecture, nous devons tester la présence dans le cache de l'adresse envoyée par le processeur.
+  \begin{itemize} % read
+  \item Si l'adresse est contenu dans le cache, alors nous devons verifier si la ligne est verrouiller ({\it lock\_by\_read} = 1). Nous n'avons pas besoin de tester si la ligne est verrouiller par une écriture. Si c'est le cas et que l'écriture été une réussite, alors la donnée est à jour dans la ligne de cache, sinon le protocole place le bit {\it lock\_by\_read} à 1.
+    \begin{itemize} % read hit
+    \item Si ligne est verrouillée alors la requête n'est pas accepté.
+    \item Si au contraire, la ligne n'est pas verrouillé, alors la requête est accepté : on lit la donnée dans le bloc RAM\_DATA et on place la requête dans la file d'attente QUEUE\_READ\_HIT. Ensuite, la section {\bf SECTION\_DCACHE\_RSP} va s'occuper d'envoyer la réponse au processeur.
+    \end{itemize}
+  \item Si l'accès en lecture fait un échec, le cache doit choisir une victime.
+    \begin{itemize}
+    \item Si la victime n'est pas valide, alors la requête n'est pas acceptée.
+    \item Si la victime est valide, la section {\bf SECTION\_DCACHE\_REQ} peut effectuer une réquête. Pour cela elle inscrit les informations dans le bloc RAM\_INFO tout en verrouillant la ligne ({\it lock\_by\_read = 1}). Ensuite la donnée est écrite dans la file QUEUE\_REQ, ce qui provoque une emission puis une reception par les sections contrôlant l'interface VCI. A reception du paquet de réponse, la section {\bf SECTION\_DCACHE\_RSP} va écrire la ligne dans le cache et déverrouiller la ligne ({\it lock\_by\_read = 0}).
+    \end{itemize}
+  \end{itemize}
+\end{itemize}
+
+\subSection{Structure interne}
+
+Dans cette section, nous allons voir comment sont structuré les ressources internes du cache non bloquant.
+
+Avant de détailler les interfaces de chaque composant, nous pouvons préciser que chaque interfaces suivent le protocole fifo. C'est a dire que pour chaque interface, il y a des blocs ``producteurs'' et des blocs ``consommateurs''. Les producteurs possède une sortie {\bf VAL} (c'est une entrée pour les consommateurs) qui indique si la requête qu'ils émettent est valide. Les consomateurs possède sortie {\bf ACK} (c'est une entrée pour les producteurs) qui indique si le consommateur peut accepter une requête. Il y a un transaction si $VAL and ACK = 1$ à la fin d'un cycle d'horloge. 
+L'avantage de ce protocole de la gestion intégré du contôle de flux : si un producteur n'a plus de donnée ou un consomateur ne peux plus accepter de transaction, il suffit de positionner respectivement les signaux {\bf VAL} et {\bf ACK} à 0 pour ne pas autoriser de transaction.
+
+
+Nous allons maintenant détailler les ressources internes du cache non bloquant : 
+\begin{itemize}
+\item Trois files d'attentes : 
+  \begin{description}
+  \item[QUEUE\_READ\_HIT :] (figure \ref{CACHE_bloc_QUEUE_READ_HIT}) Cette file d'attente s'occupe de transmettre le plus tôt possible les requêtes de lecture ayant fait un HIT. 
+    \begin{description}
+    %\item {\it Valid : } Indique si l'entrée correspondante contient une donnée valide 
+    \item {\it Index : } Index vers une entrée de RAM\_INFO
+    \end{description}
+    \printgraphonly{CACHE_bloc_QUEUE_READ_HIT}{.8}
+  \item[QUEUE\_REQ :] (figure \ref{CACHE_bloc_QUEUE_REQ}) Cette file est utilisée comme tampon d'écriture et de requête de lecture ayant fait un miss. Elle attende leur envoie à la mémoire.
+    \begin{description}
+    %\item {\it Valid : } Indique si l'entrée correspondante contient une donnée valide 
+    \item {\it Index : } Index vers une entrée de RAM\_INFO
+    \end{description}
+    \printgraphonly{CACHE_bloc_QUEUE_REQ}{.8}
+  \item[QUEUE\_RSP :] (figure \ref{CACHE_bloc_QUEUE_RSP}) La file est utilisée comme tampon pour les réponses provenant de la mémoire.
+    \begin{description}
+    %\item {\it Valid :} Indique si l'entrée correspondante contient une donnée valide 
+    \item {\it Index :} Index vers une entrée de RAM\_INFO 
+    \item {\it Line :} Contient une ligne de cache retournée par l'interface de réponse et devant être écrit dans le bloc RAM\_DATA.
+    \item {\it Error :} Indique si l'accès effectué à générée une erreur ou pas. L'erreur sera interprété par l'exception générique ``Erreur de Bus''.
+    \end{description}
+    \printgraphonly{CACHE_bloc_QUEUE_RSP}{.8}
+  \end{description}
+\item Trois blocs mémoires : 
+  \begin{description}
+  \item[RAM\_TAG :] (figure \ref{CACHE_bloc_RAM_TAG}) Contient les informations pouvant identifier les adresses contenus dans cette ligne de cache
+    \begin{description}
+    \item {\it Tag :} Il s'agit de l'étiquette de l'adresse. A partir du numéro de ligne et de l'étiquette, cette RAM peut déterminer si le cache fait un succès ou non.
+    \end{description}
+    \printgraphonly{CACHE_bloc_RAM_TAG}{.8}
+  \item[RAM\_DATA :] (figure \ref{CACHE_bloc_RAM_DATA}) Contient les données de la ligne de cache 
+    \begin{description}
+    \item {\it Line :} Contient la ligne de cache proprement dite 
+    \end{description}
+    \printgraphonly{CACHE_bloc_RAM_DATA}{.8}
+  \item[RAM\_LOCK :] (figure \ref{CACHE_bloc_RAM_LOCK}) Contient les bits de gestions de dépendances
+    \begin{description}
+    \item {\it Valid :} Indique si la ligne correspondant contient une donnée valide. 
+    \item {\it Lock\_by\_read :} Si le bit est positionné, alors il existe une requête de lecture actuellement en cours de traitement par le cache.
+    \item {\it Lock\_by\_write :} Si le bit est positionné, alors il existe une requête d'écriture actuellement en cours de traitement par le cache.
+    \end{description}
+    \printgraphonly{CACHE_bloc_RAM_LOCK}{.8}
+  \item[RAM\_INFO :] (figure \ref{CACHE_bloc_RAM_INFO}) Contient les informations relative au requête pendante. Pour plus de détails voir la section \ref{RAM_INFO}
+    \begin{description}
+    \item {\it Valid :} Indique si l'entrée correspondante contient une donnée valide 
+    \item {\it Trdid, Pktid :} Identifiant de la requête. Le trdid indique le numéro de contexte du processeur qui à émit la requête. Alors que le pktid est le numéro de paquet de ce contexte. Le processeur garantie l'unicité du couple {trdid, pktid}.
+    \item {\it Address :} Adresse de la requête. Pour une identification rapide de la ligne concernée.
+    \item {\it Type :} Type de la requête (lecture, écriture, taille de l'accès, ...)
+    \item {\it Uncached :} Indique si la réponse doit modifier le cache. Dans le cadre d'une lecture par exemple.
+    \item {\it Data :} Donnée (en cas d'écriture : DCACHE.REQ\_WDATA, en cas de lecture avec succès : contenu d'un mot de la ligne de cache) 
+    \end{description}
+    \printgraphonly{CACHE_bloc_RAM_INFO}{.8}
+  \end{description}
+\item  Quatre automates : 
+  \begin{description}
+  \item[FSM\_DCACHE\_REQ :] (figure \ref{CACHE_automate-fsm_dcache_req}) %Cet automate gère la consommation des requêtes provenant du cache et, suivant le type d'accès et la réussite de l'accès, l'écriture dans les QUEUE\_REQ et QUEUE\_READ\_HIT 
+    \printgraphonly{CACHE_automate-fsm_dcache_req}{1}
+
+  \item[FSM\_DCACHE\_RSP :] (figure \ref{CACHE_automate-fsm_dcache_rsp}) %L'automate gère la consommation de donnée de la QUEUE\_RSP et s'occupe d'écrire dans le cache les lignes chargées.
+    \printgraphonly{CACHE_automate-fsm_dcache_rsp}{.8}
+  \item[FSM\_VCI\_REQ :] (figure \ref{CACHE_automate-fsm_vci_req}) %L'automate s'occupe de consommer une donnée de QUEUE\_REQ (si la file n'est pas vide) et la lance sur l'interface VCI\_REQ (si l'interface n'est pas occupée). 
+    \printgraphonly{CACHE_automate-fsm_vci_req}{.8}
+  \item[FSM\_VCI\_RSP :] (figure \ref{CACHE_automate-fsm_vci_rsp}) %L'automate s'occupe de consommer sur l'interface VCI\_RSP (si l'interface n'est pas occupée) et l'écrit dans  la file QUEUE\_RSP (si la file n'est pas pleine).
+    \printgraphonly{CACHE_automate-fsm_vci_rsp}{.8}
+  \end{description}
+\end{itemize}
+
+\subSection{RAM\_INFO en détail}\label{RAM_INFO}
+Le bloc RAM\_INFO contient les informations relative aux requêtes pendantes. Elle est accéder par trois section du cache différente : {\bf SECTION\_DCACHE\_REQ} afin d'allouer une entrée dans ce bloc et d'écrire les informations concernant la requête, {\bf SECTION\_VCI\_REQ} afin de lire les informations utilies pour créer une requête VCI, et {\bf SECTION\_DCACHE\_RSP} afin de lire les informations permettant de répondre au processeur et d'écrire dans le cache et de désallouer l'entrée de RAM\_INFO.
+
+Le numéro de l'entrée dans lequel est écrit les informations est souvent utilisé. Aussi bien dans les différentes files QUEUE\_REQ, QUEUE\_RSP et QUEUE\_READ\_HIT, que pour indexer un paquet VCI. Ceci permet de ne pas dupliquer les informations inutilement et donc d'avoir des FIFOs contenant peut d'information.
+
+Le numéro de l'entrée sert également comme identifiant de requête lors d'une transaction VCI. Parce que le cycle de vie de cette identifiant garantie son unicité sur le réseau VCI.
+
+Nous pouvons remarquer que le nombre d'entrée dans le bloc RAM\_INFO indique le nombre de requête pouvant être géré simultanément par le cache. Lorsque ce bloc est plein, aucun nouvelle requête ne peut être accepté.
+
+Le nombre d'entrée de cette mémoire est délimité par les tailles des files QUEUE\_REQ et QEUEUE\_READ\_HIT. C'est à dire, la taille de RAM\_INFO doit être comprit entre :\\
+$[ max(\{size\_QUEUE\_REQ\}, \{size\_QUEUE\_READ\_HIT\}) ; \{size\_QUEUE\_REQ\} * \{size\_QUEUE\_READ\_HIT\} ]$
+
+\subSection{Choix de la victime}
+
+Dans cette section nous allons expliquer l'algorithme de selection de la victime et les motiviations de ce choix.
+
+Le chemin entre un processeur et son cache est souvent le chemin critique d'en un processeur. Il passe par la combinatoire qui indique que le processeur demande un accès et fait un aller retour avec l'aquittement du cache de la requête.
+
+Nous avons vut que l'aquittement donner par le cache est dépendante du type et donc du contenu du cache. Suivant le protocole définit dans la figure \ref{CACHE_protocole}, l'aquittement d'une requête dépend de la validité de la victime.
+
+Pour des raisons de rapidité, nous avons décider d'implémenter un algorithme pseudo aléatoire. Par exemple un compteur de ASSOC bits ou un LFSR (Linear Feedback Shift Register) de ASSOC+1 bits (car dans un LFSR, la combinaison 0 n'est pas une combinaison valide).
+
+\subSection{Structure du pipeline}
+
+Dans cette sous section nous allons présenter succintement les étage de pipelines. Suivant le type de la requête, le temps de réponses minimal différe. Pour cela, nous posons N le nombre de cycle aller/retour jusqu'à la mémoire et M le temps nécessaire pour avoir une ligne de cache complète après réception du premier paquet. On considére M et N comme des temps moyens et les files interne comme étant vide.
+\begin{description}
+\item[Read - Hit          : ] 2 cycles.
+\item[Read - Miss         : ] 3 + N + M cycles.
+\item[Write               : ] 4 + N cycles.
+\item[Lock et Prefetch    : ] 2 cycles.
+\item[Invalidate et Flush : ] 2 cycles.
+\end{description}
+
+\printgraphonly{CACHE_pipeline}{.8}
+
Index: trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/document-cache-specification/fr/05_optimisation.tex
===================================================================
--- trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/document-cache-specification/fr/05_optimisation.tex	(revision 45)
+++ trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/document-cache-specification/fr/05_optimisation.tex	(revision 45)
@@ -0,0 +1,73 @@
+\Section{Optimisation}\label{optimisation}
+
+Dans cette dernière section nous allons voir des optimisations que nous pouvons apporter à la structure actuelle du cache non bloquant.
+
+%\subSection{Pipeliner l'accès au cache}\label{pipeline}
+%Nous avons vut que DCACHE.REQ\_ACK ne dépend pas que de l'état des FIFOs (donc disponible au début d'un cycle) mais également des requêtes entrantes (qui sont disponible en fin de cycle). Pour couper cette chaîne critique, nous pouvons pipeliner l'accès au port de requêtes ainsi que celui des réponses. 
+%
+%\subsubSection{DCACHE\_RSP}
+%
+%Sur cette interface, les réponses sont maintenues par le cache jusqu'à ce que le processeur accepte la réponse. Pour cela, nous pouvons implémenter une simple barrière de pipeline.
+%
+%\subsubSection{DCACHE\_REQ}
+%
+%Sur cette interface, les requêtes ne sont pas maintenues par le processeur quand le cache n'accepte pas une requête. Cette spécification permet au processeur de choisir une autre requête si elle n'a pas été acceptée. (Nous rappelons qu'une requête n'est pas acceptée si la file de destination est pleine ou si une requête précedente a verrouillée la ligne.)
+%
+%Dans ce cas ajouter une barrière de pipeline va consommer la requête mais le cache va être dans l'imposibilité de l'accepter et va empêcher d'en choisir une autre.
+
+\subSection{RAM mono-port multi-banc}\label{mono-port}
+
+La mémoire la plus dense est de la mémoire mono-port, c'est à dire qu'à chaque cycle, la mémoire mono-port accepte soit une lecture, soit une écriture et non les deux.
+
+Jusqu'ici nous n'avons pas indiquer la façon d'implémenter les bancs mémoires des blocs RAM\_TAG, RAM\_DATA, RAM\_LOCK et RAM\_INFO. Pour les deux premiers blocs, il est important qu'ils soient le plus dense possible car il contiennent toute la logique et les informations du cache.
+
+Comme chaque interface des blocs de RAM est une interface fifo, elle intègre implicitement un contrôle de flux. Ceci rends les interfaces indépendantent de l'implémentation des blocs proprement dit. (Par exemple, le bloc RAM\_DATA peut être implémenté avec de la mémoire dual-port, dans ce cas les sorties d'aquittement sont toujours égals à 1).
+
+\printgraph{CACHE_implementation_monolithic}{0.7}{Implémentation monolitique d'un banc de registres}
+
+De plus, les blocs internes peuvent être implémentés de manières multibancs. Comme le montre la figure \ref{CACHE_implementation_multi-banc}, un banc de registre monolitique (voir figure \ref{CACHE_implementation_monolithic} (contenant tous les registres) peut être décomposé en deux bancs de registre ayant chacun la moitié des registres. Le premier peut avoir les registres d'adresse paire, le second les registres d'adresse impaire.
+
+\printgraph{CACHE_implementation_multi-banc}{0.7}{Implémentation multi-banc d'un banc de registres}
+
+Avec la stratégie multi-banc, nous pouvons également implémenter une stratégie de partage des ports. Comme le montre la figure \ref{CACHE_implementation_multi-banc_x2_mono-port}, un module combinatoire vérifie si les adresses de chaque port n'entre pas en conflit, c'est à dire que chaque port cible deux bancs differents. En cas de conflits, une priorité doit être choisit. Nous faisons le choix de priorité fixe, en avantageant les ports utiliser par la section {\bf SECTION\_DCACHE\_RSP} puis {\bf SECTION\_VCI\_RSP}, puis {\bf SECTION\_VCI\_REQ} et enfin {\bf SECTION\_DCACHE\_REQ}.
+
+Le tableau suivant montre les conflits d'accès au banc par rapport aux bits de poids fort de l'adresse :
+\begin{center}
+\begin{tabular}{cc|cc}
+       &     & \multicolumn{2}{|c}{Port 1} \\
+       & MSB &       0 & 1\\
+\hline
+Port 0 &   0 & conflit & ok\\
+       &   1 & ok      & conflit\\
+\end{tabular}
+\end{center}
+
+\printgraph{CACHE_implementation_multi-banc_x2_mono-port}{0.7}{Implémentation multi-banc mono-port (x2) d'un banc de registres}
+
+Avec 2 ports et 2 bancs d'un port, la probabilité de conflit et de 50\%. Afin de réduire cette probabilité, il suffit d'augmenter le nombre de banc. Dans une configuration à 4 bancs, la probabilité est de 25\%. Ceci peut être vut dans le tableau suivant :
+\begin{center}
+\begin{tabular}{cc|cccc}
+       &     & \multicolumn{4}{|c}{Port 1} \\
+       & MSB &      00 &  01    &  10    &  11    \\
+\hline					 							
+Port 0 &  00 & conflit & ok     & ok     & ok     \\
+       &  01 & ok      & conflit& ok     & ok     \\
+       &  10 & ok      & ok     & conflit& ok     \\
+       &  11 & ok      & ok     & ok     & conflit\\
+\end{tabular}
+\end{center}
+
+\printgraph{CACHE_implementation_multi-banc_x4_mono-port}{0.7}{Implémentation multi-banc (x4) mono-port d'un banc de registres}
+
+La seule condition pour implémenter des mémoires mono-port est de ne pas faire de conflits systhématique. C'est à dire que dans une même section, on ne doit pas utiliser deux ports avec la même adresse.
+
+Les blocs posant problème sont sont RAM\_TAG et RAM\_LOCK. Le premier accède deux fois au cache de TAG mais avec deux adresses différentes : l'adresse de la requête et l'adresse de la victime. Par contre pour le bloc RAM\_LOCK, il accède 3 fois à ce bloc pendant la section {\bf SECTION\_DCACHE\_REQ}, une fois avec l'adress de la requête, et deux fois avec l'adresse de la victime.
+
+Comme le bloc RAM\_LOCK est relativement petit (NB\_LINE x 3 bits), on peut ce permettre d'avoir plusieurs accès sur ces bancs. Sinon, nous pouvons toujours pipeliner l'accès et faire un bypass entre le contenu du banc de la barrière de pipeline et la nouvelle requête du processeur. %Nous pouvons voir cette technique implémenter dans le graphe \ref{CACHE_overview_mono-port}
+
+
+%\printgraphonly{CACHE_overview_mono-port}{.8}
+
+
+%\subSection{Signaux de contrôles}
+%Dans cette section, nous allons voir les fonctions combinatoires permettant de gérer les différents signaux de contrôles 
Index: trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/document-cache-specification/fr/root.tex
===================================================================
--- trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/document-cache-specification/fr/root.tex	(revision 44)
+++ trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/document-cache-specification/fr/root.tex	(revision 45)
@@ -1,393 +1,6 @@
-\Section{Introduction}
-\subSection{Motivations}
-Les processeurs haute performance lancent plusieurs instructions, de manière non ordonnée et spéculativement. Un défaut de cache ne doit pas bloquer le processeur. Le cache doit être non blouqant, c'est à dire qu'il doit pouvoir accepter des requêtes venant du processeur pendant le traitement d'un MISS.
+\input{\dirroot/01_introduction.tex}
+\input{\dirroot/02_overview_partial.tex}
+\input{\dirroot/03_problem.tex}
+\input{\dirroot/04_overview_full.tex}
+\input{\dirroot/05_optimisation.tex}
 
-\subSection{Démarche du document}
-Le document est accès en quatre parties :
-\begin{itemize}
-\item Section \ref{overview_partial} : dans un premier temps, nous allons présenter une architecture qui satisfait des requêtes courantes (lectures / écritures, succès / échec) sur des adresses non conflictuelles. Cette première architecture est utilisable dans la majorité des cas.
-\item Section \ref{problem}          : dans cette section, nous allons analyser des problèmes arrivant lors d'accès à des adresses conflictuelles, et/ou dans un environnement multi contexte. Pour chaque problème, nous proposons des solutions.
-\item Section \ref{overview_full}    : cette section est la synthèse des deux précedentes. Nous allons modifier l'architecture de départ afin d'apporter des solutions aux problèmes énumérés dans la section \ref{problem}.
-\item Section \ref{description}      : cette dernière section énumère les structures internes, ainsi que les automates de la solution retenue dans la section \ref{overview_full}.
-\end{itemize}
-
-\subSection{Paramètres nécessaires}
-\subsubSection{Paramètres interne du cache}
-
-\begin{center}
-  \begin{tabular}{|ll|ccc|}
-    \hline
-    Paramètres                &             &                       Min &                            Max & Pas \\
-    \hline
-    Taille du mot             & SIZE\_WORD  &                   32 bits &                        64 bits &  *2 \\
-    Nombre de lignes par mot  & NB\_WORD    &                     1 mot &                        64 mots &  *2 \\
-    Nombre de lignes          & NB\_LINE    &                   1 ligne &                    1024 lignes &  *2 \\
-    Associativité             & ASSOC       & 1 banc de NB\_LINE lignes & NB\_LINE/16 bancs de 16 lignes &  *2 \\
-    Taille des files internes & SIZE\_QUEUE &                    1 case &                       64 cases &  *2 \\
-    \hline
-  \end{tabular}
-\end{center}
-
-\subsubSection{Paramètres de l'interface cache / processeur}
-
-\begin{center}
-  \begin{tabular}{|ll|ccc|}
-    \hline
-    Paramètres                              &             &     Min &     Max & Pas \\
-    \hline
-    Taille d'une donnée                     & SIZE\_DATA  & 32 bits & 64 bits &  *2 \\
-    Taille de l'adresse                     & SIZE\_ADDR  & 32 bits & 64 bits &  *2 \\
-    Taille de l'identifiant du propriétaire & SIZE\_TRDID &  0 bits &  4 bits &  +1 \\
-    Taille de l'identifiant de transaction  & SIZE\_PKTID &  0 bits &  4 bits &  +1 \\
-    \hline
-  \end{tabular}
-\end{center}
-
-\subSection{Spécification}
-\begin{itemize}
-\item Write through     (Les données sont à la fois écrite dans le bloc du cache et dans le bloc de la mémoire de niveau inférieur).
-\item Write no allocate (Les échecs d'écriture n'affectent pas le cache, le bloc n'est modifié que dans le niveau mémoire inférieur).
-\item Cache associatif  (Le cache est découpé plusieurs banc et une ligne peut être placé dans n'importe quel banc.)
-\item Non bloquant      (Le cache permet d'avoir plusieurs requêtes en cours de résolution)
-\item Le modèle de consistance mémoires du processeur est relachés (Nous permettons aux lectures et aux écritures de se lancer et de se terminer de manière non ordonnées.)
-\end{itemize}
-
-\subSection{Hypothèse de travail}
-
-Nous allons supposer que le cache sera connecté à un processeur superscalaire d'ordre 4. Que le code exécuté contient 20\% de lectures et 10 \% d'écritures. Nous avons donc en moyenne 1 accès mémoire par cycle. 
-Si nous ciblons un cache ayant au minimum 90\% de réussites, nous obtenons alors les ratios suivants :
-\begin{itemize}
-\item 60 \% de lectures qui réussissent.
-\item 30 \% d'écritures qui réussissent.
-\item 6,6\% de lectures qui échouent.
-\item 3,3\% d'écritures qui échouent.
-\end{itemize}
-
-\Section{Vue d'ensemble - Modèle simplifié}\label{overview_partial}
-
-\printgraphonly{CACHE_overview_basic}{.8}
-
-Dans un premier temps, nous allons montrer un modèle qui satisfait les cas de requêtes courantes : read hit, write hit, read miss et write miss, sur des adresses non conflictuelles.
-
-
-Afin de réaliser un cache non bloquant, nous avons séparé l'interface des requêtes, de l'interface des réponses. Pour cela, 4 automates gèrent les interfaces et la gestion des ressources. La micro-architecture du cache ce décompose comme suit :
-\begin{itemize}
-\item Quatre automates : 
-  \begin{description}
-  \item[FSM\_DCACHE\_REQ :] Cet automate gère la consommation des requêtes provenant du cache et, suivant le type d'accès et la réussite de l'accès, l'écriture dans les blocs QUEUE\_REQ et QUEUE\_READ\_HIT 
-  \item[FSM\_DCACHE\_RSP :] L'automate gère la consommation de réponses contenues dans la QUEUE\_RSP et s'occupe d'écrire les lignes chargés dans le cache.
-  \item[FSM\_VCI\_REQ    :] L'automate s'occupe de consommer une requête contenue dans la QUEUE\_REQ (si la file n'est pas vide) et la lance sur l'interface VCI\_REQ (si l'interface n'est pas occupée). 
-  \item[FSM\_VCI\_RSP    :] L'automate s'occupe de consommer des réponses sur l'interface VCI\_RSP (si l'interface n'est pas occupée) et l'écrit dans  la file QUEUE\_RSP (si la file n'est pas pleine). 
-  \end{description}
-\item Trois files d'attentes : 
-  \begin{description}
-  \item[QUEUE\_READ\_HIT :] Cette file d'attente s'occupe de transmettre le plus tôt possible les requêtes de lectures ayant fait un HIT.
-  \item[QUEUE\_REQ       :] Cette file est utilisée comme tampon d'écriture et de requête de lecture ayant fait un miss. Elle attend leur envoi à la mémoire.
-  \item[QUEUE\_RSP       :] La file est utilisée comme tampon pour les réponses provenant de la mémoire.
-  \end{description}
-\item Trois blocs mémoires : 
-  \begin{description}
-  \item[RAM\_TAG  :] Contient les informations pouvant identifier les adresses contenues dans cette ligne de cache. Ce bloc est composé de ASSOC bancs de tailles identiques.
-  \item[RAM\_DATA :] Contient les données de la ligne de cache. Ce bloc est composé de ASSOC bancs de tailles identiques.
-  \item[RAM\_INFO :] Contient les informations relative aux requêtes pendantes.
-  \end{description}
-\end{itemize}
-
-\subSection{Acheminement des requêtes}
-Dans cette section, nous allons voir l'acheminement d'une requête suivant son type.
-
-\begin{description}
-\item[Read - Hit  :] La requête accède en parallèle aux RAM\_TAG et au RAM\_DATA. La donnée lue est écrite dans la RAM\_INFO, alors que le pointeur vers RAM\_INFO est sauvegardé dans le bloc QUEUE\_READ\_HIT. Ensuite la requête attend d'être sélectionnée par l'automate FSM\_DCACHE\_RSP, puis lit les informations à partir de la RAM\_INFO et est acheminée vers le port de réponse.
-\item[Read - Miss :] La requête de lecture réalisant un miss, écrit les informations concernant la requête dans la RAM\_INFO. Le pointeur de RAM\_INFO sera écrit dans la QUEUE\_REQ. L'automate FSM\_VCI\_REQ va envoyer la requête sur le réseau VCI. La réponse reviendra par l'intermédiaire de l'automate FSM\_VCI\_RSP qui enregistre la ligne de cache en cours d'arrivée dans un tampon. Dès la réception de la fin de paquet, le tampon est enregistré dans la QUEUE\_RSP. L'identifiant de requête vci sera un index vers RAM\_INFO, c'est pour cela que lorsque l'automate FSM\_DCACHE\_REQ récupère une réponse dans la QUEUE\_RSP, elle peut retrouver les informations de la requêtes dans RAM\_INFO.
-\item[Write - Hit  :] La gestion d'un write hit est équivalent à celle d'un read-miss : lors de la requête les informations sont stockées dans la RAM\_INFO (ainsi que la donnée à écrire). Lors de la réponse, (à la différence d'un read-miss, il n'y a pas de retour de ligne) la donnée à écrire va l'être dans le bloc RAM\_DATA.
-\item[Write - Miss :] Un échec d'écriture est équivalent à une réussite d'écriture mais sans mise à jour du cache.
-\item[Lock et Prefetch :] Ce cache n'implémentant ces fonctionnalités et étant le dernier niveau de cache avant l'accès à l'interconnect, alors ces requêtes sont traitées comme étant des Read Hit (sans lecture du cache)
-\item[Invalidate :] Ce cache étant le dernier niveau de cache avant l'accès à l'interconnect, il est transmis à l'interface des réponses au travers de la QUEUE\_READ\_HIT. Lors de la lecture de cette file, on va accéder au cache et mettre le bit valid de la ligne à 0
-\item[Flush :] Le cache étant un cache write through, il y a une cohérence entre le contenu du cache et le contenu de la mémoire. L'effet de cette commande est identique à une commande Invalidate. 
-\end{description}
-Une petite remarque concernant le Write-Hit :
-
- Quel automate doit gérer la mise à jour du cache : FSM\_DCACHE\_REQ ou FSM\_DCACHE\_RSP? Le premier à l'avantage de rendre la modification de la ligne visible rapidement pour les autres requêtes. Or il faudra soit rajouter un nouveau port d'écriture aux bancs RAM\_TAG et RAM\_DATA, soit synchroniser les automates afin de partager le port d'écriture. Le deuxième cas à pour avantage de n'avoir qu'un seul port d'écriture.
-
-Nous optons pour la deuxième solution. Ce choix est également motiver pour uniformiser les solutions proposées pour les problèmes de consistances mémoires.
-
-\Section{Quelques problèmes du modèle simplifié}\label{problem}
-Dans cette section, nous allons voir quelques problèmes fonctionnelle du modèle de base et nous allons présenter des solutions.
-
-\subSection{Requêtes multiples d'échec de lectures}
-Supposons le cas où le processeur réalise une suite d'accès en lecture sur des adresses consécutives en mémoire. Par exemple le processeur demande l'adresse 0x100, 0x104, 0x108, 0x10C pour une taille de ligne de 4 mots et un nombre de ligne de 8 lignes. Si la première requête de lecture fait un miss, alors les 3 autres requêtes vont également échouer.
-
-Il y aura dans ce cas deux problèmes. Le premier étant l'émission, par le cache, de 4 demandes de lignes, alors qu'une seule requête est vraiment utile. Ce n'est pas un problème en soit, mais ceci nous amène au deuxième problème : si le cache n'est pas direct-map, dans ce cas les 4 lignes identiques vont être logées à plusieurs endroit dans le cache.
-\begin{itemize}
-\item {\it Le premier problème est causé par la non sauvegarde par le cache de l'historique des requêtes. }
-\item {\it Le deuxième problème est causé par le non accès à la RAM\_TAG, au moment des réponses. }
-\end{itemize}
-
-Il y a trois solutions pour remédier à ces problèmes :
-\begin{enumerate}
-\item Ajouter un port de lecture au TAG. Quand les réponses arrivent, il faut tester si la requête de lecture fait toujours un miss. Si ce n'est plus le cas, alors aucune mise à jour de cache sera effectué. 
-  \begin{description}
-  \item[+ :] coût minimum si on implémente le banc de registre TAG par un banc de registres multi-bancs (mais synchronisation entre les automates FSM\_DCACHE\_REQ et FSM\_DCACHE\_RSP).
-  \item[- :] accès lecture de mémoire inutile, coût des miss plus long 
-  \end{description}
-\item Empêcher ce cas d'arriver en faisant l'allocation de la ligne lors de la requête. Pour cela, nous allons ajouter un bit dans le TAG : "valid\_data", ce bit est mis à 0 lors d'une requête et positionné à 1 lors de la réponse. On accepte une requête si (valid\_data = 1). 
-  \begin{description}
-  \item[+ :] pas de duplication des requêtes inutile.
-  \item[- :] coûte 1 bit par ligne de cache, suppression d'une ligne de cache alors qu'elle pouvait encore être utile. Si la requête n'est pas accepté, le processeur peut croire que le cache est bloqué et dans ce cas, maintient la requête. 
-  \end{description}
-\item Empêcher ce cas d'arriver en verrouillant les index. Pour chaque index, on rajoute un bit de lock. Ce bit est positionné à 0 lors d'une requête qui fait MISS et remit à 1 lors de la réponse. On accepte une requête qui fait miss si lock[index] = 0 
-  \begin{description}
-  \item[+ :] pas de duplication des requêtes, par rapport à la solution précédente, on a pas supprimé une ligne encore utile. 
-  \item[- :] coûte 1 bit par index. Avec l'augmentation de l'associativité, on va diminué le coût mais augmenter le nombre de ligne verrouiller. 
-  \end{description}
-\end{enumerate}
-
-Pour les deux dernières solutions, nous pouvons faire deux remarques :
-\begin{itemize}
-\item Au lieu de refuser les requêtes qui ne satisfont pas les conditions, nous pouvons les accepter et les indiquer comme "uncached". Ceci aura pour effet de ne pas mettre à jour le cache, d'accepter les requêtes et donc d'avoir les réponses rapidement (car lors d'un accès non caché, nous n'avons pas besoin de chercher une ligne entière).
-\item DCACHE.REQ\_ACK ne dépend plus que de l'état des FIFOs (donc disponible au début d'un cycle) mais également des requêtes entrantes (qui sont disponible en fin de cycle). Pour couper cette chaîne critique, nous pouvons pipeliner les accès au port de requêtes. Pour plus d'information, voir la section \ref{pipeline}
-\end{itemize}
-
-La différence principales entre les deux dernières solutions porte sur le nombre de ligne verrouiller. Donc sur le coût du vérrouillage mais engendre des pertes de performances lors d'un cache fortement associatif. De plus, la solution de verrouiller l'index n'oblige pas de faire l'allocation de la ligne de cache lors de la requête. Car la totalité de l'index est verrouillé, alors il ne peut avoir aucune miss.
-
-\subSection{Évincement précoce de ligne }
-
-Dans le cas d'un write HIT, lors de la requête, on détermine le numéro de ligne, et le numéro de banc où la donnée doit être écrite. L'écriture effective se fait lors de la réponse. La ligne cible peut pendant ce temps être évincer par une autre réponse (un Read MISS par exemple).
-Les solutions apportés par ce problème sont presque les mêmes que pour le problème précèdent :
-\begin{enumerate}
-\item Ajouter un port d'écriture. Dans ce cas, l'écriture effective se fait lors de la requête. 
-\item Verrouillage des lignes : ceci va empêcher l'évincement de la ligne concerné par l'écriture.
-\item Verrouillage des index : ceci va empêcher les évincements des lignes de cache.
-\end{enumerate}
-
-\subSection{Gestion de la Cohérence et Consistance mémoire}
-
-Le système mémoire doit assurer la cohérence mémoire (détermine quelle valeur est renvoyé par une lecture) et la consistance mémoire (détermine quand une valeur écrite sera récupérée par une lecture).
-
-Les problèmes de cohérence mémoire ne survienne que dans le cas d'un environnement multiprocesseur ou avec des périphériques d'entrée/sortie. Nous n'aborderons pas ici les solutions matériels pour résoudre ce problème. Le problème pouvant être résolue de manière logicielle en effectuant la séquence suivante présenté dans le graphe \ref{CACHE_coherence_memoire}
-
-\printgraphonly{CACHE_coherence_memoire}{.8}
- 
-Nous allons principalement nous intéresser aux problèmes de consistance mémoire.
-Le problème est le suivant : le cache lance deux requêtes, une lecture et une écriture. Ces requêtes ciblent le même bloc mémoire. L'interconnect qui relie le cache au bloc mémoire ne garantie pas l'ordre des requêtes. (La norme VCI n'impose pas d'interconnect qui délivre les messages dans l'ordre). La lecture et l'écriture entre en compétition pour l'accès à la zone mémoire, et peuvent accéder à la zone mémoire dans un ordre différent que dans l'ordre d'émission
-
-Ce problème est amplifié par le fait qu'une demande de lecture va lire une ligne de cache entière, donc il y a également des dépendances si les deux adresses  sont dans la même ligne de cache et que l'un des deux accès est une lecture.
-
-Il y a 4 types de dépendances :
-\begin{description}
-\item[RaR (Read after Read)   :] Il s'agit de deux lectures successives vers la même ligne de cache.
-\item[WaW (Write after Write) :] Il s'agit de deux écritures successives vers la même adresse.
-\item[WaR (Write after Read)  :] Il s'agit d'une lecture suivit d'une écriture vers la même ligne de cache. 
-\item[RaW (Read after Write)  :] Il s'agit d'une écriture suivit d'une lecture vers la même ligne de cache.
-\end{description}
-
-En reprenant les 4 types de dépendances, nous allons voir comment ces dépendances sont gérées :
-\begin{itemize}
-\item Dans le cadre d'une dépendance RaR, le seul problème provoqué est le lancement de requête multiple de lecture faisant des miss. (voir la section concerné). 
-\item Du point de vue du processeur, dans le cadre d'exception précise, une écriture n'a le droit de modifier le contexte visible du programmeur que si les instructions avant l'écriture sont terminée. Dans ce cas, les dépendances WaR sont gérées par le processeur. 
-\item Les dépendances WaW peuvent être implicitement géré par le processeur si les writes sont bloquants (donc attendent une réponse du cache). Les performances sont alors fortement dégradées car un write aura le même coût qu'un read faisant un MISS dans tous les niveaux de la hiérarchie mémoire. Nous pouvons tout de même noter qu'un write bloquant permet d'avoir une exception précise.
-\item Les dépendances RaW sont moins triviale : le cpu peut vérifier les cas de RaW sur la même adresse et bypasser l'accès au cache. Or comme les lectures lisent une ligne de cache entière, deux adresses peuvent être différentes mais cibler la même ligne de cache. 
-\end{itemize}
-
-Pour gérer ces différents problèmes, il y a deux solutions :
-\begin{enumerate}
-\item Gestion par le CPU : les écritures demandent des acquittement une fois que la mémoire à été mise à jour. Dans ce cas à tous moment le processeur peut savoir si une écriture est en cours d'éxècution. Les lectures peuvent être lancées s'il n'y a pas de dépendances au niveau ligne avec des écritures. De même entre deux lectures et écritures. Malheureusement cette méthode à la mauvaise propriété de saturer l'unité de mémoire avec des écritures lancées mais attendant leur écriture en mémoire. Ce problème de latence peut être diminué si l'acquittement des écritures se fait jusqu'au premier niveau de cache qui intègre des mécanismes de consistance mémoire. 
-\item Gestion par le Cache : les problèmes d'évincement précoce de ligne de cache sont du à des lectures qui évincent une ligne qui aurait du contenir le résultat d'une écriture. C'est donc une dépendance RaW car les deux adresses ont les même index. Donc nous pouvons réutiliser la solution pour les problèmes de consistance mémoire. La solution proposée içi reprend celle proposée pour les deux problèmes analysés aux sections précédentes : 
-\end{enumerate}
-
-\begin{tabular}{l|ll}
-Cas         & Action lors d'une requête du processeur & Action lors d'une réponse du bus \\
-\hline
-Read Hit    & Lecture de la donnée                    & Aucune réponse attendue          \\
-            & Pas de requête envoyée au bus           & \\
-Read Miss   & Allocation d'une ligne de cache         & Écriture de la ligne et déverrouillage \\
-            & Verrouillage                            & \\
-Write Hit   & Verrouillage de la ligne de cache       & Écriture de la ligne et déverrouillage \\
-Write Miss  & Allocation d'une ligne de cache         & Invalidation de la ligne (write no-allocate)\\
-            & Verrouillage                            & \\
-\end{tabular}
-
-Dans la deuxième solution, aucune requête provenant du processeur n'est accepté si elle concerne une ligne de cache verrouillée.
-
-\subSection{Multi-Contexte }
-Ce cache non bloquant doit pouvoir être utilisé dans un environnement multi-contexte (exécution en parallèle de plusieurs threads). L'implication du multi-contexte ne va pas modifier le comportement du cache (Car ce cache est physiquement indéxé et tagué).
-
-Le cache est optimisé pour utiliser les propriétés de localité spatiale et temporelle d'un programme. Avec le multi-contexte, le cache va être soumit à plusieurs flot qui ne sont pas dépendant entre eux. Ceci va entraîner des évincements de lignes en faveur d'un contexte, alors que la ligne victime pouvait être utilisée par un autre contexte. De plus, ceci va augmenter le phénomène décrit dans la section "Évincement précoce de ligne" : des écritures non encore finalisées vont voir leur lignes cibles évincées.
-
-\Section{Vue d'ensemble - Modèle complet}\label{overview_full}
-Cette section à pour but de montrer les modifications par rapport au modèle de base.
-
-\printgraphonly{CACHE_overview}{.8}
-
-\subSection{Solution retenue}
-
-Nous allons maintenant modifier le modèle de base en vue d'intégrer la solution retenue. La solution consiste en l'implémentation des deux principaux mécanismes vut précédemment : l'allocation précoce de victime et le verrouillage de lignes. Ces solutions ont l'avantage de garder les structures déjà présente dual-port, et de régler simplement les problèmes de consistance mémoire.
-
-Pour cela, nous ajoutons un banc de registre, RAM\_LOCK, qui contiendra 3 bits par ligne :
-\begin{itemize}
-\item Valid : qui est le bit valid anciennement contenu dans la RAM\_TAG. 
-\item Lock\_by\_read : indique si une lecture est actuellement pendante. 
-\item Lock\_by\_write : indique si une écriture est actuellement pendante. 
-\end{itemize}
-
-Détaillons les différentes actions :
-
-\printgraphonly{CACHE_protocole}{.6}
- 
-Le choix de la victime est réalisé lors de l'émission de la requête. Un read hit vérifie si une requête de lecture est en cours sur cette même ligne de cache. Si c'est le cas, alors la requête sera non cachée (donc ne mettra pas à jour le cache).
-Dans le cas d'un write hit ou d'un read miss, la ligne de cache correspondant va être verrouillée. Il est à noter que dans le cas d'un write qui fait miss, le cache va allouer une ligne pour ce write. Comme le cache est write no allocate, la ligne va être invalidée lors de la réponse.
-
-Reprenons les différents dépendances entre requêtes mémoires :
-
-\begin{tabular}{l|ll}
-Dépendance & Dépendance de ligne et adresse identique & Dépendance de ligne et adresse différente\\
-\hline
-RaR        & Bypass dans le processeur                & Rend la deuxième lecture non cachée \\
-WaW        & Géré par le processeur (mono contexte)   & Pas de problème \\
-WaR        & Géré par le processeur (mono contexte)   & La lecture verrouille la ligne.\\
-           &                                          & L'écriture devra attendre la fin de la lecture\\
-RaW        & Bypass dans le processeur                & L'écriture verrouille la ligne.\\
-           &                                          &  La lecture devra attendre la fin de l'écriture\\
-\end{tabular}
-
-\Section{Description détaillée}\label{description}
-
-\subSection{Structure interne}
-
-Pour chaque composant interne, les interfaces suivent le protocole fifo (le producteur possède une sortie VAL qui indique s'il a une requête valide et le consommateur possède une sortie ACK qui indique s'il peut accepter une transaction. Il y a une transaction si VAL et ACK sont tous les deux à 1 à la fin d'un cycle). L'avantage est qu'il est très facile de faire du contrôle de flux.
-
-Nous allons maintenant détailler les ressources internes du cache non bloquant : 
-\begin{itemize}
-\item Trois files d'attentes : 
-  \begin{description}
-  \item[QUEUE\_READ\_HIT :] Cette file d'attente s'occupe de transmettre le plus tôt possible les requêtes de lecture ayant fait un HIT. 
-    \begin{description}
-    %\item {\it Valid : } Indique si l'entrée correspondante contient une donnée valide 
-    \item {\it Index : } Index vers une entrée de RAM\_INFO
-    \end{description}
-    \printgraphonly{CACHE_bloc_QUEUE_READ_HIT}{.8}
-  \item[QUEUE\_REQ :] Cette file est utilisée comme tampon d'écriture et de requête de lecture ayant fait un miss. Elle attende leur envoie à la mémoire.
-    \begin{description}
-    %\item {\it Valid : } Indique si l'entrée correspondante contient une donnée valide 
-    \item {\it Index : } Index vers une entrée de RAM\_INFO
-    \end{description}
-    \printgraphonly{CACHE_bloc_QUEUE_REQ}{.8}
-  \item[QUEUE\_RSP :] La file est utilisée comme tampon pour les réponses provenant de la mémoire.
-    \begin{description}
-    %\item {\it Valid :} Indique si l'entrée correspondante contient une donnée valide 
-    \item {\it Index :} Index vers une entrée de RAM\_INFO 
-    \item {\it Line :} Contient la donnée retournée par l'interface de réponse
-    \item {\it Error :} Indique si l'accès effectué à généré une erreur ou pas. 
-    \end{description}
-    \printgraphonly{CACHE_bloc_QUEUE_RSP}{.8}
-  \end{description}
-\item Trois blocs mémoires : 
-  \begin{description}
-  \item[RAM\_TAG :] Contient les informations pouvant identifier les adresses contenus dans cette ligne de cache
-    \begin{description}
-    \item {\it Tag :} Numéro du tag correspondant à la ligne
-    \end{description}
-    \printgraphonly{CACHE_bloc_RAM_TAG}{.8}
-  \item[RAM\_DATA :] Contient les données de la ligne de cache 
-    \begin{description}
-    \item {\it Line :} Contient la ligne de cache proprement dite 
-    \end{description}
-    \printgraphonly{CACHE_bloc_RAM_DATA}{.8}
-  \item[RAM\_LOCK :] Contient les bits de gestions de dépendances
-    \begin{description}
-    \item {\it Valid :} Indique si la ligne correspondant contient une donnée valide 
-    \item {\it Lock\_by\_read :} Si le bit est positionné, alors il existe une lecture pendante
-    \item {\it Lock\_by\_write :} Si le bit est positionné, alors il existe une écriture pendante 
-    \end{description}
-    \printgraphonly{CACHE_bloc_RAM_LOCK}{.8}
-  \item[RAM\_INFO :] Contient les informations relative au requête pendante. Pour plus de détails voir la section \ref{RAM_INFO}
-    \begin{description}
-    \item {\it Valid :} Indique si l'entrée correspondante contient une donnée valide 
-    \item {\it Trdid, Pktid :} Identifiant de la requête
-    \item {\it Address :} Adresse de la requête. Pour une identification rapide de la ligne concernée.
-    \item {\it Type :} Type de la requête
-    \item {\it Uncached :} Indique si la réponse doit modifier le cache
-    \item {\it Data :} Donnée (en cas d'écriture : DCACHE.REQ\_WDATA, en cas de lecture avec succès : contenu d'un mot de la ligne de cache) 
-    \end{description}
-    \printgraphonly{CACHE_bloc_RAM_INFO}{.8}
-  \end{description}
-\item  Quatre automates : 
-  \begin{description}
-  \item[FSM\_DCACHE\_REQ :] Cet automate gère la consommation des requêtes provenant du cache et, suivant le type d'accès et la réussite de l'accès, l'écriture dans les QUEUE\_REQ et QUEUE\_READ\_HIT 
-    \printgraphonly{CACHE_automate-fsm_dcache_req}{1}
-
-  \item[FSM\_DCACHE\_RSP :] L'automate gère la consommation de donnée de la QUEUE\_RSP et s'occupe d'écrire dans le cache les lignes chargées.
-    \printgraphonly{CACHE_automate-fsm_dcache_rsp}{.8}
-  \item[FSM\_VCI\_REQ :] L'automate s'occupe de consommer une donnée de QUEUE\_REQ (si la file n'est pas vide) et la lance sur l'interface VCI\_REQ (si l'interface n'est pas occupée). 
-    \printgraphonly{CACHE_automate-fsm_vci_req}{.8}
-  \item[FSM\_VCI\_RSP :] L'automate s'occupe de consommer sur l'interface VCI\_RSP (si l'interface n'est pas occupée) et l'écrit dans  la file QUEUE\_RSP (si la file n'est pas pleine).
-    \printgraphonly{CACHE_automate-fsm_vci_rsp}{.8}
-  \end{description}
-\end{itemize}
-
-\subSection{RAM\_INFO en détail}\label{RAM_INFO}
-La RAM\_INFO contient les informations relative aux requêtes pendantes. Elle possède trois ports : 2 ports de lecture et 1 port d'écriture.
-Le numéro de registre dans lequel est écrit les informations est enregistré dans les files QUEUE\_REQ, QUEUE\_RSP et QUEUE\_READ\_HIT. Ceci permet de ne pas dupliquer les informations.
-
-Pour cela, lors d'une transaction acceptée sur l'interface DCACHE\_REQ, il faut allouer un registre de la RAM\_INFO. La dés-allocation de ce registre aura lieu pendant une transaction acceptée sur l'interface DCACHE\_RSP.
-Le numéro de registre sert également comme identifiant de requête lors d'une transaction VCI. (Le cycle de vie de cette identifiant garantie son unicité sur le réseau VCI)
-
-Nous pouvons noter alors que nous pouvons accepter une requête sur le l'interface DCACHE\_REQ si la file de destination n'est pas vide ET s'il y a encore une place de libre dans RAM\_INFO.
-
-%@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
-Dans un premier temps, la taille de RAM\_INFO sera le nombre maximal de requêtes pendantes que le processeur peut admettre soit : \{nombre de contexte\} * \{taille de la load store queue\} (dans ce premier cas, RAM\_INFO n'a pas besoin de contenir le pktid et le trdid de la requête). De plus le nombre de port de lecture sera de 2.
-
-Les optimisations possibles sont :
-\begin{itemize}
-\item Diminution du nombre de registres : en pratique, la taille de RAM\_INFO devra être comprit entre max(\{taille de la QUEUE\_REQ\}, \{taille de la QUEUE\_READ\_HIT\}) et \{taille de la QUEUE\_REQ\} * \{taille de la QUEUE\_READ\_HIT\}. 
-\item Un seul port de lecture : implémentation multi-banc de RAM\_INFO. Pour la gestion de conflit, il faut utiliser la même priorité que pour le choix entre la QUEUE\_READ\_HIT et la QUEUE\_RSP.
-\end{itemize}
-
-\printgraphonly{CACHE_implementation_RAM_INFO}{1}
-
-\subSection{Pipeliner l'accès au cache}\label{pipeline}
-Nous avons vut que DCACHE.REQ\_ACK ne dépend pas que de l'état des FIFOs (donc disponible au début d'un cycle) mais également des requêtes entrantes (qui sont disponible en fin de cycle). Pour couper cette chaîne critique, nous pouvons pipeliner l'accès au port de requêtes ainsi que celui des réponses. 
-
-\subsubSection{DCACHE\_RSP}
-
-Sur cette interface, les réponses sont maintenues par le cache jusqu'à ce que le processeur accepte la réponse. Pour cela, nous pouvons implémenter une simple barrière de pipeline.
-
-\subsubSection{DCACHE\_REQ}
-
-Sur cette interface, les requêtes ne sont pas maintenues par le processeur quand le cache n'accepte pas une requête. Cette spécification permet au processeur de choisir une autre requête si elle n'a pas été acceptée. (Nous rappelons qu'une requête n'est pas acceptée si la file de destination est pleine ou si une requête précedente a verrouillée la ligne.)
-
-Dans ce cas ajouter une barrière de pipeline va consommer la requête mais le cache va être dans l'imposibilité de l'accepter et va empêcher d'en choisir une autre.
-
-\subSection{Choix de la victime}
-Pour la sélection des lignes à evincer, nous allons implémenter un algorithme pseudo aléatoire.
-L'avantage de cet algorithme est de ne pas avoir besoin de sauvegarder un historique des accès.
-
-\subSection{RAM mono-port}\label{mono-port}
-
-La mémoire la plus dense est de la mémoire mono-port (soit une lecture, soit une écriture par cycle). 
-
-Comme chaque interface des blocs de RAM ont une interface fifo, elle intègre donc un contrôle de flux. Ceci les rends indépendant du nombre de port intégrer dans chaque bloc mémoire. (Par exemple, un le bloc RAM\_DATA est implémenté avec de la mémoire dual-port, alors les sorties READ\_ACK et WRITE\_ACK seront toujours égals à 1).
-
-Néanmoins, nous devons prendre soin à ce que chaque étage du cache ne commande pas deux interfaces d'un même bloc RAM. Or dans la solution retenue, nous avons les blocs RAM\_TAG et RAM\_LOCK qui ont besoin de deux interfaces durant la partie DCACHE\_REQ. Pour cela nous devons réaliser une barrière de pipeline.
-
-Le premier étages va réaliser les lectures, alors que le second va mettre à jour ces bancs. Il est à noter qu'il va devoir avoir un bypass car comme la RAM\_LOCK ainsi que le bloc RAM\_TAG n'a pas encore été mis à jour, cette requête peut être suivit par une autre requête qui entre en conflit.
-
-Le graphe \ref{CACHE_overview_mono-port} montre les modifications à apporter au cache pour n'avoir qu'un port par étage.
-
-\printgraphonly{CACHE_overview_mono-port}{.8}
-
-\subSection{Structure du pipeline}
-
-Suivant le type d'une requête, le temps de réponse minimal n'est pas le même (On pose N le nombre de cycle aller retour jusqu'a la mémoire et M le temps pour avoir une ligne de cache complète) :
-\begin{itemize}
-\item Read - Hit : 2 cycles.
-\item Read - Miss : 4 + N + M cycles.
-\item Write : 5 + N cycles.
-\item Lock et Prefetch : 2 cycles.
-\item Invalidate et Flush : 2 cycles.
-\end{itemize}
-
-\printgraphonly{CACHE_pipeline}{.8}
-
-%\subSection{Signaux de contrôles}
-%Dans cette section, nous allons voir les fonctions combinatoires permettant de gérer les différents signaux de contrôles 
