source: anr/section-3.2.tex @ 33

Last change on this file since 33 was 33, checked in by coach, 15 years ago

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

File size: 5.3 KB
RevLine 
[12]1% les objectifs scientifiques/techniques du projet.
[33]2The objectives of the COACH project are to develop a complete framework to HPC
[20]3(accelerating solutions for existing software applications) and embedded
4applications (implementing an application on a low power standalone
[24]5device).  The design steps are presented figure~\ref{coach-flow}.
[12]6\begin{figure}[hbtp]\leavevmode\center
7  \includegraphics[width=.8\linewidth]{flow}
[20]8  \caption{\label{coach-flow} COACH flow}
[12]9\end{figure}
10\begin{description}
11\item[HPC setup] Here the user splits the application into 2 parts: the host application
[33]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.
[12]14\item[SoC design] In this phase,
[33]15The user can obtain simulators for the SoC at different abstraction levels by giving to the COACH framework a SoC description. 
[12]16This description consists of a process network corresponding to the SoC application,
17an OS, an instance of a generic hardware platform
18and a mapping of processes on the platform components. The supported mapping are
19software (the process runs on a SoC processor),
20XXXpeci (the process runs on a SoC processor enhanced with dedicated instructions),
21and hardware (the process runs into a coprocessor generated by HLS and plugged on the SoC bus).
[33]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
[12]24an executable containing the host application. The user can launch the application by
[33]25loading the bitstream on an FPGA and running the executable on PC.
[12]26\end{description}
27 
28% l'avancee scientifique attendue. Preciser l'originalite et le caractere
29% ambitieux du projet.
30The main scientific contribution of the project is to unify various synthesis techniques
31(same input and output formats) allowing the user to swap without engineering effort
[33]32from one to another and even to chain them. for instance, it will be possible to run polyedric transformations before synthesis.
[12]33Another advantage of this framework is to provide different abstraction levels from
34a single description.
35Finally, this description is device family independent and its hardware implementation
36is automatically generated.
37
38% Detailler les verrous scientifiques et techniques a lever par la realisation du projet.
39System design is a very complicated task and in this project we try to simplify it
40as much as possible. For this purpose we have to deal with the following scientific
41and technological barriers.
42\begin{itemize}
43\item The main problem in HPC is the communication between the PC and the SoC.
[33]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
[12]48a given computation, power consumption, etc) are imposed by the other system
49components. The challenge is to allow user to control accurately the synthesis
[33]50process. For instance, the clock frequency must not be a result of the RTL synthesis
[12]51but a strict synthesis constraint.
52\item HLS tools are sensitive to the style in which the algorithm is written.
53In addition, they are are not integrated into an architecture and system
54exploration tool.
55Consequently, engineering work is required to swap from a tool to another,
56to integrate the resulting simulation model to an architectural exploration tool
57and to synthesize the generated RTL description.
58%CA Additionnal preprocessing, source-level transformations, are thus
59%CA required to improve the process.
60%CA Particularly, this includes parallelism exposure and efficient memory mapping.
61\item Most HLS tools translate a sequential algorithm into a coprocessor
62containing a single data-path and finite state machine (FSM). In this way,
63only the fine grained parallelism is exploited (ILP parallelism).
64The challenge is to identify the coarse grained parallelism and to generate,
65from a sequential algorithm, coprocessor containing multiple communicating
[33]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
[12]72\end{itemize}
73
74%Presenter les resultats escomptes en proposant si possible des criteres de reussite
75%et d'evaluation adaptes au type de projet, permettant d'evaluer les resultats en
76%fin de projet.
77The main result is the framework. It is composed concretely of:
[33]782 HPC communication schemes with their implementation,
[12]795 HLS tools (control dominated HLS, data dominated HLS, Coarse grained HLS,
80Memory optimisation HLS and ASIP),
813 systemC based virtual prototyping environment extended with synthesizable
82RTL IP cores (generic, ALTERA/NIOS/AVALON, XILINX/MICROBLAZE/OPB),
83one design space exploration tool,
84one operating system (OS).
85\\
86The framework fonctionality will be demonstrated with XXX-EXAMPLE1, XXX-EXAMPLE2
87and XXX-EXAMPLE3 on 4 archictures (generic/XILINX, generic/ALTERA,
88proprietary/XILINX, proprietary/ALTERA).
89
Note: See TracBrowser for help on using the repository browser.