Index: /anr/section-4.4.tex
===================================================================
--- /anr/section-4.4.tex	(revision 39)
+++ /anr/section-4.4.tex	(revision 40)
@@ -53,6 +53,6 @@
 \item[\xcoachplus format (\novers{\specXcoachDoc},
       \novers{\specXcoachToSystemC}, \novers{\specXcoachToVhdl})]
-    Its aim is the generation of the coprocessors (hardware \& prototyping model),
-    By centralizing the coprocessor generation, it guarantees their operating
+    Its aim is the generation of the coprocessors (hardware \& prototyping model).
+    By centralizing the coprocessor generation, it guarantees their functioning
     independently of the used HAS tools.
 	Our experience with UGH and GAUT give us confidence in the succes of this
@@ -62,7 +62,7 @@
      The SocLib component library contains most of the SystemC models used for the
      prototyping description of the ALTERA and XILINX architectural templates.
-     Nevertheless, at this time we do'nt know how many are missing and if the existing
+     Nevertheless, at this time we do not know how many are missing and if the existing
      are really useables.
-     If the work of theses tasks is to important, they will be given up.
+     If the work of theses tasks is too important, they will be abandoned.
      In this case the work-arround to prototype the XILINX and ALTERA architectural
      templates is to use the COACH one. These architectures being very similar, the
@@ -71,5 +71,5 @@
 \item[VCI/AVALON \& VCI/PLB bridges (\novers{\hpcAvalonBridge}, \novers{\hpcPlbBridge})]
      If one of these tasks is impossible or too important or leads to inefficiency,
-     will be given up.
+     it will be abandoned.
      In this case, the COACH architectural template will not be available for HPC and
      a SystemC VCI model corresponding to the PCI/X IP will be developped to allow
Index: /anr/task-4.tex
===================================================================
--- /anr/task-4.tex	(revision 39)
+++ /anr/task-4.tex	(revision 40)
@@ -6,21 +6,22 @@
 %
 \begin{objectif}
-This objectives of this task are to provides the 2 HAS back-ends of the COACH project and
-a tool that adapt the coprocessor frequency to the FPGA-SoC frequency. This later is given
+The objectives of this task are to provide the 2 HAS back-ends of the COACH project and
+a tool that adapt the coprocessor frequency to the FPGA-SoC frequency as given 
 by the processors and the BUS.
+%pourquoi en majuscule?
 \\
-The HAS back-ends as shown figure~\ref{archi-hls} reads \xcoach data and provides
-\xcoachplus data that is \xcoach format annotated with hardware information such as
-variable binded on register, operation binded on cell and sheduled. The \xcoach format
+The HAS back-ends as shown in figure~\ref{archi-hls} reads \xcoach data and provides
+\xcoachplus data, i.e. \xcoach data annotated with hardware information such as
+variables bindings to registers, operations bindings to cells and a schedule. The \xcoach format
 being generated by {\specXcoachToC} deliverable and \xcoachplus being treated by
 \novers{\specXcoachToSystemC} and \novers{\specXcoachToVhdl} deliverables,
-this task is very dependent of the task~1.
+this task is very dependen on task~1.
 \par
 For the two HAS front-end, this task is based on the already existing HLS tools GAUT and
-tools. These tools are complementary and not competitor because they cover irespectively
-data and control dominated orthogonal domain.
+UGH. These tools are complementary and not in competition because they cover respectively
+data and control dominated designs.
 The organization of the task is firstly to integrate quickly the existing HLS to the COACH
 framework. Secondly these tools will be improved to allows to treat data dominated application
-with a few control for GAUT and control dominated application with a few data treatment
+with a few control for GAUT and control dominated application with a few data processing
 for UGH. This will enlarge the domain the HLS can cover.
 \end{objectif}
@@ -53,5 +54,5 @@
         automatically data dominated sections included into a control dominated application.
     \item{}{21}{27}{x}{\Stima}{UGH enhancement 2} The UGH software that is able to
-        generate an micro-architecture without the variable binding currently done by the
+        generate a micro-architecture without the variable binding currently done by the
         designer.
     \item{}{18}{24}{x}{\Subs}{GAUT enhancement 1} A GAUT excutable that is able to
@@ -64,8 +65,8 @@
 \item In FPGA-SoC, the frequency is given by the processors and the BUS. The coprocessors
     generated by HLS synthesis must respect this frequency. However, the HLS tools can not
-    guarantee that the micro-architectures they generate, respect accurately this
+    guarantee that the micro-architectures they generate accurately respect this
     frequency. This is especially the case when the target is a FPGA device, because the
     delays are really known only after the RTL synthesis and that estimated delays used
-    by the HLS are very imprecis. The goal of this \ST is to provide a feature to adapt
+    by the HLS are very imprecize. The goal of this \ST is to provide a tool to adapt
     the coprocessors frequency to the FPGA-SoC frequency after the coprocessor RTL
     synthesis.
Index: /anr/task-5.tex
===================================================================
--- /anr/task-5.tex	(revision 39)
+++ /anr/task-5.tex	(revision 40)
@@ -32,21 +32,21 @@
         \global\edef\hpcCommApi{\name}
     \end{livrable}
-\item This \ST aims consists in helping the application partitioning help.
+\item This \ST consists in helping to partition the application.
     It is a library implementing the communication API with features to profile
-    the application partionning.
+    the partitioned application.
     \begin{livrable}
     \item{}{6}{12}{x}{\Supmc}{HPC partionning helper} A library implementing the communication
         API defined in the {\hpcCommApi} delivrable.
     \end{livrable}
-\item This \ST aims with the implementation of the communication API on the both sides (PC
+\item This \ST deals with the implementation of the communication API on the both sides (PC
     part and FPGA-SoC).
     \begin{livrable}
     \item{}{12}{21}{x}{\Supmc}{HPC API for Linux PC} The PC part of the HPC communication API
-        that comminicate with the FPGA-SOC, a library and probably a LINUX module.
+        that comminicates with the FPGA-SOC, a library and probably a LINUX module.
     \item{}{12}{21}{x}{\Supmc}{HPC API for MUTEK OS} The FPGA-SoC part of the communication API, a
         driver.\global\edef\hpcMutekDriver{\name}
     \item{}{21}{24}{x}{\Stima}{HPC API for DNA OS} Port of the {\hpcMutekDriver} driver on the DNA OS.
     \end{livrable}
-\item This \ST aims with the implementation of hardware required by the COACH
+\item This \ST deals with the implementation of hardware required by the COACH
     architectural template for using the PCI/X IP of \altera and \xilinx.
     \begin{livrable}
@@ -56,7 +56,7 @@
     \item{}{9}{18}{h}{\Saltera}{HPC hardware \altera}
         \setMacroInAuxFile{hpcAvalonBridge}
-        The synthesizable VHDL description of a AVALON/VCI bridge and its corresponding SystemC model.
+        The synthesizable VHDL description of an AVALON/VCI bridge and its corresponding SystemC model.
     \end{livrable}
-\item This \ST aims with the dynamic reconfiguration of FPGA.
+\item This \ST deals with the dynamic reconfiguration of an FPGA.
     \begin{livrable}
     \item{}{18}{30}{x}{\Stima}{dynamic reconfiguration \ganttlf DNA drivers}
Index: /anr/task-6.tex
===================================================================
--- /anr/task-6.tex	(revision 39)
+++ /anr/task-6.tex	(revision 40)
@@ -11,9 +11,9 @@
 %
 \begin{workpackage}{D6}
-\item This \ST is the reference demonstrator. It is a HPC application and so it covers
+\item This \ST is the reference demonstrator. It is an HPC application and so it covers
     in addition to HPC (task-5) both the system genration (task-2), the HAS (task-3) and (task-4).
     The reference demonstrator can be a Motion JPEG application,
-    or an application that draws in 3D (under open GL) a metor cloud attracted by a sun an
-    planets,
+    or an application that draws in 3D (under open GL) a simulation of a 
+    metor cloud attracted by a sun and planets,
     or a database management system.
     \begin{livrable}
@@ -21,5 +21,5 @@
     implementation as a PC C/C++ program.
     \item{VF}{6}{12}{x}{\Supmc}{reference demonstrator} The demonstrator
-    splited into 2 parts, a description as communicante task graph of the FPGA-SoC part.
+    split in two parts, a description as a communicating task graph of the FPGA-SoC part.
     \end{livrable}
 \end{workpackage}