source: anr/section-4.1.tex @ 67

Last change on this file since 67 was 65, checked in by coach, 15 years ago

IA: modif UBS

File size: 7.5 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%FIXME: la figure ne montre que l'aspect simulation. Intégrer la partie génération (PC API, PCIX, FPGA-IP, bridge vers VCI, SoC API) serait un plus, non ?
14%
15Figures~\ref{archi-csg}, \ref{archi-hls} and \ref{archi-hpc}
16summarize the software architecture of the COACH framework we will develop.
17In figures, the dotted boxes are the softwares or formats that COACH
18has to provide and to support.
19\vspace*{.75ex}\par
20For the system generation presented in figure~\ref{archi-csg}, the conductor
21is the tool \verb!CSG! (COACH System Generator). Its inputs are a process
22network describing the application to design and the synthesis parameters.
23The main parameters are the target hardware architectural template
24with its instanciation parameters, the hardware/software mapping of the
25tasks, the FPGA device and design constraints.
26\verb+CSG+ thus requires an architectural template library, a operating system
27library, two system hardware component (CPU, memories, BUS...) libraries
28(one for synthesis, one for simulation).
29For generating the coprocessor of a task mapped as hardware, \verb+CSG+
30controls the HAS tools described below.
31From these inputs \verb!CSG! can generate the entire system (both software \&
32hardware) either as a SystemC simulator to prototype and explore quickly the
33design space or as a bitstream\footnote{COACH generates synthesizable VHDL, and
34launch the Xilinx or Altera RTL synthesis tools.} directly downloadable on the
35FPGA device\footnote{Additional partial bitstreams are generated in case of
36 dynamic partial reconfiguration}.
37\\
38%To proove CSG that COACH is open and CSG is really configurable, COACH will
39%basically support 3 architecture template (the COACH template based on a
40%MIPS processors and a VCI token ring, the Altera template based on the NIOS
41%and AVALON bus, the Xilinx template based on the MICROBLAZE and OPB bus)
42%and 2 operating systems (DNA/OS and MUTEK). Furthermore, thus is enforced
43%by the \mustbecompleted{FIXME:zied} contribution that consists in
44%implementing an other hardware target.
45%\\
46%Finally, it is important to notice that this work is a strong
47%enhancement of the SocLib software.
48\vspace*{.75ex}\par
49The software architecture for HAS is presented in figure~\ref{archi-hls}.
50The input is a single task of the process network. The HAS tools do not work
51directly on the C++ task description but on an internal format called
52\xcoach generated by a plugin into the GNU C compiler (GCC).
53This allows on the one hand to insure that all the tools will
54accept the same C++ description and on the other hand to make possible
55their chaining. The front-end tools read a \xcoach description and generate
56a new \xcoach description that exibits more parallelism or implement
57specific instructions for ASIP. The back-end tools read a \xcoach
58description and generate a \xcoachplus description. This is a \xcoach
59description anotated with hardware information (scheduling, binding) required by
60the VHDL and systemC drivers.
61Furthermore, the back-end tools uses a macro-cell library (functional and memory
62unit).
63\vspace*{.75ex}\par
64In addition to digital system design, HPC requires a supplementary
65partitioning step presented in figure~\ref{archi-hpc}. The designer
66splits the initial application (tag 1) in two parts: one still on the PC and the
67other running in a FPGA plugged on the PCI/X PC bus. The two parts exchange data
68through communication primitives (tag 2) implemented in a library.
69To evaluate the relevance of the partitioning, the designer can build a
70simulator. Once the partitioning is validated, the design of the FPGA part
71is done through \verb!CSG! (figure~\ref{archi-csg}).
72\vspace*{.75ex}\par
73\mustbecompleted{FIXME == MODIFICATION DE LA FIGURE}
74The project is split into 8 tasks numbered from 0 to 7.
75The first task (task 0) is the project management, the last one (task 7) is
76the dissemination the other task are listed below:
77\begin{enumerate}
78\item\textbf{\Backbone:} This task tackles the fundamental points of the
79        project such as the defintion of the COACH inputs and outputs,
80    the internal formats (e.g. \xcoach), the architectural templates and
81    the design flow.
82\item\textbf{System generation:} This task addresses the prototyping and
83    the generation of digital system. Apart from HAS that belong to the task 3
84    and 4, its components are those presented figure~\ref{archi-csg}
85    (e.g.  \verb!CSG!, operating systems).
86\item\textbf{HAS front-end:} This task mainly focusses on four functionalities:
87    optimization of the memory usage, parallelism enhancement through loop
88    transformations, coarse grain parallelization and ASIP generation.
89\item\textbf{HAS back-end:} This task groups two functionalities:
90    High-Level Synthesis of data dominated description and HLS of control
91    dominated description.
92    This task contains also the development of a frequency adaptator
93    that will allow the coprocessors to respect the processor \& the bus
94    frequency.
95\item\textbf{Communication between PC \& FPGA-SoC:}
96    This task pools the features dedicated to HPC. The main are the
97    partitioning validation (see figure~\ref{archi-hpc}), the sytem drivers for
98    both PC and FPGA-SoC sides, the hardware communication components and
99        support for dynamic partial reconfiguration.
100\item\textbf{Demonstrators:}
101    This task groups the demonstrators of the COACH project.
102    \mustbecompleted{FIXME}
103\end{enumerate}
104%
105\begin{figure}\leavevmode\center
106%\includegraphics[width=.4\linewidth]{dependence-task}
107\includegraphics[width=0.70\linewidth]{dependence-task-h}
108\caption{\label{dependence-task}Task dependencies}
109\end{figure}
110Figure~\ref{dependence-task} presents the tasks dependencies.
111"$task-N \longrightarrow task-M$" means that $task-N$ impacts the $task-M$.
112The more bold is the arrow, the more important is the dependency.
113The graph shows:
114\begin{itemize}
115\item Even that $T3$ and $T4$ functionalities are complementary, their
116developments are independent (thanks to \xcoach internal format).
117\item $T2$ slightly depends on $T3$ and $T4$. Indeed, $T2$ may works
118without $T3$ and $T4$ if we limit to digital systems without hardware
119accellerators.
120\item $T2$ strongly impacts on $T5$ but, $T2$ does not depend at all on
121$T5$. So demonstrators ($T6$) of embedded system would not be impacted if
122$T5$ would fail. 
123\item $T1$ drives all the tasks ($T2$, $T3$, $T4$, $T5$) at the heart of
124the COACH project.
125\item The demonstrators developped in $T6$, of course, strongly depends on the achievements
126of the prvious tasks ($T1$, $T2$, $T3$, $T4$, $T5$).
127\item $T7$ and $T0$ respectively depends on and impacts all the other tasks.
128\end{itemize}
129This organisation offers enough robustness to insure the success of the
130project except for the specification task $T1$.
131
132The only critical task in this chart is T1. \label{xcoach-problem}
133However, the partners met
13410 times (a one day meeting per month) during the last year to prepare the
135specification and the project proposal. This gives us a degree of confidence
136that T1 will be completed in time.
Note: See TracBrowser for help on using the repository browser.