Changeset 38


Ignore:
Timestamp:
Jan 19, 2010, 11:01:35 AM (15 years ago)
Author:
coach
Message:
 
Location:
anr
Files:
9 edited

Legend:

Unmodified
Added
Removed

  • anr/anr.tex

    r36 r38  
    3232%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    3333\def\Sformat#1{\begin{small}\textsc{#1}\end{small}}
    34 \def\irisa{irisa\xspace}    \def\Sirisa{\Sformat{IRI}\xspace}
     34\def\irisa{IRISA\xspace}    \def\Sirisa{\Sformat{IRI}\xspace}
    3535\def\citi{CITI\xspace}      \def\Sciti{\Sformat{CITI}\xspace}
    3636\def\lip{LIP\xspace}        \def\Slip{\Sformat{LIP}\xspace}

  • anr/section-2.1.tex

    r32 r38  
    1 Microelectronic allows the integration of complicated functions into products, to increase their
    2 commercial attractivity and to improve their competitivity. Multimedia and communication
    3 sectors have taken advantage from microelectronics facilities thanks to the developpment of
    4 design methodologies and tools for real time embedded systems. Many other sectors could
    5 benefit from microelectronics if these methologies and tools were adapted to their features.
    6 The Non Recurring Engineering (NRE) costs involded in designing and manufacturing an ASIC is
    7 very high. An IC foundry costs several billions of euros and the fabrication
    8 of a specific circuit costs several millions. For example a conservative estimate for a 65nm ASIC project is 10 million USD.
     1Microelectronic allows the integration of complicated functions into products, increases
     2commercial attractivity of these products and improves their competitivity.
     3Multimedia and communication sectors have taken advantage from microelectronics facilities
     4thanks to the developpment of design methodologies and tools for real time embedded
     5systems.
     6Many other sectors could benefit from microelectronics if these methologies and tools were
     7adapted to their features. The Non Recurring Engineering (NRE) costs involded in designing
     8and manufacturing an ASIC is very high.
     9An IC foundry costs several billions of euros and the fabrication of a specific circuit
     10costs several millions. For example a conservative estimate for a 65nm ASIC project is 10
     11million USD.
    912Consequently, it is generally unfeasible to design and fabricate ASICs in
    1013low volumes and ICs are designed to cover a broad applications spectrum at the cost of
    11 performance degradation.
     14some performance degradation.
    1215\\
    1316Today, FPGAs become important actors in the computational domain that was originally dominated

  • anr/section-2.tex

    r32 r38  
    66complexity of design problems. Such methods, addressing these challenges starting from high levels of
    77abstraction, will have to perform large solution space explorations both for software and (possibly
    8 reconfigurable) hrdware, involving almost marginal design effort and offering a high predictability of results
    9 with respect to cost- and performance- objectives.
     8reconfigurable) hardware, reducing the design effort and offering a high predictability of results
     9with respect to cost and performance objectives.
    1010Current design methodologies provide quite low-level abstraction capabilities. However in a few years
    1111from now tens of programmable processors will be embedded in an IC with more than 100M
    12 transistors adding to the complexity of the problem of designing such systems. Taking into account
    13 that the complexity of the software part is increasing at an even faster rate, current solutions for
    14 design space exploration, mainly manually based, by no means do supply an adequate performance.
     12transistors, therefore adding to the complexity of the problem of designing such systems.
     13Taking into account that the complexity of the software part is increasing at an even
     14faster rate, current solutions for design space exploration, mainly manually based, by no
     15means do supply an adequate efficiency.
    1516Consequently, there is an urgent need to leverage system level
    1617exploration through the use of a high level specification of the application and an early design
    … …  
    2223\\
    2324Thus, new system-level design flows need to be developed, enabling the exploration of an application
    24 independently of the implementation, almost at the beginning of the design process. A
    25 fundamental element of this evolution is the definition of abstraction layers that should allow the
    26 systematic re-use of software and hardware components at the system level driven by performance estimation
    27 and analysis. In this context, COACH will combine modeling and estimation methods and
    28 compilers and design space exploration techniques. This approach will cause a real breakthrough in
    29 the embedded system design methodology, i.e. one of the radical innovations.
     25independently of the implementation, almost at the beginning of the design process.
     26A fundamental element of this evolution is the definition of abstraction layers that should allow the
     27performance driven re-use of software and hardware components at the system level.
     28In this context, COACH will combine modeling and estimation methods and compilers and
     29design space exploration techniques. This approach will be a radical innovation in
     30embedded system design methodology.
    3031\\
    31 The reason is that COACH precedes the use of high-level design tools in the embedded
    32 systems design flows. In that way, it will make possible a real and efficiently combined
    33 exploitation of high-level synthesis tools, parallelising approaches and compilers, already
     32The reason is that the COACH framework is applied before high-level design tools in the embedded
     33systems design flow. In that way, it will make possible a real and efficiently combined
     34exploitation of high-level synthesis tools, parallelizing approaches and compilers, already
    3435available on the market. These tools and approaches are not yet massively adopted, precisely
    35 because this decisive design step is missing. COACH will indeed permit (i) to predict and
     36because this preliminary design step is missing. COACH will indeed permit (i) to predict and
    3637control implementation optimizations, (ii) to target multiple implementation technologies
    3738(and thus the associated tools) from a unique specification and (iii) to efficiently integrate high
    … …  
    4344a lower global cost.
    4445\par
    45 To get an efficient embedded system, designer has to take into account
    46 application characteristics when it chooses one of the former technologies.
    47 This choice is not easy and in most cases designer has to try different
     46To get an efficient embedded system, the system designer has to take into account
     47application characteristics when it chooses one of the available technologies.
     48This choice is not easy and in most cases the designer has to try different
    4849technologies to retain the most adapted one.
    4950\\
    5051The first objective of COACH is to provide an open-source framework to
    51 design embedded system on FPGA device.
    52 COACH framework allows designer to explore various software/hardware
     52design embedded system on FPGA devices.
     53The COACH framework allows the designer to explore various software/hardware
    5354partitions of the target application, to run timing and functional
    5455simulations and to generate automatically both the software and the
    … …  
    6566Micro-architectural exploration: When hardware components are required, the
    6667HLS tools of the framework generate them automatically. At this stage the
    67 framework provides various HLS tools allowing the micro-architectural space
     68framework provides various HLS tools that allow the micro-architectural space
    6869design exploration. The exploration criteria also are throughput, latency
    6970and power consumption.
    … …  
    7475
    7576\item
    76 Performance measurement: For each point of design space exploration,
    77 metrics of criteria are available such as throughput, latency, power
     77Performance measurement: For each point in the design space,
     78figures of merit are available such as throughput, latency, power
    7879consumption, area, memory allocation and data locality. They are evaluated
    79 using virtual prototyping, estimation or analysing methodologies.
     80using virtual prototyping, estimation or analyzing methodologies.
    8081\item
    81 Targeted hardware technology: The COACH description of system is
    82 independent of the FPGA family.  Every point of the design exploration
     82Targeted hardware technology: The COACH description of a system is
     83independent of the FPGA family.  Every point of the design
    8384space can be implemented on any FPGA having the required resources.
    8485Basically, COACH handles both Altera and Xilinx FPGA families.
    … …  
    8687As an extension of embedded system design, COACH deals also with High
    8788Performance Computing (HPC).
    88 In HPC, the kind of targeted application is an existing one running on PC.
    89 COACH helps designer to accelerate it by migrating critical parts into a
    90 SoC implemented on a FPGA plugged to the PC bus.
     89In HPC, the kind of targeted application is an existing one running on a PC.
     90The COACH framework helps designer to accelerate it by migrating critical parts into a
     91SoC implemented on an FPGA plugged to the PC bus.
    9192\par
    92 COACH is the result of the will of several laboratory to unify their know
    93 how and skills in the following domains: Operating system and hardware
    94 communication (TIMA, SITI), SoC and MPSoC (LIP6 and TIMA), ASIP (IRISA) and
    95 HLS (LIP6, Lab-STIC and LIP).
     93COACH is the result of the will of several laboratories to unify their knowhow
     94and skills in the following domains: Operating system and hardware
     95communication (\tima, \citi), SoC and MPSoC (\upmc and \tima), ASIP (\irisa) and
     96HLS (\upmc, \ubs) and compilation (\irisa, \lip).
    9697The project objective is to integrate these various domains into a unique
    9798free framework (licence ...) masking as much as possible these domains and

  • anr/section-4.1.tex

    r37 r38  
    4848The input is a single task of the process network. The HAS tools do not work
    4949directly on the C++ task description but on an internal format called
    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
    54 driver. This allows on the one hand to insure that all the tools will
     50\xcoach generated by a plugin into the GNU C compiler (GCC).
     51This allows on the one hand to insure that all the tools will
    5552accept the same C++ description and on the other hand to make possible
    5653their chaining. The front-end tools read a \xcoach description and generate

  • anr/section-4.2.tex

    r25 r38  
    55management, of the co-operation and the reporting of the progress. Each month the Task
    66Leaders have to send to the project leader short update report with the
    7 main high-lights, major opportunities and treats according to the work-plan.
     7main high-lights, major opportunities and problems according to the work-plan.
    88Therefore, each Partner has the responsibility to monthly inform the task Leaders of the
    9 current development of the \ST it has in charge.
    10 COACH will be organized in 8 tasks whose interactions are presented in
     9current development of the \ST he has in charge.
     10COACH will be organized in \mustbecompleted{FIXME: 8} tasks whose interactions are presented in
    1111Figure~\ref{dependence-task}.
    1212
    1313\item[Scientific and Technical Reports]
    14 For every yearly and half period report, milestone or deliverable, a written progress
    15 report has to be provided by the task leader to coordinator for integration in the
    16 contractual reports.
     14For every yearly review, a written progress report for each deliverable has to be
     15provided by the task leader to the coordinator for integration in the contractual reports.
    1716
    1817\item[Management of knowledge, Intellectual Property Right (IPR) and Results Exploitation]
    19 The partners will have to respect to work under the NDA constraints.
     18The partners will have to work under the eventual NDA constraints.
    2019Prior Intellectual Property remains property of the concerned partners.
    2120The exploitation of the results obtained in the project and by each partner involved in the consortium will
    … …  
    3635\end{itemize}
    3736Following the requests and the information received by the partner's representatives and
    38 their financial and legal department, a Consortium Agreement will be realized and will
     37their financial and legal department, a Consortium Agreement will be written and will
    3938deal mainly with all aspects of the relationships between partners, including legal
    4039aspects, property rights and further exploitation of the results.
    4140Moreover, the management rules of the project will also be defined clearly in this major
    4241document (decision level, reporting systems, red flag cases).  A first draft of this
    43 document will be introduced to each partner during the kick-off meeting.
     42document will be submitted to each partner during the kick-off meeting.
    4443
    4544\item[Project follow-ups]

  • anr/section-4.4.tex

    r36 r38  
    1919\begin{description}
    2020\item[Milestone 1 ($T0+6$)] Specification of COACH inputs, of the \xcoach format and of
    21     demonstatrors as a referennce software.
     21    demonstatrors as a reference software.
    2222\item[Milestone 2 ($T0+12$)] The first COACH release. At this step the demonstrators are
    23     written in COACH. The COACH release allows to prototype and to generate the FPGA-SoC.
     23    written in the COACH input format. This COACH release allows to prototype and to generate the FPGA-SoC.
    2424    The main restrictions are:
    2525    1) only the COACH architectural template is supported,
    26     2) HAS is not available (but prototyping with virtual coprocessor is available),
    27     3) Enhanced communication schems are not available.
     26    2) HAS is not available (but prototyping with virtual coprocessors is available),
     27    3) Enhanced communication schemes are not available.
    2828\item[Milestone 3 ($T0+18$)]  The second COACH release. At this step most of the COACH
    2929    features are availables.
    3030    The main restriction is that COACH can not yet generate FPGA-SoC for ALTERA and XILINX
    31     architectural template.
     31    architectural templates.
    3232    The others restriction is that the HAS tools are not yet fully operational.
    33 \item[Milestone 4 ($T0+24$)] The pre-rlease of the COACH project. The full design flow is
     33\item[Milestone 4 ($T0+24$)] The pre-release of the COACH project. The full design flow is
    3434    supported.
    3535    The main restriction are:
    … …  
    4141This organisation allows to advance globally the project step by step mixing development
    4242and demonstrator delivrables.
    43 So demonstrator feed-back will arrive early and so the risk to point out incompatibility
    44 at the integration phasis is suppressed.
     43Hence, demonstrator feed-back will arrive early and so the risk to point out incompatibility
     44at the integration phase is significantly reduced.
    4545\par
    4646The project has several critical issues:
    4747\begin{description}
    4848\item[\xcoachplus format (\novers{\specXcoachDoc}, \novers{\specXcoachToC})]
    49     Because it bonds tightly all the HAS tools, it is a
     49    Because all the HAS tools rely on it, it is a
    5050    crucial task. There are no work-arround but as mentionned in
    51     section~\ref{xcoach-problem} (page~\pageref{xcoach-problem}) we worked ont it since a
    52     year and are confident.
     51    section~\ref{xcoach-problem} (page~\pageref{xcoach-problem}) we have worked on it
     52        for a year and are confident.
    5353\item[\xcoachplus format (\novers{\specXcoachDoc},
    5454      \novers{\specXcoachToSystemC}, \novers{\specXcoachToVhdl})]
    55     It aims with the generation of the coprocessors (hardware \& prototyping model),
    56     By centralizing the coprocessor generations, it guarantees their operating
     55    Its aim is the generation of the coprocessors (hardware \& prototyping model),
     56    By centralizing the coprocessor generation, it guarantees their operating
    5757    independently of the used HAS tools.
     58        Our experience with UGH and GAUT give us confidence in the succes of this
     59        task.
    5860\item[prototyping of ALTERA \& XILINX architectural templates ({\csgAlteraSystemC},
    5961     {\csgXilinxSystemC}]

  • anr/task-1.tex

    r36 r38  
    55%
    66\begin{objectif}
    7 This task relies to the main features for embedded system.
    8 Its objective consists of the specification of designer input, of the
     7This task deals with to the main features for embedded system.
     8Its objective consists of the specification of the designer input, of the
    99definition of the hardware architectural templates and of all the features
    1010that the HAS tools share.
    … …  
    1313\begin{workpackage}{D1}
    1414\item This \ST specifies COACH for the system designer. At this
    15     level COACH is a black box. The deliverables aredocuments allowing the system
     15    level COACH is a black box. The deliverables are documents allowing the system
    1616    designers to use COACH: feeding it (inputs), how to use it (design flow),
    1717    what COACH can generate (definition of the generic architecture of the
    … …  
    1919    \begin{livrable}
    2020    \item{V1}{0}{6}{d}{\Supmc}{COACH user manual} \setMacroInAuxFile{specGenManualI}
    21         It is the first milestone of the COACH user manual that will allow demonstrator
     21        It is the first milestone of the COACH user manual that will allow the demonstrator
    2222        \STs to start.
    2323        It contains the general description of the framework, the design flow and the
    … …  
    3030        of the demonstrator \STs.
    3131    \item{V1}{0}{6}{d}{\Stima}{CSG user manual} \setMacroInAuxFile{specCsgManualI}
    32         It is the first milestone of the CSG user manual that will allow demonstrator
    33         \STs to start.
    34         It describes how the task graph is described, the communication schems and its
     32        It is the first milestone of the CSG (COACH System Generator) user manual that
     33                will allow the demonstrator \STs to start.
     34        It specifies how the task graph is described, the communication schemes and its
    3535        associated API (Application  Programming Interface).
    36         The base is the SRL library and MWMR communication component defined by the SocLib
     36        The base is the SRL library and the MWMR communication component defined by the SocLib
    3737        ANR project.
    38         Nevertheless, these basic schems will be enhanced to allow more efficent
     38        Nevertheless, these basic schemes will be enhanced to allow more efficent
    3939        synthesis.
    4040    \item{VF}{6}{12}{d}{\Stima}{CSG user manual} \setMacroInAuxFile{specCsgManual}
    … …  
    4242        of the demonstrator \STs.
    4343    \item{V1}{0}{6}{d}{\Subs}{HAS user manual} \setMacroInAuxFile{specHasManualI}
    44         It is the first milestone of the HAS user manual that will allow demonstrator
    45         \STs to start.
    46         It describes how tasks of task graph must be written (C/C++ subset) and how
    47         communication schems defined in the {\specCsgManual} delivrable must be described for
     44        It is the first milestone of the HAS (Hardware Accelerator Synthesis) user manual that
     45                will allow the demonstrator \STs to start.
     46        It specifies how tasks must be written (C/C++ subset) and how
     47        communication schemes defined in the {\specCsgManual} delivrable must be described for
    4848        coprocessor synthesis.
    4949    \item{VF}{6}{12}{d}{\Subs}{HAS user manual} \setMacroInAuxFile{specHasManual}
    … …  
    6767        Second release of XML specification of the \xcoach format
    6868        taking into account the corrections and modifications that the
    69         developers of HAS tools rised.
     69        developers of HAS tools suggested.
    7070    \item{VF}{12}{18}{d+x}{\Slip}{specification of \xcoach format}
    7171        \setMacroInAuxFile{specXcoachDoc}
    7272        Last release of XML specification of the \xcoach format enhanced with
    73         the expression of loop potential.
     73        the expression of loop potential parallelism.
    7474    \item{V1}{6}{12}{x}{\Subs}{C++ to/from \xcoach format}
    7575        \setMacroInAuxFile{specXcoachToCI}
    … …  
    8282    \item{VF}{12}{18}{x}{\Subs}{C++ to/from \xcoach format}
    8383        \setMacroInAuxFile{specXcoachToC}
    84         The same softwares as the former (\specXcoachToCI) but for \xcoach format defined
    85         in the {\specXcoachDoc} deliverable and HAS input defined in the {\specHasManual}
     84        The same softwares as the former (\specXcoachToCI) but for the \xcoach format as defined
     85        in the {\specXcoachDoc} deliverable and HAS input as defined in the {\specHasManual}
    8686        deliverable.
    8787    \item{V1}{12}{18}{x}{\Supmc}{\xcoachplus format to SystemC}
    … …  
    101101    \end{livrable}
    102102\item Backend HLS tools use a characterized macro-cell library to build the
    103     micro-architecture of a coprocessor. The characterisation of a cell dépends
     103    micro-architecture of a coprocessor. The characterisation of a cell depends
    104104    on the target device. The role of this \ST is to define the macro-cells and
    105105    to provite a tool that characterizes them automatically by synthesizing them

  • anr/task-2.tex

    r36 r38  
    1515\item the configuration and the development of drivers of the operating systems,
    1616\item the CSG software that generates the simulators for prototiping and the FPGA-SoC system,
    17 \item the specification of enhanced communication schems and their sofware and hardware implementation.
     17\item the specification of enhanced communication schemes and their sofware and hardware implementation.
    1818\end{itemize}
    1919This task being based on the SocLib platform, a first release will be delivrable at $T0+12$
    2020to allow the demonstrators to start working.
    21 This release will include the standard communication schems (base on SocLib MWMR component)
     21This release will include the standard communication schemes (base on SocLib MWMR component)
    2222and support the COACH architectural template for prototyping and hardware generation.
    2323\end{objectif}
    … …  
    7272\item This \ST consists of the configuration of the SocLib MUTEK and DNA operating
    7373    system and the development of drivers for the hardware architectural templates
    74     and enhanced communication schems defined in \novers{\specCsgManual} delivrable.
     74    and enhanced communication schemes defined in \novers{\specCsgManual} delivrable.
    7575    For the ALTERA and XILINX architectural template, the OSs must also be ported on
    7676    the NIOS2 and MICROBLAZE processors.
    … …  
    9393% moved in task 1
    9494%\item This \ST relies to definition and implementation of the enhanced communication
    95 %    schems usable in the definition of communicante task graph.
     95%    schemes usable in the definition of communicante task graph.
    9696%    \begin{livrable}
    9797%    \item{}{0}{6}{d}{\Stima}{CSG user manual} A document that describes the CSG task
    98 %        graph inputs (task graph, task description, communication schems).
     98%        graph inputs (task graph, task description, communication schemes).
    9999%    \end{livrable}
    100100%\item This \ST relies to implementation of the MWMR component for the Xilinx and Altera

  • anr/task-5.tex

    r36 r38  
    1111\item Helping the HPC designer to find a good partition of the initial application
    1212    (figure~\ref{archi-hpc}.
    13 \item Providing communication schems between the software part runing on the PC and the
     13\item Providing communication schemes between the software part runing on the PC and the
    1414FPGA-SoC.
    15 \item Implementing the communication schem at all levels: partition help, software
     15\item Implementing the communication scheme at all levels: partition help, software
    1616implementation both on the PC and in the operating system of the FPGA-SoC, hardware.
    1717\item FPGA reconfiguration. \mustbecompleted{FIXME:TIMA}
    … …  
    2020transfers. The reasons of this choices are that both ALTERA and Xilinx provide PCI/X IP for
    2121their FPGA and that GPU HPC softwares use also it.
    22 This will allow us at least to be inspired by GPU communication schems and may be to reuse
     22This will allow us at least to be inspired by GPU communication schemes and may be to reuse
    2323parts of the GPU softwares.
    2424\end{objectif}
    2525%
    2626\begin{workpackage}{D5}
    27 \item This \ST is the definition of the communication schems as a software API
     27\item This \ST is the definition of the communication schemes as a software API
    2828    (Application Programing Interface) between the application part running on the PC and
    2929    the application part running on the FPGA-SoC.
Note: See TracChangeset for help on using the changeset viewer.