\begin{figure}\leavevmode\center
\includegraphics[width=.8\linewidth]{architecture-csg}
\caption{\label{archi-csg} software architecture for embedded system generation}
%\end{figure}\begin{figure}\leavevmode\center
\mbox{}\vspace*{1ex}\\
\includegraphics[width=.8\linewidth]{architecture-hls}
\caption{\label{archi-hls} software architecture of HLS}
%\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}
%
The figures~\ref{archi-csg}, \ref{archi-hls} and \ref{archi-hpc}
summarize the software architecture of COACH framework we plan to develop.
In figures, the dotted boxes are the softwares or formats that COACH
has to provide or define.
\vspace*{.75ex}\par
For the system genration presented figure~\ref{archi-csg}, the conductor is
the program \verb!CSG! (COACH System Generator). Its inputs are a process
network and miscellaneaous generation parameters.
The main parameters are the template of the target hardware architecture
with its instanciation parameters, the hardware/software mapping of the
tasks and the FPGA device.
From these inputs \verb!CSG! can generate the system (software \& hardware) as
a SystemC simulator to prototype and explore quickly the system design
space and/or as a bitstream directly downloadable on the FPGA device.
For processing, \verb+CSG+ requires 1) a hardware template found into the
architecture library, 2) a micro-kernel, it chooses among
two in the micro kernel library, 3) the system hardware components that
are taken from the SystemC model library for the simulator and from the
VHDL component library for the FPGA bitstream.  
For generating the coprocessor of a task mapped as harware, \verb+CSG+
controls the HLS tools described below.
\\
To proove CSG that COACH is open and CSG is really configurable, COACH will
basically support 3 architecture template (the COACH template based on a
MIPS processors and a VCI token ring, the Altera template based on the NIOS
and AVALON bus, the Xilinx template based on the MICROBLAZE and OPB bus)
and 2 operating systems (DNA/OS and MUTEK). Furthermore, thus is enforced
by the \mustbecompleted{FIXME:zied} contribution that consists in
implementing an other hardware target.
\\
Finally, it is important to notice that this work is a strong
enhancement of the SocLib software.
\vspace*{.75ex}\par
The software architecture for HLS is presented figure~\ref{archi-hls}.
The input is a task of the process network. The HLS tools do not work
directly on the C++ task description but on an internal format called
\xcoach generated by a the GNU C compiler (GCC) tainted by a COACH
driver. This allows on the one hand to insure that all the tools will
accept the same C++ description and on the other hand to make possible
to chain them. The front-end tools read a \xcoach description and writes
a new \xcoach description that exibits possible parallelism or implement
specific instruction for ASIP. The back-end tools read a \xcoach
description and generates a \xcoach+ description that is a \xcoach
description anotated with hardware information to let work the VHDL systemC
drivers. Furthermore, the back-end tools uses a macro-cell library.
\vspace*{.75ex}\par
The software architecture for HPC is presented figure~\ref{archi-hpc}.
\mustbecompleted{FIXME Miss HPC description\\\ldots\\\ldots\\\ldots\\\ldots.}
\vspace*{.75ex}\par
The project is splitted into 8 tasks numbered from 0 to 7.
The first task (task 0) is the project management, the last one (task 7) is
the dissemination the other task are listed below:
\begin{enumerate}
\item\textbf{\backbone:} This task groups the critical issues of the
	project. They consist of the definition of COACH inputs, the \xcoach
	format that is mandatory to develop the HLS tools and the HLS drivers
	that are mandatory for testing the HLS tools. 
\item\textbf{system generation:} This task groups \verb+CSG+s and the components
	required to generate the system simulator and bitstream except the HLS
	tools that belong to the task 3 and 4. These components are the
	operating systems, the VHDL description and SystemC models of the
	target hardware achitectures.
\item\textbf{HLS front-end:} This task groups the 4 HLS front-head. Those
	are a tool that exhibits fine grain parallelism using polyedric
	transformation, a tool that exhibits coarse grain parallelism,
	a tool that minimizes the memory usage and a tool that implement ASIP.
\item\textbf{HLS back-end:} This task groups two HLS back-end tool, one
	for treating the data oriented description, the second for treating the
	control dominated description. This task contains also a the
	development of a frequency adaptator that will allow the coprocessor
	to respect the processor \& bus frequency.
\item\textbf{Communication software PC/FPGA-SoC:} This task groups all what is mandatorythe critical issues of the
\item\textbf{Demonstrator:} This task groups the demostrators of the COACH project.
\end{enumerate}
This task division offers the avantage that tasks except for the "\backbone" and
"demonstrator" task are almost independent at the development level as shown
figure~\ref{dependence-dev}. The dependence at the validation level is
presented figure~\ref{dependence-test}. It is more critical but the
redundance in the tasks "HLS front-end", "HLS back-end" and "demonstrators"
reduces this inter-dependence.\\
So if the first phasis of "\backbone" task is sucessfully conduced, most of the
projet delivrables will be carry through, even if some delivrable are lated
or missing.
\begin{figure}\leavevmode\center
\begin{minipage}[t]{.4\linewidth}
\includegraphics[width=1\linewidth]{dependence-dev}
\caption{\label{dependence-dev}Dependence graph at development level}
\end{minipage}\hfill\begin{minipage}[t]{.4\linewidth}
\includegraphics[width=1\linewidth]{dependence-test}
\caption{\label{dependence-test}Dependence graph at validation level}
\end{minipage}
\end{figure}