Index: anr/section-3.2.tex =================================================================== --- anr/section-3.2.tex (revision 32) +++ anr/section-3.2.tex (revision 33) @@ -1,4 +1,4 @@ % les objectifs scientifiques/techniques du projet. -The objectives of COACH project are to develop a complete framework to HPC +The objectives of the COACH project are to develop a complete framework to HPC (accelerating solutions for existing software applications) and embedded applications (implementing an application on a low power standalone @@ -10,9 +10,8 @@ \begin{description} \item[HPC setup] Here the user splits the application into 2 parts: the host application -which remains on PC and the SoC application which migrates on SoC. -The framework provides a simulation model allowing to evaluate the partitioning. +which remains on a PC and the SoC application which migrates into a SoC. +The framework provides a simulation model which allows an evaluation of the partitioning. \item[SoC design] In this phase, -The user can obtain simulators at different abstraction levels of the SoC by giving to COACH framework -a SoC description. +The user can obtain simulators for the SoC at different abstraction levels by giving to the COACH framework a SoC description. This description consists of a process network corresponding to the SoC application, an OS, an instance of a generic hardware platform @@ -21,8 +20,8 @@ XXXpeci (the process runs on a SoC processor enhanced with dedicated instructions), and hardware (the process runs into a coprocessor generated by HLS and plugged on the SoC bus). -\item[Application compilation] Once SoC description is validated, COACH generates automatically -an FPGA bitstream containing the hardware platform with SoC application software and +\item[Application compilation] Once the SoC description is validated, COACH generates automatically +an FPGA bitstream containing the hardware platform with the SoC application software and an executable containing the host application. The user can launch the application by -loading the bitstream on FPGA and running the executable on PC. +loading the bitstream on an FPGA and running the executable on PC. \end{description} @@ -31,6 +30,5 @@ The main scientific contribution of the project is to unify various synthesis techniques (same input and output formats) allowing the user to swap without engineering effort -from one to an other and even to chain them, for example, to run polyedric transformation -before synthesis. +from one to another and even to chain them. for instance, it will be possible to run polyedric transformations before synthesis. Another advantage of this framework is to provide different abstraction levels from a single description. @@ -44,11 +42,11 @@ \begin{itemize} \item The main problem in HPC is the communication between the PC and the SoC. -This problem has 2 aspects. The first one is the efficiency. The second is to -eliminate enginnering effort to implement it at different abstract levels. -\item COACH design flow has a top-down approach. In the such case, -the required performance of a coprocessor (run frequency, maximum cycles for +This problem has 2 aspects. The first one is the run-time efficiency. The second is its engineering cost, especially if one want to refine an implementation +at several abstract levels. +\item The COACH design flow has a top-down approach. In such a case, +the required performance of a coprocessor (clock frequency, maximum cycles for a given computation, power consumption, etc) are imposed by the other system components. The challenge is to allow user to control accurately the synthesis -process. For instance, the run frequency must not be a result of the RTL synthesis +process. For instance, the clock frequency must not be a result of the RTL synthesis but a strict synthesis constraint. \item HLS tools are sensitive to the style in which the algorithm is written. @@ -66,5 +64,10 @@ The challenge is to identify the coarse grained parallelism and to generate, from a sequential algorithm, coprocessor containing multiple communicating -tasks (data-paths and FSMs). +tasks (data-paths and FSMs). To this aim, one may adapt techniques which +were developed in the 1990 for the construction of distributed programs. +However, in the context of HLS, there are still several original problems +to be solved, mainly to do with the construction of FIFO communication +channels and with memory optimization. + \end{itemize} @@ -73,5 +76,5 @@ %fin de projet. The main result is the framework. It is composed concretely of: -2 HPC communication shemes with their implementation, +2 HPC communication schemes with their implementation, 5 HLS tools (control dominated HLS, data dominated HLS, Coarse grained HLS, Memory optimisation HLS and ASIP), Index: anr/section-4.1.tex =================================================================== --- anr/section-4.1.tex (revision 32) +++ anr/section-4.1.tex (revision 33) @@ -12,6 +12,6 @@ \end{figure} % -The figures~\ref{archi-csg}, \ref{archi-hls} and \ref{archi-hpc} -summarize the software architecture of COACH framework we plan to develop. +Figures~\ref{archi-csg}, \ref{archi-hls} and \ref{archi-hpc} +summarize the software architecture of the COACH framework we plan to develop. In figures, the dotted boxes are the softwares or formats that COACH has to provide. @@ -48,5 +48,8 @@ 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 +\xcoach generated by a the GNU C compiler (GCC) +%Paul: ``tainted'' ça ve dire ``souillé''. Qu'est-ce que tu veux dire +%exactement: piloté, modifié ....? +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 @@ -69,5 +72,5 @@ is done through \verb!CSG! (figure~\ref{archi-csg}). \vspace*{.75ex}\par -The project is splitted into 8 tasks numbered from 0 to 7. +The project is split into 8 tasks numbered from 0 to 7. The first task (task 0) is the project management, the last one (task 7) is the dissemination the other task are listed below: @@ -95,5 +98,5 @@ both PC and FPGA-SoC sides, the hardware communication components. \item\textbf{Demonstrators:} - This task groups the demostrators of the COACH project. + This task groups the demonstrators of the COACH project. \mustbecompleted{FIXME} \end{enumerate} @@ -122,6 +125,11 @@ \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. +This organisation offers enough robustness to insure the success of the +project except for the specification task $T1$. + +The only critical task in this chart is T1. + +However, the partners met +10 times (a one day meeting per month) during the last year to prepare the +specification and the project proposal. This gives us a degree of confidence +that T1 will be completed in time.