\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} % Figures~\ref{archi-csg}, \ref{archi-hls} and \ref{archi-hpc} summarize the software architecture of the COACH framework we plan to develop. In figures, the dotted boxes are the softwares or formats that COACH has to provide. \vspace*{.75ex}\par For the system genration presented in figure~\ref{archi-csg}, the conductor is the tool \verb!CSG! (COACH System Generator). Its inputs are a process network describing the application to design and the synthesis parameters. The main parameters are the target hardware architectural template with its instanciation parameters, the hardware/software mapping of the tasks, the FPGA device and design constraints. \verb+CSG+ thus requires an architectural template library, a 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 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. \\ %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 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 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 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 a \xcoach description and generate a \xcoachplus description. This is a \xcoach description anotated 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). \vspace*{.75ex}\par 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 if 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}). \vspace*{.75ex}\par \mustbecompleted{FIXME == MODIFICATION DE LA FIGURE} The project is split 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 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\textbf{System generation:} This task addresses the prototyping and the generation of digital system. Apart from HAS that belong to the task 3 and 4, its components are those presented figure~\ref{archi-csg} (e.g. \verb!CSG!, operating systems). \item\textbf{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\textbf{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\textbf{Communication between PC \& FPGA-SoC:} This task pools the features dedicated to HPC. The main are the partitioning validation (see figure~\ref{archi-hpc}, the sytem drivers for both PC and FPGA-SoC sides, the hardware communication components. \item\textbf{Demonstrators:} This task groups the demonstrators of the COACH project. \mustbecompleted{FIXME} \end{enumerate} % \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 dependencies between the tasks. "$task-N \longrightarrow task-M$" means that $task-N$ requires $task-M$ to work and be demonstrated. The more bold is the arrow, the more important is the dependency. The graph shows: \begin{itemize} \item Even that $T3$ and $T4$ functionalities are complementary, their developments are independent (thanks to \xcoach internal format). \item $T2$ depends slightly from $T3$ and $T4$. Indeed, $T2$ may works without $T3$ and $T4$ if we limit to digital systems without hardware accellerators. \item $T5$ strongly depends on $T2$ but, $T2$ does not depend at all on $T5$. So demonstrators ($T6$) of embedded system would not be impacted if $T5$ would fail. \item $T1$ drives all the tasks ($T2$, $T3$, $T4$, $T5$) at the heart of the COACH project. \item $T7$ and $T0$ 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 $T1$. The only critical task in this chart is T1. \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 T1 will be completed in time.