Index: trunk/doc/slides/1_contexte_sujet.tex
===================================================================
--- trunk/doc/slides/1_contexte_sujet.tex	(revision 18)
+++ trunk/doc/slides/1_contexte_sujet.tex	(revision 19)
@@ -3,4 +3,6 @@
 %==============================================================================
 
+% reviewed 0.2
+% [Contexte : La simulation c'est bien mais c'est lent]
 \begin{frame} \FT{Contexte}
     \BI
@@ -8,5 +10,5 @@
     développement de compilateurs et d'applications, pour bon nombre de raisons :
        \BI
-       \o Il n'est pas nécessaire d'avoir à sa disposition le micro-processeur
+       \o Il n'est pas nécessaire d'avoir à sa disposition le processeur
        \o Elle permet un diagnostic spécifique à un processeur des performances
        d'un programme
@@ -15,6 +17,42 @@
     très nombreux des processeurs, il en découle des simulations très lentes,
     voire inutilisables pour simuler des architectures multic\oe ur.
+
+    \o Un facteur de ralentissement de 10 à 10000 est constaté entre
+    l'exécution native et la simulation d'un programme. À titre d'exemple, il
+    n'est pas rare que la simulation d'un programme s'exécutant nativement en
+    dix minutes dure jusqu'à trois semaines.
     \EI
 \end{frame} %-------------------------------------------------------------------
+
+% reviewed 0.2
+% [Problématique : Est-ce qu'on peut simplifier la simulation pour aller plus
+%   vite ?]
+\section{Problématique et approche}
+\begin{frame} \FT{Problématique}
+    \BI
+    \o Les simulations complètes sont trop longues pour être exploitables
+    \o Les simulations entraînent souvent des approximations du fait de
+    certaines spécificités non toujours documentées des différents processeurs.
+    \o Les modèles de simulation doivent donc être simplifiés, tout en
+    préservant la pertinence de la simulation : on doit garder une bonne
+    approximation du comportement des applications, notamment dans le cas
+    d'applications utilisant des fonctionnalités  multic\oe urs.
+    \EI
+\end{frame}
+
+% reviewed 0.1++
+% [Approche : simuler seulement le comportement de la mémoire]
+\begin{frame} \FT{Approche}
+    \BI
+    \o % simulation gros grain
+    \o %    hum hum : la mémoire est un facteur déterminant
+    \o % modèle choisi : intégrer uniquement la simulation
+        % des accès mémoire et un temps de traitement des
+        % instructions
+    \o %    et le 1
+    \EI
+\end{frame}
+
+
 \begin{frame} \FT{Description détaillée}
     \BI
@@ -22,5 +60,5 @@
     l'aspect mémoire :
         \BI
-        \o La hierarchie de cache
+        \o La hiérarchie de cache
         \o La communication entre les cache
         \o La gestion de la cohérence entre les caches partagés
@@ -42,10 +80,10 @@
         \BI
         \o SimpleScalar, qui est inutilisable (sans extension) pour simuler
-        des systèmes multi-processeurs ou multic\oe urs.
+        des systèmes multiprocesseurs ou multic\oe urs.
         \o Unisim, qui est beaucoup plus modulaire, mais qui procure un
         framework assez important, dont il aurait fallu extraire la 
         simple modélisation de cache.
         \o Simics, semble offrir des avantages considérables sur les autres,
-        notemment quant à sa vitesse d'exécution, mais c'est un logiciel
+        notamment quant à sa vitesse d'exécution, mais c'est un logiciel
         propriétaire que nous n'avons pas testé
         \EI
Index: trunk/doc/slides/2_definition_analyse_probleme.tex
===================================================================
--- trunk/doc/slides/2_definition_analyse_probleme.tex	(revision 18)
+++ trunk/doc/slides/2_definition_analyse_probleme.tex	(revision 19)
@@ -3,11 +3,11 @@
 %==============================================================================
 
-\begin{frame} \FT{Simulation de caches de processeurs multicoeurs}
+\begin{frame} \FT{Simulation de caches de processeurs multic\oe urs}
     \BI
     \o La simulation doit prendre en compte les aspects suivants :
-        - hierarchie paramétrabe de plusieurs caches, de façon modulaire
+        - hiérarchie paramétrable de plusieurs caches, de façon modulaire
         (cache L1, L2, etc.)
-    \o communications entres les caches hierarchiques
-    \o gestion de caches de processeurs multicoeurs :
+    \o communications entres les caches hiérarchiques
+    \o gestion de caches de processeurs multic\oe urs :
         \BI
         \o caches partagés
Index: trunk/doc/slides/3_principe_solution.tex
===================================================================
--- trunk/doc/slides/3_principe_solution.tex	(revision 18)
+++ trunk/doc/slides/3_principe_solution.tex	(revision 19)
@@ -5,5 +5,5 @@
 \begin{frame} \FT{Principe de la solution}
     \BI
-    \o Modélisation de la hierarchie de cache
+    \o Modélisation de la hiérarchie de cache
     \o Traitement d'une séquence d'accès (read, write) à des adresses
     \o Un modèle très simplifié pour le reste des instructions:
@@ -11,5 +11,5 @@
         \o pas d'analyse de dépendances
         \o pas de prédiction de branchement
-        \o constantes pour les temps d'execution des instructions
+        \o constantes pour les temps d'exécution des instructions
         \EI
     \o le traitement des autres instructions est encore à définir
Index: trunk/doc/slides/4_identification_taches.tex
===================================================================
--- trunk/doc/slides/4_identification_taches.tex	(revision 18)
+++ trunk/doc/slides/4_identification_taches.tex	(revision 19)
@@ -7,5 +7,5 @@
     \o Étude modèle simplifié du processeur, différentes approches possibles
         \BI
-        \o intrumentation d'un exécutable (modèle de valgrind)
+        \o instrumentation d'un exécutable (modèle de Valgrind)
         \o émulation
         \EI
Index: trunk/doc/slides/plan.txt
===================================================================
--- trunk/doc/slides/plan.txt	(revision 19)
+++ trunk/doc/slides/plan.txt	(revision 19)
@@ -0,0 +1,101 @@
+Contexte et Sujet
+=================
+
+Contexte :
+	[La simulation c'est bien mais c'est lent]
+
+Problématique :
+	[Est-ce qu'on peut simplifier la simulation ?]
+
+Approche :
+	[On simule seulement le comportement de la mémoire]
+
+État de l'art :
+	[simplescalar, unisim, Virtutech simics]
+
+
+
+
+Principe de la solution
+=======================
+
+Schéma
+	[zoli dessin]
+	
+Principe
+	[modélisation du cache]
+	
+Objectifs de la Simulation
+	[multicoeur, rapide, séquence d'accÚs, etc.]
+	
+Tâches à accomplir
+	[étude modÚle simplifié, intégration valgrind, émulation]
+
+
+
+
+Procédure de recette
+====================
+Tests de validité et performances
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+================================================================================
+================================================================================
+Contexte et Sujet
+=================
+Contexte :
+	hop hop
+
+Problématique : 
+	Simulation trop longue
+	Simplifier les modÚles de simulation en préservant une bonne estimation du 
+		comportement des applications pour le problÚme considéré
+		(parallélisation et optimisation vis à vis de la mémoire
+
+Approche :
+	Simulation gros grain : 
+	ModÚle = intégrer uniquement la simulation des accÚs mémoire
+		et un temps de traitement [...]
+
+État de l'art :
+	hip hip
+
+
+
+
+
+Principe de la solution
+=======================
+Objectifs :
+	Simulation d'applications multiprocessus.
+	Calcul du temps d'exécution.
+	Mesure de la contention des caches.
+	But : Accélérer le processus Optimisation-Simulation
+
+
+
+
+Procédure de recette
+====================
+Tests semi-automatisés : 
+	- Validité cache
+	- Validité proc
+	- Validité communication
+
+Comparaison avec unisim
+
+
Index: trunk/src/l1cache.cpp
===================================================================
--- trunk/src/l1cache.cpp	(revision 18)
+++ trunk/src/l1cache.cpp	(revision 19)
@@ -1,4 +1,5 @@
 #include "l1cache.h"
 
+// TODO il manque un signal pour faire des requetes au L2
 
 void L1Cache::read()
@@ -19,4 +20,5 @@
     miss_info = false;
     hit_info = false;
+    out_activate = false;
     
    
@@ -40,36 +42,26 @@
         Address element(req, cstore->get_line_width());
 
-        // 
-        //  XXX FIXME A PARTIR d'ICI C'EST N'IMPORTE QUOI
-        //
         //  rappel : processing queue c'est le chargement interne. Si un élement
         //  est déjà chargé dans le cache, il va dans la processing queue,
         //  sinon, il part en requete dans le L2
         //
-        //  ca m'apprendra a faire du copier coller et commiter sans verifier
         //
         // Si la donnée est chargée dans le cache
         if (cstore->is_loaded(element)) {
-            
-            out_activate = true;
+            processing_queue->insert(element, latency);
+            hit_info = true;
 
             // affichage de l'action
-            cout << sc_time_stamp() << " L1Cache : access to loaded data [" << element << "]  -> hit" << endl;
+            cout << sc_time_stamp() << " L1Cache : access to data [" << element << "]  -> hit ... [start loading]" << endl;
 
-            hit_info = true;
-            out_data = in_data;
         } else {
+            // XXX requete a un module exterieur
 
             // affichage de l'action
-            cout << sc_time_stamp() << " L1Cache : access to loaded data [" << element << "]  -> miss" << endl; 
+            cout << sc_time_stamp() << " L1Cache : access to data [" << element << "]  -> miss" << endl; 
 
+            out_data = in_data;
             miss_info = true;
-            processing_queue->insert(element, latency);
-            processing_queue->print();
         }
-
-        //
-        // XXX JUSQU'A ICI, C'est N'IMPORTE QUOI
-        //
     }