\anrdoc{%
Presentez le programme scientifique et justifiez la decomposition en taches du
programme de travail en coherence avec les objectifs poursuivis.\\
Utilisez un diagramme pour presenter les liens entre les differentes taches (organigramme technique)\\
Les taches representent les grandes phases du projet. Elles sont en nombre
limite.\\
Le cas echeant (programmes exigeant la pluridisciplinarite), demontrer
l'articulation entre les disciplines scientifiques.\\
N'oubliez pas les activites et actions correspondant à la dissemination et à la valorisation.}


\begin{figure}[h!]\leavevmode\center
\includegraphics[width=.7\linewidth]{architecture-csg}
\caption{\label{archi-csg} Software architecture for digital system generation}
%\end{figure}\begin{figure}\leavevmode\center
%\mbox{}\vspace*{1ex}\\
\includegraphics[width=1.0\linewidth]{architecture-hls}
\caption{\label{archi-hls} Software architecture of HAS (hardware Accelerator Synthesis)}
%\end{figure}\begin{figure}\leavevmode\center
%\mbox{}\vspace*{1ex}\\
\includegraphics[width=.65\linewidth]{architecture-hpc}
\caption{\label{archi-hpc} Performance analysis of a HPC partitioning}
\end{figure}
%
Figures~\ref{archi-csg}, \ref{archi-hls} and \ref{archi-hpc}
summarize the software architecture of the COACH framework we will develop.
In figures, the dotted boxes are the softwares or formats that COACH
has to provide and to support.
\parlf
For the system generation presented in figure~\ref{archi-csg}, the conductor
is the tool \verb!CSG! (COACH System Generator). Its inputs are a process
network describing the target application and the synthesis parameters.
The main parameters are the target hardware architectural template
with its instantiation parameters, the hardware/software mapping of the
tasks, the FPGA device and design constraints.
\verb+CSG+ thus requires an architectural template library, an operating system
library, two system hardware component (CPU, memories, BUS...) libraries
(one for synthesis, one for simulation).
For generating the coprocessor of a task mapped as hardware, \verb+CSG+
controls the \verb!HAS! (Hardware Accelerator Synthesis) tools described below.
From these inputs \verb!CSG! can generate the entire system (both software and
hardware) either as an IP under IP-XACT to integrate the SoC in larger
design or
as a SystemC simulator (cycle accurate and/or TLM) to prototype and explore quickly the
design space or as a bitstream\footnote{COACH generates synthesizable VHDL, and
launch the \xilinx or \altera RTL synthesis tools.} directly downloadable on the
FPGA device\footnote{Additional partial bitstreams are generated in case of
 dynamic partial reconfiguration}.
 \\
 Furthermore the architecture template and hardware component libraries will be described
 under the IP-XACT specification to facilitate the configuration of \verb+CSG+ to other
 architecture or the enhancement of existing template with IP.
\parlf
The software architecture for \verb!HAS! is presented in figure~\ref{archi-hls}.
The input is a single task of the process network. The \verb!HAS! tools do not work
directly on the C++ task description but on an internal format called
\xcoach generated by a plugin into the GNU C compiler (GCC). 
This will allow on the one hand to insure that all the tools will
accept the same C++ description and on the other hand make possible
their chaining. The front-end tools read an \xcoach description and generate
a new \xcoach description that exhibits more parallelism or implement
specific instructions for ASIP. The back-end tools read an \xcoach
description and generate an \xcoachplus description. This is an \xcoach
description annotated with hardware information (scheduling, binding) required by
the VHDL and systemC drivers.
Furthermore, the back-end tools use a macro-cell library (functional and memory
unit).
\parlf
\label{HPC:howto}%
In addition to digital system design, HPC requires a supplementary
partitioning step presented in figure~\ref{archi-hpc}. The designer
splits the initial application (tag 1) into two parts: one still on the PC and the
other running in a FPGA plugged on the PCI/X PC bus. The two parts exchange data
through communication primitives (tag 2) implemented in a library.
To evaluate the relevance of the partitioning, the designer can build a
simulator. Once the partitioning is validated, the design of the FPGA part
is done through \verb!CSG! (figure~\ref{archi-csg}).
\parlf
The project is split into 8 tasks. They are described
in short below and in detail in section \ref{task-description}.
\begin{description}
\item[Task-1: \textit{Project management}]
    This task relates to the monitoring of the COACH project.
\item[Task-2: \textit{\Backbone}] This task tackles the fundamental points of the
	project such as the definition of the COACH inputs and outputs,
    the internal formats (i.e. \xcoach and \xcoachplus) and their associated tools, 
	the architectural templates and the design flow.
\item[Task-3: \textit{System generation}] This task addresses the prototyping and
    the generation of digital system. Apart from \verb!HAS! that belongs to task 3
    and 4, its components are those presented in figure~\ref{archi-csg}
    (e.g.  \verb!CSG!, operating systems).
\item[Task-4: \textit{HAS front-end}] This task mainly focusses on four functionalities:
    optimization of the memory usage, parallelism enhancement through loop
    transformations, coarse grain parallelization and ASIP generation.
\item[Task-5: \textit{HAS back-end}] This task groups two functionalities:
    High-Level Synthesis of data dominated description and HLS of control
    dominated description.
    This task contains also the development of a frequency adapter
    that will allow the coprocessors to meet processor and bus
    frequency constraints.
\item[Task-6: \textit{PC/FPGA communication middleware}]
    This task pools the features dedicated to HPC. These are mainly the
    validation of the partitioning (see figure~\ref{archi-hpc}), the system drivers for
    both PC and FPGA-SoC sides, the hardware communication components and
	the support for dynamic partial reconfiguration.
\item[Task-7: \textit{Industrial demonstrators}]
    This task groups the demonstrators of the COACH project.
    Most of them are industrial applications that will be developed within
    the COACH framework.
    Others consist in integrating the COACH framework into
    industrial proprietary design tools.
\item[Task 8: \textit{Dissemination}]
    This task concerns the diffusion of the project results.
    It mainly consists of the production of 4 COACH releases (\verb!T0+12!, \verb!T0+18!,
    \verb!T0+24! and \verb!T0+36!), the publication of a tutorial and user manuals on a WEB site, the publication
	of research papers in international journals and conferences and the organization of workshops and tutorials in
	international conferences.
\end{description}
%
\begin{figure}\leavevmode\center
%\includegraphics[width=.4\linewidth]{dependence-task}
\includegraphics[width=0.50\linewidth]{dependence-task-h}
\caption{\label{dependence-task}Task dependencies}
\end{figure}
Figure~\ref{dependence-task} presents the tasks dependencies.
"$T_N \longrightarrow T_M$" means that $T_N$ impacts the $T_M$. 
The more bold the arrow, the more important is the impact.
The graph shows:
\begin{itemize}
\item Even though $T4$ and $T5$ functionalities are complementary, 
their developments are independent (thanks to the \xcoach internal format).
\item $T3$ slightly depends on $T4$ and $T5$. Indeed, $T3$ may work
without $T4$ and $T5$ if targeted digital systems do not include hardware
accelerators. 
\item $T3$ strongly impacts $T6$ but $T3$ does not depend at all on
$T6$. Hence demonstrators ($T7$) of embedded system would not be impacted if
$T6$ would fail.  
\item $T2$ drives all the tasks ($T3$, $T4$, $T5$, $T6$) and is at the heart of
the COACH project.
\item The demonstrators developed in $T7$, of course strongly depend on the achievements 
of the previous tasks ($T2$, $T3$, $T4$, $T5$, $T6$).
\item $T8$ and $T1$ depend on and impact all the other tasks.
\end{itemize}
%This organisation offers enough robustness to insure the success of the
%project, the only critical task in this chart being $T2$. \label{xcoach-problem}
%%However, the partners met 12 times (a one-day meeting per month) during the last year.
%%Ten meeting were dedicated to preliminary technical discussions, including a tentative specification
%%of {\tt xcoach}. The other meetings were dedicated to the preparation of the present proposal.
%However, the partners had 10 one-day meetings where a preliminary draft of the
%\xcoach format was defined. This makes this task less critical.
This project has been shaped with this chart in order to minimize the technical
risk: the task $T2$ handles the major technical issues to be solved and as it is
planned at the beginning of the project we will be able to react fast and take
decisions for possible workaround and enable the continuation of the work with
other tasks. Nevertheless, we are confident becausein preparation to this project,
academic partners are already working close together and know well each other's
technologies, and also a lot of face to face meeting are planned at the
beginning of the project in task $T2$ in order to define the \xcoach format which is
the corner stone of the COACH platform.