\begin{figure}\leavevmode\center
\includegraphics[width=.8\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 hardware accellerator synthesis}
%\end{figure}\begin{figure}\leavevmode\center
\mbox{}\vspace*{1ex}\\
\includegraphics[width=.8\linewidth]{architecture-hpc}
\caption{\label{archi-hpc} Software architecture of HPC}
\end{figure}
%FIXME: la figure ne montre que l'aspect simulation. Intégrer la partie génération (PC API, PCIX, FPGA-IP, bridge vers VCI, SoC API) serait un plus, non ?
%
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 HAS tools described below.
From these inputs \verb!CSG! can generate the entire system (both software \&
hardware) either as a SystemC simulator (cycla 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}.
\parlf
The software architecture for HAS is presented in figure~\ref{archi-hls}.
The input is a single task of the process network. The 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 a \xcoach description and generate
a new \xcoach description that exibits 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 uses a macro-cell library (functional and memory
unit).
\parlf
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) in 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 numbered from 1 to 8. There are described
below and detailled 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 defintion of the COACH inputs and outputs,
    the internal formats (e.g. \xcoach), 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 HAS that belongs to task 3
    and 4, its components are those presented 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 adaptator
    that will allow the coprocessors to respect the processor \& the bus
    frequency.
\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 sytem 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 developped within
    the COACH framework.
    Others consist in integrating the COACH framework as a driver of 
    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.70\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 Notwithstanding that $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 works
without $T4$ and $T5$ if we limit ourselves to digital systems without 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 developped in $T7$, of course strongly depends on the achievements 
of the previous tasks ($T2$, $T3$, $T4$, $T5$, $T6$).
\item $T8$ and $T1$ respectively depends on and impacts all the other tasks.
\end{itemize}
This organisation offers enough robustness to insure the success of the
project except for the specification task $T2$. 
The only critical task in this chart is $T2$. \label{xcoach-problem}
However, the partners met
10 times (a one day meeting per month) during the last year to prepare the
specification and the project proposal. This gives us a degree of confidence 
that $T2$ will be completed in time.