source: anr/section-4.1.tex @ 283

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