Index: anr/section-4.1.tex
===================================================================
--- anr/section-4.1.tex	(revision 12)
+++ anr/section-4.1.tex	(revision 21)
@@ -1,9 +1,9 @@
 \begin{figure}\leavevmode\center
 \includegraphics[width=.8\linewidth]{architecture-csg}
-\caption{\label{archi-csg} software architecture for embedded system generation}
+\caption{\label{archi-csg} software architecture for digital system generation}
 %\end{figure}\begin{figure}\leavevmode\center
 \mbox{}\vspace*{1ex}\\
-\includegraphics[width=.8\linewidth]{architecture-hls}
-\caption{\label{archi-hls} software architecture of HLS}
+\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}\\
@@ -15,49 +15,57 @@
 summarize the software architecture of COACH framework we plan to develop.
 In figures, the dotted boxes are the softwares or formats that COACH
-has to provide or define.
+has to provide.
 \vspace*{.75ex}\par
-For the system genration presented figure~\ref{archi-csg}, the conductor is
-the program \verb!CSG! (COACH System Generator). Its inputs are a process
-network and miscellaneaous generation parameters.
-The main parameters are the template of the target hardware architecture
+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 and the FPGA device.
-From these inputs \verb!CSG! can generate the system (software \& hardware) as
-a SystemC simulator to prototype and explore quickly the system design
-space and/or as a bitstream directly downloadable on the FPGA device.
-For processing, \verb+CSG+ requires 1) a hardware template found into the
-architecture library, 2) a micro-kernel, it chooses among
-two in the micro kernel library, 3) the system hardware components that
-are taken from the SystemC model library for the simulator and from the
-VHDL component library for the FPGA bitstream.  
-For generating the coprocessor of a task mapped as harware, \verb+CSG+
-controls the HLS tools described below.
+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.
+%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 HLS is presented figure~\ref{archi-hls}.
-The input is a task of the process network. The HLS tools do not work
+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 the GNU C compiler (GCC) tainted by a COACH
 driver. 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
-to chain them. The front-end tools read a \xcoach description and writes
-a new \xcoach description that exibits possible parallelism or implement
-specific instruction for ASIP. The back-end tools read a \xcoach
-description and generates a \xcoach+ description that is a \xcoach
-description anotated with hardware information to let work the VHDL systemC
-drivers. Furthermore, the back-end tools uses a macro-cell library.
+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
-The software architecture for HPC is presented figure~\ref{archi-hpc}.
-\mustbecompleted{FIXME Miss HPC description\\\ldots\\\ldots\\\ldots\\\ldots.}
+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
 The project is splitted into 8 tasks numbered from 0 to 7.
@@ -65,41 +73,55 @@
 the dissemination the other task are listed below:
 \begin{enumerate}
-\item\textbf{\backbone:} This task groups the critical issues of the
-	project. They consist of the definition of COACH inputs, the \xcoach
-	format that is mandatory to develop the HLS tools and the HLS drivers
-	that are mandatory for testing the HLS tools. 
-\item\textbf{system generation:} This task groups \verb+CSG+s and the components
-	required to generate the system simulator and bitstream except the HLS
-	tools that belong to the task 3 and 4. These components are the
-	operating systems, the VHDL description and SystemC models of the
-	target hardware achitectures.
-\item\textbf{HLS front-end:} This task groups the 4 HLS front-head. Those
-	are a tool that exhibits fine grain parallelism using polyedric
-	transformation, a tool that exhibits coarse grain parallelism,
-	a tool that minimizes the memory usage and a tool that implement ASIP.
-\item\textbf{HLS back-end:} This task groups two HLS back-end tool, one
-	for treating the data oriented description, the second for treating the
-	control dominated description. This task contains also a the
-	development of a frequency adaptator that will allow the coprocessor
-	to respect the processor \& bus frequency.
-\item\textbf{Communication software PC/FPGA-SoC:} This task groups all what is mandatorythe critical issues of the
-\item\textbf{Demonstrator:} This task groups the demostrators of the COACH project.
+\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{Demonstrator:}
+    This task groups the demostrators of the COACH project.
+    \mustbecompleted{FIXME}
 \end{enumerate}
-This task division offers the avantage that tasks except for the "\backbone" and
-"demonstrator" task are almost independent at the development level as shown
-figure~\ref{dependence-dev}. The dependence at the validation level is
-presented figure~\ref{dependence-test}. It is more critical but the
-redundance in the tasks "HLS front-end", "HLS back-end" and "demonstrators"
-reduces this inter-dependence.\\
-So if the first phasis of "\backbone" task is sucessfully conduced, most of the
-projet delivrables will be carry through, even if some delivrable are lated
-or missing.
+%
 \begin{figure}\leavevmode\center
-\begin{minipage}[t]{.4\linewidth}
-\includegraphics[width=1\linewidth]{dependence-dev}
-\caption{\label{dependence-dev}Dependence graph at development level}
-\end{minipage}\hfill\begin{minipage}[t]{.4\linewidth}
-\includegraphics[width=1\linewidth]{dependence-test}
-\caption{\label{dependence-test}Dependence graph at validation level}
-\end{minipage}
+%\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}
+So this organisation offers enough robustness for insure the success of the
+project except for the specification task $T1$. However, the partners meet
+10 times (a one day meeting per month) during the last years to prepare the
+specification and the project proposal.
