Changeset 44 for trunk/IPs/systemC/processor/Morpheo/Documentation
- Timestamp:
- Jul 17, 2007, 4:47:56 PM (17 years ago)
- Location:
- trunk/IPs/systemC/processor/Morpheo/Documentation/Source
- Files:
-
- 9 added
- 3 edited
- 1 moved
Legend:
- Unmodified
- Added
- Removed
-
trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/document-cache-specification/fr/root.tex
r42 r44 1 \Section{Introduction - Motivation} 2 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. 1 \Section{Introduction} 2 \subSection{Motivations} 3 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. 4 5 \subSection{Démarche du document} 6 Le document est accès en quatre parties : 7 \begin{itemize} 8 \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. 9 \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. 10 \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}. 11 \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}. 12 \end{itemize} 3 13 4 14 \subSection{Paramètres nécessaires} 5 15 \subsubSection{Paramètres interne du cache} 6 \begin{itemize} 7 \item Taille du mot 8 \item Nombre de lignes par mot 9 \item Nombre de lignes 10 \item Associativité 11 \item Nombre d'interface 12 \item Taille des files internes 13 \end{itemize} 16 17 \begin{center} 18 \begin{tabular}{|ll|ccc|} 19 \hline 20 Paramètres & & Min & Max & Pas \\ 21 \hline 22 Taille du mot & SIZE\_WORD & 32 bits & 64 bits & *2 \\ 23 Nombre de lignes par mot & NB\_WORD & 1 mot & 64 mots & *2 \\ 24 Nombre de lignes & NB\_LINE & 1 ligne & 1024 lignes & *2 \\ 25 Associativité & ASSOC & 1 banc de NB\_LINE lignes & NB\_LINE/16 bancs de 16 lignes & *2 \\ 26 Taille des files internes & SIZE\_QUEUE & 1 case & 64 cases & *2 \\ 27 \hline 28 \end{tabular} 29 \end{center} 14 30 15 31 \subsubSection{Paramètres de l'interface cache / processeur} 16 \begin{itemize} 17 \item Nombre de bits composant une donnée 18 \item Nombre de bits composant une adresse 19 \item Nombre de bits composant l'identifiant du propriétaire 20 \item Nombre de bits composant l'identifiant de transaction 21 \end{itemize} 32 33 \begin{center} 34 \begin{tabular}{|ll|ccc|} 35 \hline 36 Paramètres & & Min & Max & Pas \\ 37 \hline 38 Taille d'une donnée & SIZE\_DATA & 32 bits & 64 bits & *2 \\ 39 Taille de l'adresse & SIZE\_ADDR & 32 bits & 64 bits & *2 \\ 40 Taille de l'identifiant du propriétaire & SIZE\_TRDID & 0 bits & 4 bits & +1 \\ 41 Taille de l'identifiant de transaction & SIZE\_PKTID & 0 bits & 4 bits & +1 \\ 42 \hline 43 \end{tabular} 44 \end{center} 22 45 23 46 \subSection{Spécification} 24 47 \begin{itemize} 25 \item Write through 26 \item Write no allocate 27 \item Les requêtes envoyé par le processeur ne garantisse pas le stricte ordre séquentielle du programme. 28 \item Associatif : 1, N, Totalement 29 \end{itemize} 30 31 \Section{Vue d'ensemble - Modèle simplifié} 32 33 \printgraphonly{CACHE_overview_save}{.8} 48 \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). 49 \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). 50 \item Cache associatif (Le cache est découpé plusieurs banc et une ligne peut être placé dans n'importe quel banc.) 51 \item Non bloquant (Le cache permet d'avoir plusieurs requêtes en cours de résolution) 52 \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.) 53 \end{itemize} 54 55 \subSection{Hypothèse de travail} 56 57 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. 58 Si nous ciblons un cache ayant au minimum 90\% de réussites, nous obtenons alors les ratios suivants : 59 \begin{itemize} 60 \item 60 \% de lectures qui réussissent. 61 \item 30 \% d'écritures qui réussissent. 62 \item 6,6\% de lectures qui échouent. 63 \item 3,3\% d'écritures qui échouent. 64 \end{itemize} 65 66 \Section{Vue d'ensemble - Modèle simplifié}\label{overview_partial} 67 68 \printgraphonly{CACHE_overview_basic}{.8} 34 69 35 70 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. 36 71 37 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 : 72 73 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 : 38 74 \begin{itemize} 39 75 \item Quatre automates : 40 76 \begin{description} 41 77 \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 42 \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.78 \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. 43 79 \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). 44 80 \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 83 \begin{description} 48 84 \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. 49 \item[QUEUE\_REQ :] Cette file est utilisée comme tampon d'écriture et de requête de lecture ayant fait un miss. Elle attend e leur envoieà la mémoire.85 \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. 50 86 \item[QUEUE\_RSP :] La file est utilisée comme tampon pour les réponses provenant de la mémoire. 51 87 \end{description} 52 88 \item Trois blocs mémoires : 53 89 \begin{description} 54 \item[RAM\_TAG :] Contient les informations pouvant identifier les adresses contenues dans cette ligne de cache. 55 \item[RAM\_DATA :] Contient les données de la ligne de cache. 90 \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. 91 \item[RAM\_DATA :] Contient les données de la ligne de cache. Ce bloc est composé de ASSOC bancs de tailles identiques. 56 92 \item[RAM\_INFO :] Contient les informations relative aux requêtes pendantes. 57 93 \end{description} … … 62 98 63 99 \begin{description} 64 \item[Read - Hit :] La requête accède en par ralè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 seraacheminée vers le port de réponse.100 \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. 65 101 \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. 66 \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.102 \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. 67 103 \item[Write - Miss :] Un échec d'écriture est équivalent à une réussite d'écriture mais sans mise à jour du cache. 68 104 \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 112 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. 77 113 78 \Section{Quelques problèmes du modèle simplifié} 114 \Section{Quelques problèmes du modèle simplifié}\label{problem} 79 115 Dans cette section, nous allons voir quelques problèmes fonctionnelle du modèle de base et nous allons présenter des solutions. 80 116 … … 179 215 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. 180 216 181 \Section{Vue d'ensemble - Modèle complet} 217 \Section{Vue d'ensemble - Modèle complet}\label{overview_full} 182 218 Cette section à pour but de montrer les modifications par rapport au modèle de base. 183 219 … … 215 251 \end{tabular} 216 252 217 \Section{Description détaillée} 253 \Section{Description détaillée}\label{description} 218 254 219 255 \subSection{Structure interne} 256 257 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. 258 220 259 Nous allons maintenant détailler les ressources internes du cache non bloquant : 221 260 \begin{itemize} … … 224 263 \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. 225 264 \begin{description} 226 \item {\it Valid : } Indique si l'entrée correspondante contient une donnée valide265 %\item {\it Valid : } Indique si l'entrée correspondante contient une donnée valide 227 266 \item {\it Index : } Index vers une entrée de RAM\_INFO 228 267 \end{description} 268 \printgraphonly{CACHE_bloc_QUEUE_READ_HIT}{.8} 229 269 \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. 230 270 \begin{description} 231 \item {\it Valid : } Indique si l'entrée correspondante contient une donnée valide271 %\item {\it Valid : } Indique si l'entrée correspondante contient une donnée valide 232 272 \item {\it Index : } Index vers une entrée de RAM\_INFO 233 273 \end{description} 274 \printgraphonly{CACHE_bloc_QUEUE_REQ}{.8} 234 275 \item[QUEUE\_RSP :] La file est utilisée comme tampon pour les réponses provenant de la mémoire. 235 276 \begin{description} 236 \item {\it Valid :} Indique si l'entrée correspondante contient une donnée valide277 %\item {\it Valid :} Indique si l'entrée correspondante contient une donnée valide 237 278 \item {\it Index :} Index vers une entrée de RAM\_INFO 238 279 \item {\it Line :} Contient la donnée retournée par l'interface de réponse 239 280 \item {\it Error :} Indique si l'accès effectué à généré une erreur ou pas. 240 281 \end{description} 282 \printgraphonly{CACHE_bloc_QUEUE_RSP}{.8} 241 283 \end{description} 242 284 \item Trois blocs mémoires : … … 246 288 \item {\it Tag :} Numéro du tag correspondant à la ligne 247 289 \end{description} 290 \printgraphonly{CACHE_bloc_RAM_TAG}{.8} 248 291 \item[RAM\_DATA :] Contient les données de la ligne de cache 249 292 \begin{description} 250 293 \item {\it Line :} Contient la ligne de cache proprement dite 251 294 \end{description} 295 \printgraphonly{CACHE_bloc_RAM_DATA}{.8} 252 296 \item[RAM\_LOCK :] Contient les bits de gestions de dépendances 253 297 \begin{description} … … 256 300 \item {\it Lock\_by\_write :} Si le bit est positionné, alors il existe une écriture pendante 257 301 \end{description} 302 \printgraphonly{CACHE_bloc_RAM_LOCK}{.8} 258 303 \item[RAM\_INFO :] Contient les informations relative au requête pendante. Pour plus de détails voir la section \ref{RAM_INFO} 259 304 \begin{description} … … 265 310 \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) 266 311 \end{description} 312 \printgraphonly{CACHE_bloc_RAM_INFO}{.8} 267 313 \end{description} 268 314 \item Quatre automates : … … 289 335 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. 290 336 337 %@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 291 338 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. 292 339 … … 312 359 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. 313 360 361 \subSection{Choix de la victime} 362 Pour la sélection des lignes à evincer, nous allons implémenter un algorithme pseudo aléatoire. 363 L'avantage de cet algorithme est de ne pas avoir besoin de sauvegarder un historique des accès. 364 365 \subSection{RAM mono-port}\label{mono-port} 366 367 La mémoire la plus dense est de la mémoire mono-port (soit une lecture, soit une écriture par cycle). 368 369 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). 370 371 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. 372 373 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. 374 375 Le graphe \ref{CACHE_overview_mono-port} montre les modifications à apporter au cache pour n'avoir qu'un port par étage. 376 377 \printgraphonly{CACHE_overview_mono-port}{.8} 378 379 \subSection{Structure du pipeline} 380 381 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) : 382 \begin{itemize} 383 \item Read - Hit : 2 cycles. 384 \item Read - Miss : 4 + N + M cycles. 385 \item Write : 5 + N cycles. 386 \item Lock et Prefetch : 2 cycles. 387 \item Invalidate et Flush : 2 cycles. 388 \end{itemize} 389 390 \printgraphonly{CACHE_pipeline}{.8} 391 392 %\subSection{Signaux de contrôles} 393 %Dans cette section, nous allons voir les fonctions combinatoires permettant de gérer les différents signaux de contrôles -
trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Makefile
r42 r44 50 50 PS_FILES = $(patsubst $(DIR_TEX)/%.tex,%.ps ,$(TEX_FILES)) 51 51 PDF_FILES = $(patsubst $(DIR_TEX)/%.tex,%.pdf,$(TEX_FILES)) 52 EPS_FILES = $(patsubst $(DIR_GRAPH)/%.p,$(DIR_SCHEMA_EPS)/%.eps,$(wildcard $(DIR_GRAPH)/*.p)) \53 $(patsubst $(DIR_SCHEMA)/%.fig,$(DIR_SCHEMA_ EPS)/%.eps,$(wildcard $(DIR_SCHEMA)/*.fig)) \54 $(patsubst $(DIR_SCHEMA)/%.eps,$(DIR_SCHEMA_ EPS)/%.eps,$(wildcard $(DIR_SCHEMA)/*.eps))52 PNG_FILES = $(patsubst $(DIR_GRAPH)/%.p,$(DIR_SCHEMA_PNG)/%.png,$(wildcard $(DIR_GRAPH)/*.p)) \ 53 $(patsubst $(DIR_SCHEMA)/%.fig,$(DIR_SCHEMA_PNG)/%.png,$(wildcard $(DIR_SCHEMA)/*.fig)) \ 54 $(patsubst $(DIR_SCHEMA)/%.eps,$(DIR_SCHEMA_PNG)/%.png,$(wildcard $(DIR_SCHEMA)/*.eps)) 55 55 56 56 #-------------------------------------------------------------------------------- … … 58 58 #-------------------------------------------------------------------------------- 59 59 .PHONY : all clean view help doc doc_all new delete 60 .SECONDARY : $(DVI_FILES) $(PS_FILES) $(PDF_FILES) $(EPS_FILES) $(DIR_SCHEMA_EPS) $(DIR_SCHEMA_PNG) 60 .SECONDARY : $(DVI_FILES) $(PS_FILES) $(PDF_FILES) $(PNG_FILES) $(DIR_SCHEMA_EPS) $(DIR_SCHEMA_PNG) 61 .PRECIOUS : %.pdf %.ps %.dvi $(DIR_SCHEMA_PNG)/%.png $(DIR_SCHEMA_EPS)/%.eps 61 62 62 63 all : help 63 64 64 doc : $(DIR_TEX) $( EPS_FILES)65 doc : $(DIR_TEX) $(PNG_FILES) 65 66 @ \ 66 67 for file in $(ALL_FILES); do \ … … 373 374 @$(MKDIR) $@ 374 375 376 $(DIR_SCHEMA_PNG)/%.png : $(DIR_SCHEMA_EPS)/%.eps $(DIR_SCHEMA_PNG) 377 @$(ECHO) "Generate files : $*.png" 378 # @$(EPS2PNG) $< $@ 379 375 380 $(DIR_SCHEMA_EPS)/%.eps : $(DIR_SCHEMA)/%.eps $(DIR_SCHEMA_EPS) $(DIR_SCHEMA_PNG) 376 381 @$(ECHO) "Generate files : $*.eps" 377 382 @$(CP) $(DIR_SCHEMA)/$*.eps $(DIR_SCHEMA_EPS) 378 @$(EPS2PNG) $@ $(DIR_SCHEMA_PNG)/$*.png379 383 380 384 $(DIR_SCHEMA_EPS)/%.eps : $(DIR_SCHEMA)/%.fig $(DIR_SCHEMA_EPS) $(DIR_SCHEMA_PNG) 381 385 @$(ECHO) "Generate files : $*.eps" 382 386 @$(FIG2EPS) $< $@ 383 @$(EPS2PNG) $@ $(DIR_SCHEMA_PNG)/$*.png384 387 385 388 $(DIR_SCHEMA_EPS)/%.eps : $(DIR_GRAPH)/%.p $(DIR_SCHEMA_EPS) $(DIR_SCHEMA_PNG) 386 389 @$(ECHO) "Generate files : $*.eps" 387 390 @$(CD) $(DIR_GRAPH); $(GNUPLOT) $*.p 388 @$(EPS2PNG) $@ $(DIR_SCHEMA_PNG)/$*.png389 391 390 392 #-------------------------------------------------------------------------------- -
trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Package/document-cache-specification.sty
r42 r44 1 \def\review{2007/07/ 02}1 \def\review{2007/07/11} 2 2 %\def\review{\number\day/\number\month/\number\year\xspace} 3 3 4 \title{Cache - Specification}4 \title{Cache de données associatif et non bloquant\\{\it Spécification}} 5 5 6 6 \author{}
Note: See TracChangeset
for help on using the changeset viewer.