source: anr/task-frontend.tex @ 334

\begin{taskinfo}
\let\LIP\leader
\let\IRISA\enable
\let\UBS\enable
\let\UPMC\enable
\let\TIMA\enable
\end{taskinfo}
%
\begin{objectif}
The objective of this task is to convert the input specification of
an hardware accelerator, which must be written in a familiar language
(C/C++) with as few constraints as possible, into a form suitable for
the HLS tools (i.e. HAS back-end tools of the COACH project). If the 
target is an ASIP, the frontend has to extract 
patterns from the source code and convert them into the definition
of an extensible processor. If the target is a process network, the
front end has to distribute the workload and the data sets as fairly
as possible, identify communication channels, and output an \xcoach
description.
\end{objectif}
%
\begin{workpackage}
  \subtask{ASIP compiler}
  This sub-task aims at providing compiler support for custom instructions 
  within the HAS front-end. It will take as input the COACH intermediate 
  representation, and will output an annotated COACH IR containing the custom
  instructions definitions along with their occurrence in the application.
    \begin{livrable}
      \itemV{0}{18}{x}{\Sirisa}{ASIP compilation flow}
        In this first version of the software, the computations patterns corresponding to
        custom instructions are specified by the user, and then automatically extracted (when
        beneficial) from the application intermediate representation. 
      \itemL{18}{27}{x}{\Sirisa}{ASIP compilation flow}{0:6:3}
        In this second version, the software will also be able to automatically identify 
        interesting pattern candidates in the application code, and use them as custom 
        instructions.  
    \end{livrable}
 
 \subtask{Micro-architectural template models for ASIP}
 In this sub-task, we provide micro-architectural template models for the two target
 processor architectures (NIOS-II and MIPS) supported within the COACH-ASIP design flow. 
 For each processor, we provide a simulation model (System-C) and a synthesizable model (VHDL) 
 of the architecture, along with its architectural extensions 
    \begin{livrable}
      \itemV{0}{12}{x}{\Sirisa}{SystemC for extensible MIPS }
      { A SystemC simulation model for a simple extensible MIPS architectural template }
      \itemL{12}{20}{x}{\Sirisa}{SystemC for extensible MIPS}{2:3:0}
      {A SystemC simulation model for an extensible MIPS with a tight architectural integration of
      its instruction set extensions}
      \itemV{3}{18}{h}{\Sirisa}{VHDL for an extensible MIPS}
      {A synthesizable VHDL model for a simple extensible MIPS architectural template}
      \itemL{18}{27}{h}{\Sirisa}{VHDL for extensible MIPS}{9:9:3}
      {A synthesizable VHDL model for an extensible MIPS with a tight architectural integration of
      its instruction set extensions}
      \itemL{27}{36}{d}{\Sirisa}{Evaluation report }{0:0:2}
      {An evaluation report with quantitative analysis of the performance/area trade-off induced by
      the different approaches}
    \end{livrable}

 \subtask{Automatic parallelization and memory optimization}
This sub-task aims at providing a source-level optimizer in front the
HLS back-end tools. The optimizations are threefold:
\begin{itemize}
\item Extraction of parallelism in polyhedral loops and conversion
  into a process network.
\item Minimization of intra-process local memory
\item Construction of inter-process FIFOs
\end{itemize}
We will design these methods by using polyhedral techniques, as we did
in the past for pure HPC optimizations. The program model is typically
regular programs where loop bounds, conditions and array indices are
affine functions. In a second part, we will extend the program model
by using conservative approximations.
   \begin{livrable}
    \itemV{0}{6}{d}{\Slip}{Method, Preliminary Definition}
      Description and specification of a process construction method for programs with 
      polyhedral loops. 
    \itemV{6}{12}{x}{\Slip}{Process construction}
      Preliminary implementation in the Syntol framework. 
      At this step the software will just implement a single constructor.
    \itemL{30}{36}{d+x}{\Slip}{Process generation method}{4:0:3}
      Final assessment of the method and improved version of the specification.
%
    \itemV{6}{12}{d}{\Slip} {Arrays and FIFO}
    Description and specification of the FIFO construction method
    and the local memory optimization method.
    \itemV{12}{18}{d+x}{\Slip} {Arrays and FIFO}
    Preliminary implementation in the Bee framework.
    Conversion of the input and output of Bee to the \xcoach format.
    At this step, only local memory optimization will be available.
    \itemL{18}{30}{d+x}{\Slip}{Arrays and FIFO}{1.5:3.0:1.5}
    Final assessment of the method and improved version of the specification.
%
    \itemV{18}{30}{d+x}{\Slip}{Non-polyhedral extension}
      Extension of automatic parallelization and memory optimization
      to non-polyhedral loops. Implementation in the Bee framework.
    \itemL{30}{36}{d+x}{\Slip} {Non-polyhedral extension}{0.0:7.0:13.0}
      Final release taking into account the feedbacks from the 
      demonstrator \STs.
   \end{livrable}

\end{workpackage}