source: anr/section-project-task-schedule.tex @ 359

\anrdoc{\begin{itemize}
\item Presenter sous forme graphique un echeancier des differentes taches
et leurs dependances (diagramme de Gantt par exemple).
\item Presenter un tableau synthetique  de l'ensemble des livrables du
projet (numero de tache, date, intitule, responsable).
\item Preciser de facon synthetique les jalons scientifiques et/ou
techniques, les principaux points de rendez-vous, les points bloquants ou
aleas qui risquent de remettre en cause l'aboutissement du projet ainsi que
les reunions de projet prevues.\end{itemize}}

\definecolor{gtcBoxHeavy}{rgb}{0.10,0.10,0.90}
\definecolor{gtcBoxLight}{rgb}{0.9,0.90,0.99}
\definecolor{gtcTaskBG0} {rgb}{0.99,0.90,0.7}
\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=27}
%\def\ganttlabelstyle#1{\begin{small}#1\end{small}}
\def\ganttlabelstyle#1{\begin{small}\hyperlink{#1}{#1}\end{small}}
\def\gantttitlestyle#1{\begin{scriptsize}\textit{#1}\end{scriptsize}}

\begin{figure}\leavevmode\center
\hypersetup{
    %backref=true,
    %pagebackref=true,
    %hyperindex=true,
    colorlinks=true, %colorise les liens
    breaklinks=true, %permet le retour à la ligne dans les lien
    urlcolor= blue,  %couleur des hyperliens
    linkcolor= black  %couleur des liens internes
}
\hspace*{-.6cm}
\input{gantt.tex}
\caption{\label{gantt}Gantt diagram of deliverables}
\end{figure}

%\begin{figure}\leavevmode\center
%\hspace*{-.4cm}%\vspace{-1.5cm}
%\input{gantt1.tex}
%\caption{\label{gantt1}Gantt diagram of deliverables (task-1 to task-6)}
%\end{figure}
%
%\begin{figure}\leavevmode\center
%\hspace*{-.4cm}%\vspace{-1.5cm}
%\input{gantt2.tex}
%\caption{\label{gantt2}Gantt diagram of deliverables (task-7 and task-8)}
%\end{figure}

The figure~\ref{gantt} presents the Gantt diagram of the project.
%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+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
    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.
    The main restrictions are:
    1) Only the neutral architectural template is supported,
    2) HAS is not available (but prototyping with virtual coprocessors is available),
    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 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+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 enhancements 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.
\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 mentioned 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})]
%    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
%   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 efficient on the other
    architectural templates.
    The project will allow an experimental verification of 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 \xilinxcpu 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/\xilinxbus bridges ({\NOVERShpcAvalonBridge}, {\NOVERShpcPlbBridge})]
    These bridges may decrease the efficiency of the \altera \& \xilinx
    architectural templates.
    Developing the communication components (MWMR) for the AVALON and \xilinxbus 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}
%
Finally the list of all the deliverables is presented on figure~\ref{all-delivrables}.
\begin{figure}[t]\leavevmode\center
{
\fontsize{7pt}{9pt}\selectfont
\settowidth\desclen{XILINX RTL optimisation (5)}
\def\Sformat#1{\textsc{#1}}
%\hspace*{-2.5mm}
\begin{minipage}{1.0\linewidth}
\input{table_livrable_01.tex}
\hfill\hspace*{1mm}\hfill
\input{table_livrable_02.tex}
\end{minipage}
}
\caption{\label{all-delivrables}All the deliverables}
\end{figure}