Index: /anr/anr.tex =================================================================== --- /anr/anr.tex (revision 37) +++ /anr/anr.tex (revision 38) @@ -32,5 +32,5 @@ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \def\Sformat#1{\begin{small}\textsc{#1}\end{small}} -\def\irisa{irisa\xspace} \def\Sirisa{\Sformat{IRI}\xspace} +\def\irisa{IRISA\xspace} \def\Sirisa{\Sformat{IRI}\xspace} \def\citi{CITI\xspace} \def\Sciti{\Sformat{CITI}\xspace} \def\lip{LIP\xspace} \def\Slip{\Sformat{LIP}\xspace} Index: /anr/section-2.1.tex =================================================================== --- /anr/section-2.1.tex (revision 37) +++ /anr/section-2.1.tex (revision 38) @@ -1,13 +1,16 @@ -Microelectronic allows the integration of complicated functions into products, to increase their -commercial attractivity and to improve their competitivity. Multimedia and communication -sectors have taken advantage from microelectronics facilities thanks to the developpment of -design methodologies and tools for real time embedded systems. Many other sectors could -benefit from microelectronics if these methologies and tools were adapted to their features. -The Non Recurring Engineering (NRE) costs involded in designing and manufacturing an ASIC is -very high. An IC foundry costs several billions of euros and the fabrication -of a specific circuit costs several millions. For example a conservative estimate for a 65nm ASIC project is 10 million USD. +Microelectronic allows the integration of complicated functions into products, increases +commercial attractivity of these products and improves their competitivity. +Multimedia and communication sectors have taken advantage from microelectronics facilities +thanks to the developpment of design methodologies and tools for real time embedded +systems. +Many other sectors could benefit from microelectronics if these methologies and tools were +adapted to their features. The Non Recurring Engineering (NRE) costs involded in designing +and manufacturing an ASIC is very high. +An IC foundry costs several billions of euros and the fabrication of a specific circuit +costs several millions. For example a conservative estimate for a 65nm ASIC project is 10 +million USD. Consequently, it is generally unfeasible to design and fabricate ASICs in low volumes and ICs are designed to cover a broad applications spectrum at the cost of -performance degradation. +some performance degradation. \\ Today, FPGAs become important actors in the computational domain that was originally dominated Index: /anr/section-2.tex =================================================================== --- /anr/section-2.tex (revision 37) +++ /anr/section-2.tex (revision 38) @@ -6,11 +6,12 @@ complexity of design problems. Such methods, addressing these challenges starting from high levels of abstraction, will have to perform large solution space explorations both for software and (possibly -reconfigurable) hrdware, involving almost marginal design effort and offering a high predictability of results -with respect to cost- and performance- objectives. +reconfigurable) hardware, reducing the design effort and offering a high predictability of results +with respect to cost and performance objectives. Current design methodologies provide quite low-level abstraction capabilities. However in a few years from now tens of programmable processors will be embedded in an IC with more than 100M -transistors adding to the complexity of the problem of designing such systems. Taking into account -that the complexity of the software part is increasing at an even faster rate, current solutions for -design space exploration, mainly manually based, by no means do supply an adequate performance. +transistors, therefore adding to the complexity of the problem of designing such systems. +Taking into account that the complexity of the software part is increasing at an even +faster rate, current solutions for design space exploration, mainly manually based, by no +means do supply an adequate efficiency. Consequently, there is an urgent need to leverage system level exploration through the use of a high level specification of the application and an early design @@ -22,16 +23,16 @@ \\ Thus, new system-level design flows need to be developed, enabling the exploration of an application -independently of the implementation, almost at the beginning of the design process. A -fundamental element of this evolution is the definition of abstraction layers that should allow the -systematic re-use of software and hardware components at the system level driven by performance estimation -and analysis. In this context, COACH will combine modeling and estimation methods and -compilers and design space exploration techniques. This approach will cause a real breakthrough in -the embedded system design methodology, i.e. one of the radical innovations. +independently of the implementation, almost at the beginning of the design process. +A fundamental element of this evolution is the definition of abstraction layers that should allow the +performance driven re-use of software and hardware components at the system level. +In this context, COACH will combine modeling and estimation methods and compilers and +design space exploration techniques. This approach will be a radical innovation in +embedded system design methodology. \\ -The reason is that COACH precedes the use of high-level design tools in the embedded -systems design flows. In that way, it will make possible a real and efficiently combined -exploitation of high-level synthesis tools, parallelising approaches and compilers, already +The reason is that the COACH framework is applied before high-level design tools in the embedded +systems design flow. In that way, it will make possible a real and efficiently combined +exploitation of high-level synthesis tools, parallelizing approaches and compilers, already available on the market. These tools and approaches are not yet massively adopted, precisely -because this decisive design step is missing. COACH will indeed permit (i) to predict and +because this preliminary design step is missing. COACH will indeed permit (i) to predict and control implementation optimizations, (ii) to target multiple implementation technologies (and thus the associated tools) from a unique specification and (iii) to efficiently integrate high @@ -43,12 +44,12 @@ a lower global cost. \par -To get an efficient embedded system, designer has to take into account -application characteristics when it chooses one of the former technologies. -This choice is not easy and in most cases designer has to try different +To get an efficient embedded system, the system designer has to take into account +application characteristics when it chooses one of the available technologies. +This choice is not easy and in most cases the designer has to try different technologies to retain the most adapted one. \\ The first objective of COACH is to provide an open-source framework to -design embedded system on FPGA device. -COACH framework allows designer to explore various software/hardware +design embedded system on FPGA devices. +The COACH framework allows the designer to explore various software/hardware partitions of the target application, to run timing and functional simulations and to generate automatically both the software and the @@ -65,5 +66,5 @@ Micro-architectural exploration: When hardware components are required, the HLS tools of the framework generate them automatically. At this stage the -framework provides various HLS tools allowing the micro-architectural space +framework provides various HLS tools that allow the micro-architectural space design exploration. The exploration criteria also are throughput, latency and power consumption. @@ -74,11 +75,11 @@ \item -Performance measurement: For each point of design space exploration, -metrics of criteria are available such as throughput, latency, power +Performance measurement: For each point in the design space, +figures of merit are available such as throughput, latency, power consumption, area, memory allocation and data locality. They are evaluated -using virtual prototyping, estimation or analysing methodologies. +using virtual prototyping, estimation or analyzing methodologies. \item -Targeted hardware technology: The COACH description of system is -independent of the FPGA family. Every point of the design exploration +Targeted hardware technology: The COACH description of a system is +independent of the FPGA family. Every point of the design space can be implemented on any FPGA having the required resources. Basically, COACH handles both Altera and Xilinx FPGA families. @@ -86,12 +87,12 @@ As an extension of embedded system design, COACH deals also with High Performance Computing (HPC). -In HPC, the kind of targeted application is an existing one running on PC. -COACH helps designer to accelerate it by migrating critical parts into a -SoC implemented on a FPGA plugged to the PC bus. +In HPC, the kind of targeted application is an existing one running on a PC. +The COACH framework helps designer to accelerate it by migrating critical parts into a +SoC implemented on an FPGA plugged to the PC bus. \par -COACH is the result of the will of several laboratory to unify their know -how and skills in the following domains: Operating system and hardware -communication (TIMA, SITI), SoC and MPSoC (LIP6 and TIMA), ASIP (IRISA) and -HLS (LIP6, Lab-STIC and LIP). +COACH is the result of the will of several laboratories to unify their knowhow +and skills in the following domains: Operating system and hardware +communication (\tima, \citi), SoC and MPSoC (\upmc and \tima), ASIP (\irisa) and +HLS (\upmc, \ubs) and compilation (\irisa, \lip). The project objective is to integrate these various domains into a unique free framework (licence ...) masking as much as possible these domains and Index: /anr/section-4.1.tex =================================================================== --- /anr/section-4.1.tex (revision 37) +++ /anr/section-4.1.tex (revision 38) @@ -48,9 +48,6 @@ The input is a single task of the process network. The HAS tools do not work directly on the C++ task description but on an internal format called -\xcoach generated by a the GNU C compiler (GCC) -%Paul: ``tainted'' ça ve dire ``souillé''. Qu'est-ce que tu veux dire -%exactement: piloté, modifié ....? -tainted by a COACH -driver. This allows on the one hand to insure that all the tools will +\xcoach generated by a plugin into the GNU C compiler (GCC). +This allows on the one hand to insure that all the tools will accept the same C++ description and on the other hand to make possible their chaining. The front-end tools read a \xcoach description and generate Index: /anr/section-4.2.tex =================================================================== --- /anr/section-4.2.tex (revision 37) +++ /anr/section-4.2.tex (revision 38) @@ -5,17 +5,16 @@ management, of the co-operation and the reporting of the progress. Each month the Task Leaders have to send to the project leader short update report with the -main high-lights, major opportunities and treats according to the work-plan. +main high-lights, major opportunities and problems according to the work-plan. Therefore, each Partner has the responsibility to monthly inform the task Leaders of the -current development of the \ST it has in charge. -COACH will be organized in 8 tasks whose interactions are presented in +current development of the \ST he has in charge. +COACH will be organized in \mustbecompleted{FIXME: 8} tasks whose interactions are presented in Figure~\ref{dependence-task}. \item[Scientific and Technical Reports] -For every yearly and half period report, milestone or deliverable, a written progress -report has to be provided by the task leader to coordinator for integration in the -contractual reports. +For every yearly review, a written progress report for each deliverable has to be +provided by the task leader to the coordinator for integration in the contractual reports. \item[Management of knowledge, Intellectual Property Right (IPR) and Results Exploitation] -The partners will have to respect to work under the NDA constraints. +The partners will have to work under the eventual NDA constraints. Prior Intellectual Property remains property of the concerned partners. The exploitation of the results obtained in the project and by each partner involved in the consortium will @@ -36,10 +35,10 @@ \end{itemize} Following the requests and the information received by the partner's representatives and -their financial and legal department, a Consortium Agreement will be realized and will +their financial and legal department, a Consortium Agreement will be written and will deal mainly with all aspects of the relationships between partners, including legal aspects, property rights and further exploitation of the results. Moreover, the management rules of the project will also be defined clearly in this major document (decision level, reporting systems, red flag cases). A first draft of this -document will be introduced to each partner during the kick-off meeting. +document will be submitted to each partner during the kick-off meeting. \item[Project follow-ups] Index: /anr/section-4.4.tex =================================================================== --- /anr/section-4.4.tex (revision 37) +++ /anr/section-4.4.tex (revision 38) @@ -19,17 +19,17 @@ \begin{description} \item[Milestone 1 ($T0+6$)] Specification of COACH inputs, of the \xcoach format and of - demonstatrors as a referennce software. + demonstatrors as a reference software. \item[Milestone 2 ($T0+12$)] The first COACH release. At this step the demonstrators are - written in COACH. The COACH release allows to prototype and to generate the FPGA-SoC. + written in the COACH input format. This COACH release allows to prototype and to generate the FPGA-SoC. The main restrictions are: 1) only the COACH architectural template is supported, - 2) HAS is not available (but prototyping with virtual coprocessor is available), - 3) Enhanced communication schems are not available. + 2) HAS is not available (but prototyping with virtual coprocessors is available), + 3) Enhanced communication schemes are not available. \item[Milestone 3 ($T0+18$)] The second COACH release. At this step most of the COACH features are availables. The main restriction is that COACH can not yet generate FPGA-SoC for ALTERA and XILINX - architectural template. + architectural templates. The others restriction is that the HAS tools are not yet fully operational. -\item[Milestone 4 ($T0+24$)] The pre-rlease of the COACH project. The full design flow is +\item[Milestone 4 ($T0+24$)] The pre-release of the COACH project. The full design flow is supported. The main restriction are: @@ -41,19 +41,21 @@ This organisation allows to advance globally the project step by step mixing development and demonstrator delivrables. -So demonstrator feed-back will arrive early and so the risk to point out incompatibility -at the integration phasis is suppressed. +Hence, demonstrator feed-back will arrive early and so the risk to point out incompatibility +at the integration phase is significantly reduced. \par The project has several critical issues: \begin{description} \item[\xcoachplus format (\novers{\specXcoachDoc}, \novers{\specXcoachToC})] - Because it bonds tightly all the HAS tools, it is a + Because all the HAS tools rely on it, it is a crucial task. There are no work-arround but as mentionned in - section~\ref{xcoach-problem} (page~\pageref{xcoach-problem}) we worked ont it since a - year and are confident. + section~\ref{xcoach-problem} (page~\pageref{xcoach-problem}) we have worked on it + for a year and are confident. \item[\xcoachplus format (\novers{\specXcoachDoc}, \novers{\specXcoachToSystemC}, \novers{\specXcoachToVhdl})] - It aims with the generation of the coprocessors (hardware \& prototyping model), - By centralizing the coprocessor generations, it guarantees their operating + Its aim is the generation of the coprocessors (hardware \& prototyping model), + By centralizing the coprocessor generation, it guarantees their operating independently of the used HAS tools. + Our experience with UGH and GAUT give us confidence in the succes of this + task. \item[prototyping of ALTERA \& XILINX architectural templates ({\csgAlteraSystemC}, {\csgXilinxSystemC}] Index: /anr/task-1.tex =================================================================== --- /anr/task-1.tex (revision 37) +++ /anr/task-1.tex (revision 38) @@ -5,6 +5,6 @@ % \begin{objectif} -This task relies to the main features for embedded system. -Its objective consists of the specification of designer input, of the +This task deals with to the main features for embedded system. +Its objective consists of the specification of the designer input, of the definition of the hardware architectural templates and of all the features that the HAS tools share. @@ -13,5 +13,5 @@ \begin{workpackage}{D1} \item This \ST specifies COACH for the system designer. At this - level COACH is a black box. The deliverables aredocuments allowing the system + level COACH is a black box. The deliverables are documents allowing the system designers to use COACH: feeding it (inputs), how to use it (design flow), what COACH can generate (definition of the generic architecture of the @@ -19,5 +19,5 @@ \begin{livrable} \item{V1}{0}{6}{d}{\Supmc}{COACH user manual} \setMacroInAuxFile{specGenManualI} - It is the first milestone of the COACH user manual that will allow demonstrator + It is the first milestone of the COACH user manual that will allow the demonstrator \STs to start. It contains the general description of the framework, the design flow and the @@ -30,11 +30,11 @@ of the demonstrator \STs. \item{V1}{0}{6}{d}{\Stima}{CSG user manual} \setMacroInAuxFile{specCsgManualI} - It is the first milestone of the CSG user manual that will allow demonstrator - \STs to start. - It describes how the task graph is described, the communication schems and its + It is the first milestone of the CSG (COACH System Generator) user manual that + will allow the demonstrator \STs to start. + It specifies how the task graph is described, the communication schemes and its associated API (Application Programming Interface). - The base is the SRL library and MWMR communication component defined by the SocLib + The base is the SRL library and the MWMR communication component defined by the SocLib ANR project. - Nevertheless, these basic schems will be enhanced to allow more efficent + Nevertheless, these basic schemes will be enhanced to allow more efficent synthesis. \item{VF}{6}{12}{d}{\Stima}{CSG user manual} \setMacroInAuxFile{specCsgManual} @@ -42,8 +42,8 @@ of the demonstrator \STs. \item{V1}{0}{6}{d}{\Subs}{HAS user manual} \setMacroInAuxFile{specHasManualI} - It is the first milestone of the HAS user manual that will allow demonstrator - \STs to start. - It describes how tasks of task graph must be written (C/C++ subset) and how - communication schems defined in the {\specCsgManual} delivrable must be described for + It is the first milestone of the HAS (Hardware Accelerator Synthesis) user manual that + will allow the demonstrator \STs to start. + It specifies how tasks must be written (C/C++ subset) and how + communication schemes defined in the {\specCsgManual} delivrable must be described for coprocessor synthesis. \item{VF}{6}{12}{d}{\Subs}{HAS user manual} \setMacroInAuxFile{specHasManual} @@ -67,9 +67,9 @@ Second release of XML specification of the \xcoach format taking into account the corrections and modifications that the - developers of HAS tools rised. + developers of HAS tools suggested. \item{VF}{12}{18}{d+x}{\Slip}{specification of \xcoach format} \setMacroInAuxFile{specXcoachDoc} Last release of XML specification of the \xcoach format enhanced with - the expression of loop potential. + the expression of loop potential parallelism. \item{V1}{6}{12}{x}{\Subs}{C++ to/from \xcoach format} \setMacroInAuxFile{specXcoachToCI} @@ -82,6 +82,6 @@ \item{VF}{12}{18}{x}{\Subs}{C++ to/from \xcoach format} \setMacroInAuxFile{specXcoachToC} - The same softwares as the former (\specXcoachToCI) but for \xcoach format defined - in the {\specXcoachDoc} deliverable and HAS input defined in the {\specHasManual} + The same softwares as the former (\specXcoachToCI) but for the \xcoach format as defined + in the {\specXcoachDoc} deliverable and HAS input as defined in the {\specHasManual} deliverable. \item{V1}{12}{18}{x}{\Supmc}{\xcoachplus format to SystemC} @@ -101,5 +101,5 @@ \end{livrable} \item Backend HLS tools use a characterized macro-cell library to build the - micro-architecture of a coprocessor. The characterisation of a cell dépends + micro-architecture of a coprocessor. The characterisation of a cell depends on the target device. The role of this \ST is to define the macro-cells and to provite a tool that characterizes them automatically by synthesizing them Index: /anr/task-2.tex =================================================================== --- /anr/task-2.tex (revision 37) +++ /anr/task-2.tex (revision 38) @@ -15,9 +15,9 @@ \item the configuration and the development of drivers of the operating systems, \item the CSG software that generates the simulators for prototiping and the FPGA-SoC system, -\item the specification of enhanced communication schems and their sofware and hardware implementation. +\item the specification of enhanced communication schemes and their sofware and hardware implementation. \end{itemize} This task being based on the SocLib platform, a first release will be delivrable at $T0+12$ to allow the demonstrators to start working. -This release will include the standard communication schems (base on SocLib MWMR component) +This release will include the standard communication schemes (base on SocLib MWMR component) and support the COACH architectural template for prototyping and hardware generation. \end{objectif} @@ -72,5 +72,5 @@ \item This \ST consists of the configuration of the SocLib MUTEK and DNA operating system and the development of drivers for the hardware architectural templates - and enhanced communication schems defined in \novers{\specCsgManual} delivrable. + and enhanced communication schemes defined in \novers{\specCsgManual} delivrable. For the ALTERA and XILINX architectural template, the OSs must also be ported on the NIOS2 and MICROBLAZE processors. @@ -93,8 +93,8 @@ % moved in task 1 %\item This \ST relies to definition and implementation of the enhanced communication -% schems usable in the definition of communicante task graph. +% schemes usable in the definition of communicante task graph. % \begin{livrable} % \item{}{0}{6}{d}{\Stima}{CSG user manual} A document that describes the CSG task -% graph inputs (task graph, task description, communication schems). +% graph inputs (task graph, task description, communication schemes). % \end{livrable} %\item This \ST relies to implementation of the MWMR component for the Xilinx and Altera Index: /anr/task-5.tex =================================================================== --- /anr/task-5.tex (revision 37) +++ /anr/task-5.tex (revision 38) @@ -11,7 +11,7 @@ \item Helping the HPC designer to find a good partition of the initial application (figure~\ref{archi-hpc}. -\item Providing communication schems between the software part runing on the PC and the +\item Providing communication schemes between the software part runing on the PC and the FPGA-SoC. -\item Implementing the communication schem at all levels: partition help, software +\item Implementing the communication scheme at all levels: partition help, software implementation both on the PC and in the operating system of the FPGA-SoC, hardware. \item FPGA reconfiguration. \mustbecompleted{FIXME:TIMA} @@ -20,10 +20,10 @@ transfers. The reasons of this choices are that both ALTERA and Xilinx provide PCI/X IP for their FPGA and that GPU HPC softwares use also it. -This will allow us at least to be inspired by GPU communication schems and may be to reuse +This will allow us at least to be inspired by GPU communication schemes and may be to reuse parts of the GPU softwares. \end{objectif} % \begin{workpackage}{D5} -\item This \ST is the definition of the communication schems as a software API +\item This \ST is the definition of the communication schemes as a software API (Application Programing Interface) between the application part running on the PC and the application part running on the FPGA-SoC.