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 42)
+++ trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/document-cache-specification/fr/root.tex	(revision 44)
@@ -1,44 +1,80 @@
-\Section{Introduction - Motivation}
-Les processeurs haute performance lancent plusieurs instructions, de manières non ordonnées et spéculativement. Un défaut de cache ne doit pas bloquer le processeur. Le cache doit pouvoir accepter des requêtes pendant le traitement d'un MISS. Il s'agit du concept de cache non bloquant.
+\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.
+
+\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{itemize}
-\item Taille du mot 
-\item Nombre de lignes par mot 
-\item Nombre de lignes 
-\item Associativité 
-\item Nombre d'interface 
-\item Taille des files internes
-\end{itemize}
+
+\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{itemize}
-\item Nombre de bits composant une donnée 
-\item Nombre de bits composant une adresse 
-\item Nombre de bits composant l'identifiant du propriétaire 
-\item Nombre de bits composant l'identifiant de transaction
-\end{itemize}
+
+\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 
-\item Write no allocate 
-\item Les requêtes envoyé par le processeur ne garantisse pas le stricte ordre séquentielle du programme. 
-\item Associatif : 1, N, Totalement
-\end{itemize}
-
-\Section{Vue d'ensemble - Modèle simplifié}
-
-\printgraphonly{CACHE_overview_save}{.8}
+\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 :
+
+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 contenue dans la QUEUE\_RSP et s'occupe d'écrire les lignes chargés dans le cache.
+  \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). 
@@ -47,11 +83,11 @@
   \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 attende leur envoie à la mémoire.
+  \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.
-  \item[RAM\_DATA :] Contient les données de la ligne de cache.
+  \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}
@@ -62,7 +98,7 @@
 
 \begin{description}
-\item[Read - Hit  :] La requête accède en parralèle aux RAM\_TAG et au RAM\_DATA. La donnée lu est écrite dans la RAM\_INFO, alors que le pointeur vers RAM\_INFO est sauvegardé dans la QUEUE\_READ\_HIT. Ensuite la requête attendra d'être sélectionnée par l'automate FSM\_DCACHE\_RSP, puis va lire les informations à partir de la RAM\_INFO et sera acheminée vers le port de réponse.
+\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  :] Un write hit est équivalent à 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 - 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)
@@ -76,5 +112,5 @@
 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é}
+\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.
 
@@ -179,5 +215,5 @@
 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}
+\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.
 
@@ -215,7 +251,10 @@
 \end{tabular}
 
-\Section{Description détaillée}
+\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}
@@ -224,19 +263,22 @@
   \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 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 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 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 : 
@@ -246,8 +288,10 @@
     \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}
@@ -256,4 +300,5 @@
     \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}
@@ -265,4 +310,5 @@
     \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 : 
@@ -289,4 +335,5 @@
 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.
 
@@ -312,2 +359,35 @@
 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 
