source: anr/section-3.2.tex @ 235

% les objectifs scientifiques/techniques du projet.
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
device).  The design steps are presented figure~\ref{coach-flow}.
\begin{figure}[hbtp]\leavevmode\center
  \includegraphics[width=.8\linewidth]{flow}
  \caption{\label{coach-flow} COACH design flow}
\end{figure}
\begin{description}
\item[HPC setup:] During this step, the user splits the application into 2 parts: the host application
which remains on a PC and the SoC application which is mapped on the FPGA. 
COACH will allow to automatically translate high level language programs to FPGA configurations.
In addition, it will provide a SystemC simulation model of the whole system (PC+communication+FPGA-SoC) 
which will allow performance evaluation of the partitioning.
\item[SoC design:] In this phase, 
COACH will allow the user to obtain simulators for the SoC at different abstraction levels by giving to the COACH framework a SoC description.  
This description will consist of a process network corresponding to the application, 
an OS, an instance of a generic hardware platform
and a mapping of processes on the platform components. COACH will offer different targets to map the processes:  
software (the process runs on a SoC processor),
ASIP (the process runs on a SoC processor enhanced with dedicated instructions),
and hardware (the process runs into a coprocessor that is generated by HLS and plugged on the SoC bus).
\item[Application compilation:] Once the SoC description is validated through performances analysis, COACH will generate automatically
an FPGA bitstream containing the hardware platform with the SoC application software and 
an executable containing the host application. The user will be able to launch the application by
loading the bitstream on an FPGA and running the executable on PC.
\end{description}
 
% l'avancee scientifique attendue. Preciser l'originalite et le caractere 
% ambitieux du projet. 
%FIXME == {NON ceci n'est pas une contribution scientifique. A re-ecrire}

%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 another and even to chain them. For instance, it will be possible to run loop transformations before synthesis.
%Another advantage of this framework is to provide different abstraction levels from
%a single description.
%Finally, this description is device family independent and its hardware implementation
%is automatically generated.

% Detailler les verrous scientifiques et techniques a lever par la realisation du projet.
System design is a very complex task and in this project we will try to simplify it
as much as possible. For this purpose the following scientific and technological barriers
have to be addressed.

\begin{description}
\item[Design Space Exploration:]
    The COACH environment will allow to easily map an application described by using a process 
        network Model of Computation (MoC) on a shared-memory, MPSoC architecture. COACH will
        allow to explore the design space by allowing system designer to select and 
        parameterize the target architecture, and to define the best hardware/software 
        partitioning of the application.
\item[Hardware Accelerators Synthesis (HAS):]
    COACH will allow the automatic generation of hardware accelerators when required.
    Hence, High-Level Synthesis (HLS) tools, Application Specific Instruction Processor
    (ASIP) design environment and source-level transformation tools (loop transformations
    and memory optimisation) will be provided.
    This will allow further exploration of the micro-architectural design space.
    HLS tools are sensitive to the coding style of the input specification and the domain
    they target (control vs. data dominated).
    The HLS tools of COACH will support a common language and coding style to avoid
    re-engineering by the designer.
\item[Platform based design:] 
    COACH will handle both \altera and \xilinx FPGA devices.
    COACH will define architectural templates that can be customized by adding
    dedicated coprocessors and ASIPs and by fixing template parameters such as
    the number of embedded processors, the number of sizes of embedded memory banks
    or the embedded the operating system.
    However, the specification of the application will be independant of both the
    architectural template and the target FPGA device.
    Basically, the 3 following architectural templates will be provided:
    \begin{enumerate}
    \item A \mustbecompleted{FIXME :: Neutral est tres pejoratif. Technology inependent, independant, standard ???} Neutral architectural template based on the SoCLib IP core library and the
      VCI/OCP communication infrastructure.
    \item An \altera architectural template based on the \altera IP core library, the
      AVALON system bus and the NIOS processor.
    \item A \xilinx architectural template based on the Xilinx IP core library, the PLB
      system bus and the Microblaze processor.
    \end{enumerate}
\item[Hardware/Software communication middleware:]
    COACH will implement an homogeneous HW/SW communication infrastructure and
    communication APIs (Application Programming Interface), that will be used for 
    communications between software tasks running on embedded processors and 
    dedicated hardware coprocessors.
\end{description}



----------------------------------------------------------------------------------------------


\begin{itemize}
\item HLS tools are sensitive to the style in which the algorithm is written.
In addition, they are are not integrated into an architecture and system 
exploration tool. Consequently, engineering work is required to swap from a tool to another,
to integrate the resulting simulation model to an architectural exploration tool 
and to synthesize the generated RTL description.
%CA Additionnal preprocessing, source-level transformations, are thus
%CA required to improve the process.
%CA Particularly, this includes parallelism exposure and efficient memory mapping.
\item Most HLS tools translate a sequential algorithm into a coprocessor
containing a single data-path and finite state machine (FSM). In this way,
only the fine grained parallelism is exploited (ILP parallelism).
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). 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.
\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 clock frequency must not be a result of the RTL synthesis
but a strict synthesis constraint.
\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 run-time efficiency. The second is 
its engineering  cost, especially if one want to refine an implementation
at several abstract levels.

\end{itemize}

%Presenter les resultats escomptes en proposant si possible des criteres de reussite 
%et d'evaluation adaptes au type de projet, permettant d'evaluer les resultats en 
%fin de projet.
The main result is the framework. It is composed concretely of: 
a communication middleware for HPC, 
5 HAS tools (control dominated HLS, data dominated HLS, Coarse grained HLS, 
Memory optimisation HLS and ASIP),
3 architectural templates that are synthesizable and that can be prototyped,
one design space exploration tool,
2 operating systems (DNA/OS and MUTEKH).
\\
The framework fonctionality will be demonstrated with the demonstrators
(see task-7 page~\pageref{task-7}) and the tutorial example (see task-8
page~\ref{subtask-tutorial}).