source: anr/section-project-description.tex @ 302

Last change on this file since 302 was 297, checked in by coach, 14 years ago
  • Property svn:eol-style set to native
  • Property svn:keywords set to Revision HeadURL Id Date
File size: 8.4 KB
Line 
1\anrdoc{%
2Presentez le programme scientifique et justifiez la decomposition en taches du
3programme de travail en coherence avec les objectifs poursuivis.\\
4Utilisez un diagramme pour presenter les liens entre les differentes taches (organigramme technique)\\
5Les taches representent les grandes phases du projet. Elles sont en nombre
6limite.\\
7Le cas echeant (programmes exigeant la pluridisciplinarite), demontrer
8l'articulation entre les disciplines scientifiques.\\
9N'oubliez pas les activites et actions correspondant à la dissemination et à la valorisation.}
10
11
12\begin{figure}\leavevmode\center
13\includegraphics[width=.8\linewidth]{architecture-csg}
14\caption{\label{archi-csg} Software architecture for digital system generation}
15%\end{figure}\begin{figure}\leavevmode\center
16\mbox{}\vspace*{1ex}\\
17\includegraphics[width=1.0\linewidth]{architecture-hls}
18\caption{\label{archi-hls} Software architecture of hardware accellerator synthesis}
19%\end{figure}\begin{figure}\leavevmode\center
20\mbox{}\vspace*{1ex}\\
21\includegraphics[width=.8\linewidth]{architecture-hpc}
22\caption{\label{archi-hpc} Performance analysis of a HPC partitionning}
23\end{figure}
24%
25Figures~\ref{archi-csg}, \ref{archi-hls} and \ref{archi-hpc}
26summarize the software architecture of the COACH framework we will develop.
27In figures, the dotted boxes are the softwares or formats that COACH
28has to provide and to support.
29\parlf
30For the system generation presented in figure~\ref{archi-csg}, the conductor
31is the tool \verb!CSG! (COACH System Generator). Its inputs are a process
32network describing the target application and the synthesis parameters.
33The main parameters are the target hardware architectural template
34with its instantiation parameters, the hardware/software mapping of the
35tasks, the FPGA device and design constraints.
36\verb+CSG+ thus requires an architectural template library, an operating system
37library, two system hardware component (CPU, memories, BUS...) libraries
38(one for synthesis, one for simulation).
39For generating the coprocessor of a task mapped as hardware, \verb+CSG+
40controls the HAS tools described below.
41From these inputs \verb!CSG! can generate the entire system (both software and
42hardware) either as an IP under IP-XACT to integrate the SoC in larger
43design or
44as a SystemC simulator (cycle accurate and/or TLM) to prototype and explore quickly the
45design space or as a bitstream\footnote{COACH generates synthesizable VHDL, and
46launch the \xilinx or \altera RTL synthesis tools.} directly downloadable on the
47FPGA device\footnote{Additional partial bitstreams are generated in case of
48 dynamic partial reconfiguration}.
49 \\
50 Furthermore the architecture template and hardware component libraries will be described
51 under the IP-XACT specification to facilitate the configuration of \verb+CSG+ to other
52 architecture or the enhancement of existing template with IP.
53\parlf
54The software architecture for HAS is presented in figure~\ref{archi-hls}.
55The input is a single task of the process network. The HAS tools do not work
56directly on the C++ task description but on an internal format called
57\xcoach generated by a plugin into the GNU C compiler (GCC).
58This will allow on the one hand to insure that all the tools will
59accept the same C++ description and on the other hand make possible
60their chaining. The front-end tools read a \xcoach description and generate
61a new \xcoach description that exibits more parallelism or implement
62specific instructions for ASIP. The back-end tools read an \xcoach
63description and generate an \xcoachplus description. This is an \xcoach
64description annotated with hardware information (scheduling, binding) required by
65the VHDL and systemC drivers.
66Furthermore, the back-end tools uses a macro-cell library (functional and memory
67unit).
68\parlf
69In addition to digital system design, HPC requires a supplementary
70partitioning step presented in figure~\ref{archi-hpc}. The designer
71splits the initial application (tag 1) in two parts: one still on the PC and the
72other running in a FPGA plugged on the PCI/X PC bus. The two parts exchange data
73through communication primitives (tag 2) implemented in a library.
74To evaluate the relevance of the partitioning, the designer can build a
75simulator. Once the partitioning is validated, the design of the FPGA part
76is done through \verb!CSG! (figure~\ref{archi-csg}).
77\parlf
78The project is split into 8 tasks numbered from 1 to 8. They are described
79in short below and in detail in section \ref{task-description}.
80\begin{description}
81\item[Task-1: \textit{Project management}]
82    This task relates to the monitoring of the COACH project.
83\item[Task-2: \textit{\Backbone}] This task tackles the fundamental points of the
84        project such as the defintion of the COACH inputs and outputs,
85    the internal formats (i.e. \xcoach and \xcoachplus) and their associated tools,
86        the architectural templates and the design flow.
87\item[Task-3: \textit{System generation}] This task addresses the prototyping and
88    the generation of digital system. Apart from HAS that belongs to task 3
89    and 4, its components are those presented figure~\ref{archi-csg}
90    (e.g.  \verb!CSG!, operating systems).
91\item[Task-4: \textit{HAS front-end}] This task mainly focusses on four functionalities:
92    optimization of the memory usage, parallelism enhancement through loop
93    transformations, coarse grain parallelization and ASIP generation.
94\item[Task-5: \textit{HAS back-end}] This task groups two functionalities:
95    High-Level Synthesis of data dominated description and HLS of control
96    dominated description.
97    This task contains also the development of a frequency adaptator
98    that will allow the coprocessors to respect the processor and the bus
99    frequency.
100\item[Task-6: \textit{PC/FPGA communication middleware}]
101    This task pools the features dedicated to HPC. These are mainly the
102    validation of the partitioning (see figure~\ref{archi-hpc}), the sytem drivers for
103    both PC and FPGA-SoC sides, the hardware communication components and
104        the support for dynamic partial reconfiguration.
105\item[Task-7: \textit{Industrial demonstrators}]
106    This task groups the demonstrators of the COACH project.
107    Most of them are industrial applications that will be developped within
108    the COACH framework.
109    Others consist in integrating the COACH framework as a driver of
110    industrial proprietary design tools.
111\item[Task 8: \textit{Dissemination}]
112    This task concerns the diffusion of the project results.
113    It mainly consists of the production of 4 COACH releases (\verb!T0+12!, \verb!T0+18!,
114    \verb!T0+24! and \verb!T0+36!), the publication of a tutorial and user manuals on a WEB site, the publication
115        of research papers in international journals and conferences and the organization of workshops and tutorials in
116        international conferences.
117\end{description}
118%
119\begin{figure}\leavevmode\center
120%\includegraphics[width=.4\linewidth]{dependence-task}
121\includegraphics[width=0.70\linewidth]{dependence-task-h}
122\caption{\label{dependence-task}Task dependencies}
123\end{figure}
124Figure~\ref{dependence-task} presents the tasks dependencies.
125"$T_N \longrightarrow T_M$" means that $T_N$ impacts the $T_M$.
126The more bold the arrow, the more important is the impact.
127The graph shows:
128\begin{itemize}
129\item Even though $T4$ and $T5$ functionalities are complementary,
130their developments are independent (thanks to the \xcoach internal format).
131\item $T3$ slightly depends on $T4$ and $T5$. Indeed, $T3$ may work
132without $T4$ and $T5$ if targeted digital systems do not include hardware
133accelerators.
134\item $T3$ strongly impacts $T6$ but $T3$ does not depend at all on
135$T6$. Hence demonstrators ($T7$) of embedded system would not be impacted if
136$T6$ would fail. 
137\item $T2$ drives all the tasks ($T3$, $T4$, $T5$, $T6$) and is at the heart of
138the COACH project.
139\item The demonstrators developped in $T7$, of course strongly depend on the achievements
140of the previous tasks ($T2$, $T3$, $T4$, $T5$, $T6$).
141\item $T8$ and $T1$ depend on and impact all the other tasks.
142\end{itemize}
143This organisation offers enough robustness to insure the success of the
144project except for the specification task $T2$.
145The only critical task in this chart is $T2$. \label{xcoach-problem}
146However, the partners met
14712 times (a one-day meeting per month) during the last year: 10 meetings to exchange and work on scientific
148and technical aspects and 2 meetings to prepare the project proposal. This gives us a high degree of confidence
149that $T2$ will be completed in time.
Note: See TracBrowser for help on using the repository browser.