Changeset 33
- Timestamp:
- Jan 14, 2010, 5:31:54 PM (15 years ago)
- Location:
- anr
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
anr/section-3.2.tex
r24 r33 1 1 % les objectifs scientifiques/techniques du projet. 2 The objectives of COACH project are to develop a complete framework to HPC2 The objectives of the COACH project are to develop a complete framework to HPC 3 3 (accelerating solutions for existing software applications) and embedded 4 4 applications (implementing an application on a low power standalone … … 10 10 \begin{description} 11 11 \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 onSoC.13 The framework provides a simulation model allowing to evaluatethe partitioning.12 which remains on a PC and the SoC application which migrates into a SoC. 13 The framework provides a simulation model which allows an evaluation of the partitioning. 14 14 \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. 15 The user can obtain simulators for the SoC at different abstraction levels by giving to the COACH framework a SoC description. 17 16 This description consists of a process network corresponding to the SoC application, 18 17 an OS, an instance of a generic hardware platform … … 21 20 XXXpeci (the process runs on a SoC processor enhanced with dedicated instructions), 22 21 and 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 automatically24 an FPGA bitstream containing the hardware platform with SoC application software and22 \item[Application compilation] Once the SoC description is validated, COACH generates automatically 23 an FPGA bitstream containing the hardware platform with the SoC application software and 25 24 an executable containing the host application. The user can launch the application by 26 loading the bitstream on FPGA and running the executable on PC.25 loading the bitstream on an FPGA and running the executable on PC. 27 26 \end{description} 28 27 … … 31 30 The main scientific contribution of the project is to unify various synthesis techniques 32 31 (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. 32 from one to another and even to chain them. for instance, it will be possible to run polyedric transformations before synthesis. 35 33 Another advantage of this framework is to provide different abstraction levels from 36 34 a single description. … … 44 42 \begin{itemize} 45 43 \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 to47 eliminate enginnering effort to implement it at differentabstract levels.48 \item COACH design flow has a top-down approach. In the suchcase,49 the required performance of a coprocessor ( runfrequency, maximum cycles for44 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 45 at several abstract levels. 46 \item The COACH design flow has a top-down approach. In such a case, 47 the required performance of a coprocessor (clock frequency, maximum cycles for 50 48 a given computation, power consumption, etc) are imposed by the other system 51 49 components. The challenge is to allow user to control accurately the synthesis 52 process. For instance, the runfrequency must not be a result of the RTL synthesis50 process. For instance, the clock frequency must not be a result of the RTL synthesis 53 51 but a strict synthesis constraint. 54 52 \item HLS tools are sensitive to the style in which the algorithm is written. … … 66 64 The challenge is to identify the coarse grained parallelism and to generate, 67 65 from a sequential algorithm, coprocessor containing multiple communicating 68 tasks (data-paths and FSMs). 66 tasks (data-paths and FSMs). To this aim, one may adapt techniques which 67 were developed in the 1990 for the construction of distributed programs. 68 However, in the context of HLS, there are still several original problems 69 to be solved, mainly to do with the construction of FIFO communication 70 channels and with memory optimization. 71 69 72 \end{itemize} 70 73 … … 73 76 %fin de projet. 74 77 The main result is the framework. It is composed concretely of: 75 2 HPC communication s hemes with their implementation,78 2 HPC communication schemes with their implementation, 76 79 5 HLS tools (control dominated HLS, data dominated HLS, Coarse grained HLS, 77 80 Memory optimisation HLS and ASIP), -
anr/section-4.1.tex
r23 r33 12 12 \end{figure} 13 13 % 14 The figures~\ref{archi-csg}, \ref{archi-hls} and \ref{archi-hpc}15 summarize the software architecture of COACH framework we plan to develop.14 Figures~\ref{archi-csg}, \ref{archi-hls} and \ref{archi-hpc} 15 summarize the software architecture of the COACH framework we plan to develop. 16 16 In figures, the dotted boxes are the softwares or formats that COACH 17 17 has to provide. … … 48 48 The input is a single task of the process network. The HAS tools do not work 49 49 directly on the C++ task description but on an internal format called 50 \xcoach generated by a the GNU C compiler (GCC) tainted by a COACH 50 \xcoach generated by a the GNU C compiler (GCC) 51 %Paul: ``tainted'' ça ve dire ``souillé''. Qu'est-ce que tu veux dire 52 %exactement: piloté, modifié ....? 53 tainted by a COACH 51 54 driver. This allows on the one hand to insure that all the tools will 52 55 accept the same C++ description and on the other hand to make possible … … 69 72 is done through \verb!CSG! (figure~\ref{archi-csg}). 70 73 \vspace*{.75ex}\par 71 The project is split tedinto 8 tasks numbered from 0 to 7.74 The project is split into 8 tasks numbered from 0 to 7. 72 75 The first task (task 0) is the project management, the last one (task 7) is 73 76 the dissemination the other task are listed below: … … 95 98 both PC and FPGA-SoC sides, the hardware communication components. 96 99 \item\textbf{Demonstrators:} 97 This task groups the demo strators of the COACH project.100 This task groups the demonstrators of the COACH project. 98 101 \mustbecompleted{FIXME} 99 102 \end{enumerate} … … 122 125 \item $T7$ and $T0$ respectively depends on and impacts all the other tasks. 123 126 \end{itemize} 124 So this organisation offers enough robustness for insure the success of the 125 project except for the specification task $T1$. However, the partners meet 126 10 times (a one day meeting per month) during the last years to prepare the 127 specification and the project proposal. 127 This organisation offers enough robustness to insure the success of the 128 project except for the specification task $T1$. 129 130 The only critical task in this chart is T1. 131 132 However, the partners met 133 10 times (a one day meeting per month) during the last year to prepare the 134 specification and the project proposal. This gives us a degree of confidence 135 that T1 will be completed in time.
Note: See TracChangeset
for help on using the changeset viewer.