Changeset 33 for anr/section-3.2.tex


Ignore:
Timestamp:
Jan 14, 2010, 5:31:54 PM (15 years ago)
Author:
coach
Message:

Paul: des petites améliorations
M anr/section-3.2.tex
M anr/section-4.1.tex

File:
1 edited

Legend:

Unmodified
Added
Removed
  • anr/section-3.2.tex

    r24 r33  
    11% les objectifs scientifiques/techniques du projet.
    2 The objectives of COACH project are to develop a complete framework to HPC
     2The objectives of the COACH project are to develop a complete framework to HPC
    33(accelerating solutions for existing software applications) and embedded
    44applications (implementing an application on a low power standalone
     
    1010\begin{description}
    1111\item[HPC setup] Here the user splits the application into 2 parts: the host application
    12 which remains on PC and the SoC application which migrates on SoC.
    13 The framework provides a simulation model allowing to evaluate the partitioning.
     12which remains on a PC and the SoC application which migrates into a SoC.
     13The framework provides a simulation model which allows an evaluation of the partitioning.
    1414\item[SoC design] In this phase,
    15 The user can obtain simulators at different abstraction levels of the SoC by giving to COACH framework
    16 a SoC description. 
     15The user can obtain simulators for the SoC at different abstraction levels by giving to the COACH framework a SoC description. 
    1716This description consists of a process network corresponding to the SoC application,
    1817an OS, an instance of a generic hardware platform
     
    2120XXXpeci (the process runs on a SoC processor enhanced with dedicated instructions),
    2221and hardware (the process runs into a coprocessor generated by HLS and plugged on the SoC bus).
    23 \item[Application compilation] Once SoC description is validated, COACH generates automatically
    24 an FPGA bitstream containing the hardware platform with SoC application software and
     22\item[Application compilation] Once the SoC description is validated, COACH generates automatically
     23an FPGA bitstream containing the hardware platform with the SoC application software and
    2524an executable containing the host application. The user can launch the application by
    26 loading the bitstream on FPGA and running the executable on PC.
     25loading the bitstream on an FPGA and running the executable on PC.
    2726\end{description}
    2827 
     
    3130The main scientific contribution of the project is to unify various synthesis techniques
    3231(same input and output formats) allowing the user to swap without engineering effort
    33 from one to an other and even to chain them, for example, to run polyedric transformation
    34 before synthesis.
     32from one to another and even to chain them. for instance, it will be possible to run polyedric transformations before synthesis.
    3533Another advantage of this framework is to provide different abstraction levels from
    3634a single description.
     
    4442\begin{itemize}
    4543\item The main problem in HPC is the communication between the PC and the SoC.
    46 This problem has 2 aspects. The first one is the efficiency. The second is to
    47 eliminate enginnering effort to implement it at different abstract levels.
    48 \item COACH design flow has a top-down approach. In the such case,
    49 the required performance of a coprocessor (run frequency, maximum cycles for
     44This 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
     45at several abstract levels.
     46\item The COACH design flow has a top-down approach. In such a case,
     47the required performance of a coprocessor (clock frequency, maximum cycles for
    5048a given computation, power consumption, etc) are imposed by the other system
    5149components. The challenge is to allow user to control accurately the synthesis
    52 process. For instance, the run frequency must not be a result of the RTL synthesis
     50process. For instance, the clock frequency must not be a result of the RTL synthesis
    5351but a strict synthesis constraint.
    5452\item HLS tools are sensitive to the style in which the algorithm is written.
     
    6664The challenge is to identify the coarse grained parallelism and to generate,
    6765from a sequential algorithm, coprocessor containing multiple communicating
    68 tasks (data-paths and FSMs).
     66tasks (data-paths and FSMs). To this aim, one may adapt techniques which
     67were developed in the 1990 for the construction of distributed programs.
     68However, in the context of HLS, there are still several original problems
     69to be solved, mainly to do with the construction of FIFO communication
     70channels and with memory optimization.
     71
    6972\end{itemize}
    7073
     
    7376%fin de projet.
    7477The main result is the framework. It is composed concretely of:
    75 2 HPC communication shemes with their implementation,
     782 HPC communication schemes with their implementation,
    76795 HLS tools (control dominated HLS, data dominated HLS, Coarse grained HLS,
    7780Memory optimisation HLS and ASIP),
Note: See TracChangeset for help on using the changeset viewer.