Index: anr/section-project-task-schedule.tex
===================================================================
--- anr/section-project-task-schedule.tex	(revision 300)
+++ anr/section-project-task-schedule.tex	(revision 304)
@@ -14,5 +14,5 @@
 \definecolor{gtcTaskBG1} {rgb}{0.90,0.99,0.7}
 \definecolor{gtcMilestone}{rgb}{0.9,0.4,0.4}
-\immediate\write\ganttdata{ML=6 ML=12 ML=18 ML=24}
+\immediate\write\ganttdata{ML=6 ML=12 ML=18 ML=27}
 %\def\ganttlabelstyle#1{\begin{small}#1\end{small}}
 \def\ganttlabelstyle#1{\begin{small}\hyperlink{#1}{#1}\end{small}}
@@ -49,11 +49,14 @@
 %The figures~\ref{gantt1}~\&~\ref{gantt2} present the Gantt diagram of the project.
 Before the final release (T0+36), there are 4 milestones (red lines on the figures) at
-$T0+6$, $T0+12$, $T0+18$ and $T0+24$ that are rendez-vous points of the precedent
+$T0+6$, $T0+12$, $T0+18$ and $T0+27$ that are rendez-vous points of the precedent
 deliverables.
 \begin{description}
-\item[Milestone 1 ($T0+6$)] Specification of COACH inputs, of the \xcoach format and of
+  \item[Milestone 1 ($T0+6$)]
+    Specification of COACH inputs, of the \xcoach format and of
     the demonstatrors as a reference software.
-\item[Milestone 2 ($T0+12$)] The first COACH release. At this step the demonstrators are
-    written in the COACH input format. This COACH release allows to prototype and to generate the FPGA-SoC.
+  \item[Milestone 2 ($T0+12$)]
+    The first COACH release. At this step the demonstrators are
+    written in the COACH input format. This COACH release allows to prototype
+    and to generate the FPGA-SoC.
     The main restrictions are:
     1) Only the neutral architectural template is supported,
@@ -61,31 +64,35 @@
     3) Enhanced communication schemes are not available.
     4) ASIP compilation flow is not available.
-\item[Milestone 3 ($T0+18$)]  The second COACH release. At this step most of the COACH
-    features are availables. A preliminary version of the ASIP synthesis flow is supported, for a 
-   simple extensible MIPS model. The main restriction is that COACH can not yet
-   generate FPGA-SoC for \altera and \xilinx architectural templates.
+  \item[Milestone 3 ($T0+18$)]
+    The second COACH release. At this step most of the COACH features are available.
+    A preliminary version of the ASIP synthesis flow is supported, for a 
+    simple extensible MIPS model. The main restriction is that COACH can not yet
+    generate FPGA-SoC for \altera and \xilinx architectural templates.
     The others restriction is that the HAS tools are not yet fully operational.
-\item[Milestone 4 ($T0+24$)] The pre-release of the COACH project. The full design flow is
-    supported.
-    The main restriction are:
-    1) The backend HAS tools have not been yet enhanced, 
-    2) Dynamic partial reconfiguration is not supported,
-    3) NIOS processor instruction set extension is supported, but only for user specified patterns. 
+\item[Milestone 4 ($T0+27$)]
+    The pre-release of the COACH project. The full design flow is supported.
+    The main restrictions are:
+    1) Automatic frequency calibration of coprocessor is not available.
+    2) Automatic HPC set up is not yet available.
+    3) NIOS processor instruction set extension is supported, but only for user
+    specified patterns.
+    4) GAUT enhencements are not available.
 \item[Final Release ($T0+36$)] 
-	
+
 \end{description}
-This organisation allows the project to globally progress step by step mixing development
-and demonstrator deliverables.
-Hence, demonstrator feed-back will arrive early and so the risk to point out incompatibility
-at the integration phase is significantly reduced.
+This organisation allows the project to globally progress step by step mixing
+development and demonstrator deliverables.
+Hence, demonstrator feed-back will arrive early and so the risk to point out
+incompatibility at the integration phase is significantly reduced.
 \par
 The risks that have been identified at the beginning of the project are the following:
 \begin{description}
-\item[\xcoach format ({\NOVERSspecXcoachDoc}, {\NOVERSspecXcoachToCA})]
-	Partners have to agree on a convenient exchange format for all tools involved.
-	Because all the HAS tools rely on it, the \xcoach format specification is a
-    crucial step. There are no work-around but as mentionned in
-    section~\ref{xcoach-problem} (page~\pageref{xcoach-problem}) the five academic partners have worked on it
-	for a full year and a preliminary document already exists.
+  \item[\xcoach format ({\NOVERSspecXcoachDoc}, {\NOVERSspecXcoachToCA})]
+    Partners have to agree on a convenient exchange format for all tools involved.
+    Because all the HAS tools rely on it, the \xcoach format specification is a
+    crucial step.
+    There are no work-around but as mentionned in section~\ref{xcoach-problem}
+    (page~\pageref{xcoach-problem}) the five academic partners have worked on it
+    for a full year and a preliminary document already exists.
 %\item[\xcoachplus format (\novers{\specXcoachDoc},
 %      \novers{\specXcoachToSystemC}, \novers{\specXcoachToVhdl})]
@@ -93,20 +100,37 @@
 %    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
-%	task.
-\item[Virtual prototyping of \altera \& \xilinx architectural templates ({\NOVERScsgImplementation})]
-     The SoCLib component library contains several SystemC models used for the virtual
-     prototyping of the \altera and \xilinx architectural templates (NIOS and Microblaze processor cores).
-     Nevertheless, at this time we do not know how many IP cores SystemC simulation models have to be developped.
-     If the workload of this simulation model development is too important, virtual prototyping
-	 of those architectural templates will not be directly supported.
-	 The three architectural templates being quite similar, the virtual
-	 prototyping will use the neutral architectural template.
-\item[VCI/AVALON \& VCI/PLB bridges ({\NOVERShpcAvalonBridge}, {\NOVERShpcPlbBridge})]
-     If one of these tasks is impossible or too important or leads to inefficiency,
-     it will be abandoned.
-     In this case, the neutral architectural template will not be available for HPC and
-     a SystemC VCI model corresponding to the PCI/X IP will be developped to allow
-     virtual prototyping.
+%   Our experience with UGH and GAUT give us confidence in the succes of this
+%   task.
+  \item[Virtual prototyping  ({\NOVERScsgImplementation})]
+    In this project, only the virtual prototyping of the neutral architectural
+    template is supported.
+    We think that this restriction is not a serious problem.
+    Indeed the \altera \& \xilinx architectural templates being architecturally close of
+    the neutral architectural template, an efficient software/hardware partition
+    on the neutral architectural template is also an efficient on the other
+    architectural templates.
+    The project will allow to verify experimentally this assumption.
+%  \item[Virtual prototyping of \altera \& \xilinx architectural templates
+%    ({\NOVERScsgImplementation})]
+%    The SoCLib component library contains several SystemC models used for the
+%    virtual prototyping of the \altera and \xilinx architectural templates
+%    (NIOS and Microblaze processor cores).
+%    Nevertheless, at this time we do not know how many IP cores SystemC
+%    simulation models have to be developped.
+%    If the workload of this simulation model development is too important,
+%    virtual prototyping of those architectural templates will not be directly
+%    supported.
+%    The three architectural templates being quite similar, the virtual
+%    prototyping will use the neutral architectural template.
+  \item[VCI/AVALON \& VCI/PLB bridges ({\NOVERShpcAvalonBridge}, {\NOVERShpcPlbBridge})]
+    These bridges may decrease the efficiency of the \altera \& \xilinx
+    architectural templates.
+    Developing the communication components (MWMR) for the AVALON and PLB buses
+    will correct this problem.
+%    If one of these tasks is impossible or too important or leads to inefficiency,
+%    it will be abandoned.
+%    In this case, the neutral architectural template will not be available for HPC and
+%    a SystemC VCI model corresponding to the PCI/X IP will be developped to allow
+%    virtual prototyping.
 \end{description}
 \parlf
