\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 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})] % 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 an 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} \parlf 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}