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

Last change on this file since 385 was 385, checked in by coach, 14 years ago

ia: bull to 24 hm + correction MDS.

  • Property svn:eol-style set to native
  • Property svn:keywords set to Revision HeadURL Id Date
File size: 9.2 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}[h!]\leavevmode\center
13\includegraphics[width=.7\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 HAS (hardware Accelerator Synthesis)}
19%\end{figure}\begin{figure}\leavevmode\center
20%\mbox{}\vspace*{1ex}\\
21\includegraphics[width=.65\linewidth]{architecture-hpc}
22\caption{\label{archi-hpc} Performance analysis of a HPC partitioning}
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 \verb!HAS! (Hardware Accelerator Synthesis) 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 \verb!HAS! is presented in figure~\ref{archi-hls}.
55The input is a single task of the process network. The \verb!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 an \xcoach description and generate
61a new \xcoach description that exhibits 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 use a macro-cell library (functional and memory
67unit).
68\parlf
69\label{HPC:howto}%
70In addition to digital system design, HPC requires a supplementary
71partitioning step presented in figure~\ref{archi-hpc}. The designer
72splits the initial application (tag 1) into two parts: one still on the PC and the
73other running in a FPGA plugged on the PCI/X PC bus. The two parts exchange data
74through communication primitives (tag 2) implemented in a library.
75To evaluate the relevance of the partitioning, the designer can build a
76simulator. Once the partitioning is validated, the design of the FPGA part
77is done through \verb!CSG! (figure~\ref{archi-csg}).
78\parlf
79The project is split into 8 tasks. They are described
80in short below and in detail in section \ref{task-description}.
81\begin{description}
82\item[Task-1: \textit{Project management}]
83    This task relates to the monitoring of the COACH project.
84\item[Task-2: \textit{\Backbone}] This task tackles the fundamental points of the
85        project such as the definition of the COACH inputs and outputs,
86    the internal formats (i.e. \xcoach and \xcoachplus) and their associated tools,
87        the architectural templates and the design flow.
88\item[Task-3: \textit{System generation}] This task addresses the prototyping and
89    the generation of digital system. Apart from \verb!HAS! that belongs to task 3
90    and 4, its components are those presented in figure~\ref{archi-csg}
91    (e.g.  \verb!CSG!, operating systems).
92\item[Task-4: \textit{HAS front-end}] This task mainly focusses on four functionalities:
93    optimization of the memory usage, parallelism enhancement through loop
94    transformations, coarse grain parallelization and ASIP generation.
95\item[Task-5: \textit{HAS back-end}] This task groups two functionalities:
96    High-Level Synthesis of data dominated description and HLS of control
97    dominated description.
98    This task contains also the development of a frequency adapter
99    that will allow the coprocessors to meet processor and bus
100    frequency constraints.
101\item[Task-6: \textit{PC/FPGA communication middleware}]
102    This task pools the features dedicated to HPC. These are mainly the
103    validation of the partitioning (see figure~\ref{archi-hpc}), the system drivers for
104    both PC and FPGA-SoC sides, the hardware communication components and
105        the support for dynamic partial reconfiguration.
106\item[Task-7: \textit{Industrial demonstrators}]
107    This task groups the demonstrators of the COACH project.
108    Most of them are industrial applications that will be developed within
109    the COACH framework.
110    Others consist in integrating the COACH framework into
111    industrial proprietary design tools.
112\item[Task 8: \textit{Dissemination}]
113    This task concerns the diffusion of the project results.
114    It mainly consists of the production of 4 COACH releases (\verb!T0+12!, \verb!T0+18!,
115    \verb!T0+24! and \verb!T0+36!), the publication of a tutorial and user manuals on a WEB site, the publication
116        of research papers in international journals and conferences and the organization of workshops and tutorials in
117        international conferences.
118\end{description}
119%
120\begin{figure}\leavevmode\center
121%\includegraphics[width=.4\linewidth]{dependence-task}
122\includegraphics[width=0.50\linewidth]{dependence-task-h}
123\caption{\label{dependence-task}Task dependencies}
124\end{figure}
125Figure~\ref{dependence-task} presents the tasks dependencies.
126"$T_N \longrightarrow T_M$" means that $T_N$ impacts the $T_M$.
127The more bold the arrow, the more important is the impact.
128The graph shows:
129\begin{itemize}
130\item Even though $T4$ and $T5$ functionalities are complementary,
131their developments are independent (thanks to the \xcoach internal format).
132\item $T3$ slightly depends on $T4$ and $T5$. Indeed, $T3$ may work
133without $T4$ and $T5$ if targeted digital systems do not include hardware
134accelerators.
135\item $T3$ strongly impacts $T6$ but $T3$ does not depend at all on
136$T6$. Hence demonstrators ($T7$) of embedded system would not be impacted if
137$T6$ would fail. 
138\item $T2$ drives all the tasks ($T3$, $T4$, $T5$, $T6$) and is at the heart of
139the COACH project.
140\item The demonstrators developed in $T7$, of course strongly depend on the achievements
141of the previous tasks ($T2$, $T3$, $T4$, $T5$, $T6$).
142\item $T8$ and $T1$ depend on and impact all the other tasks.
143\end{itemize}
144%This organisation offers enough robustness to insure the success of the
145%project, the only critical task in this chart being $T2$.
146%%However, the partners met 12 times (a one-day meeting per month) during the last year.
147%%Ten meeting were dedicated to preliminary technical discussions, including a tentative specification
148%%of {\tt xcoach}. The other meetings were dedicated to the preparation of the present proposal.
149%However, the partners had 10 one-day meetings where a preliminary draft of the
150%\xcoach format was defined. This makes this task less critical.
151This project has been shaped with this chart in order to minimize the technical
152risk: the task $T2$ handles the major technical issues to be solved and as it is
153planned at the beginning of the project we will be able to react fast and take
154decisions for possible workaround and enable the continuation of the work with
155other tasks.
156\label{xcoach-problem}
157Nevertheless, we are confident because in preparation to this project,
158academic partners are already working close together and know well each other's
159technologies, and also a lot of face to face meeting are planned at the
160beginning of the project in task $T2$ in order to define the \xcoach format which is
161the corner stone of the COACH platform.
162
Note: See TracBrowser for help on using the repository browser.