%\def\t{\\\hspace*{.5em}}
\def\t{\\{$\bullet$}~}
\def\sectionPpageP#1{section~\ref{#1} (page~\pageref{#1})\xspace}
\def\sectionVpage#1{section~\ref{#1}, page~\pageref{#1}\xspace}
%
Le projet a Ã©tÃ© soumis en 2010 au programme ARPEGE.
Dans la premiÃšre section, nous prÃ©sentons nos rÃ©ponses aux suggestions et
remarques des experts en suivant l'ordre du dossier d'Ã©valuation qui nous a Ã©tÃ©
retournÃ©. La seconde section, quant Ã  elle, synthÃ©tise ces rÃ©ponses.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{RÃ©ponses sÃ©quentielles}
%
\subsubsection{Pertinence de la proposition au regard de l'appel Ã  projet}
Pas de faiblesse signalÃ©e.
\subsubsection{QualitÃ© scientifique et technique de la proposition}
\begin{description}
  \item[Point 1 (\textit{non prise en compte des outils existants})]\mbox{}
    \t%\note{O.1}
    Pour la synthÃšse de bas niveau sur FPGA, nous utiliserons intensivement
    les environnements industriels QUARTUS \& ISE.
    \t%\note{O.2}
    Pour la synthÃšse de SoC, on pourrait effectivement utiliser des outils
    tels \mustbecompleted{XXX ou XXX}.
    Nous avons choisi DSX/SoCLib, car il est open source, et c'est celui que
    nous maitrisons le plus et nous savons dÃ©jÃ  que son moteur couvre une
    grande partie des besoins de COACH Ã  ce niveau. 
    \t\note{INT}
    Enfin COACH ne vise pas les flots de conception de systÃšmes complexes tels
    \mustbecompleted{SOCKET, MDA de MAGILLEM, SPEAR-DE ou XXX}.
    Il se trouvent Ã  un niveau bien infÃ©rieur.
    Cependant, il est vrai que dans la micro Ã©lectronique d'aujourd'hui ce
    niveau ne peut Ãªtre ignorÃ©.
    \textit{Nous avons ajoutÃ© Ã  COACH ce qui est nÃ©cessaire pour qu'il puisse
    Ãªtre intÃ©grÃ© dans de tels environnements de conception:
    configuration et description des SoC gÃ©nÃ©rÃ©s en IP-XACT}.
    Les livrables {\NOVERStrtSpearde} et {\NOVERSmdsAppSpecification} dÃ©montrent cette
    possibilitÃ©.
  \item[Point 2 (\textit{pas de dimension recherche})]\mbox{}
    \\ La dimension recherche est présente Ã  différents niveaux de ce projet.
    \t%\note{R.1}
    Tour d'abord, le fait de synthÃ©tiser la mÃªme description de haut niveau soit par HLS
    soit par ASIP, est Ã  notre connaissance non encore rÃ©alisÃ© Ã  ce jour.
    \t%\note{R.2}
    De plus, l'utilisation de transformations polyÃ©driques  dans des outils de HLS
    opÃ©rationnels n'est pas courant.
    \t%\note{R.3}
    \mustbecompleted{je ne comprends pas cet argument}
	Les IPs sont d'abord des composants matÃ©riels gÃ©nÃ©riques, COACH permettra
    de concevoir des IPs trÃšs paramÃ©trables (hardware + software), il sera
    intÃ©ressant de voir ce que de tel IP peuvent apporter Ã  la micro
    Ã©lectronique.
    \t%\note{R.4}
    Les outils de conception de SoC actuels ont soit une approche matÃ©rielle
    (sans limite sur les choix architecturaux), soit massivement parallÃšle Ã 
    gros grain (MPSoC Ã  mÃ©moire cohÃ©rente). Il en rÃ©sulte des systÃšmes trÃšs complexes nÃ©cessitant des spÃ©cialistes en
    matÃ©riel (approche matÃ©rielle) ou en programmation parallÃšle.
    A l'opposÃ©, dans COACH l'architecture matÃ©rielle  est simple et quasiment fixÃ©e.
    Le moyen d'accÃ©lÃ©ration est  le parallÃ©lisme Ã  grain trÃšs fin gÃ©nÃ©rÃ© au sein
    des coprocesseurs par HLS. Il en rÃ©sulte que des dÃ©veloppeurs de logiciel
    standard pourront utiliser COACH. \\
    La dÃ©monstration de la pertinence ou de la non pertinence de ces choix est
    Ã notre avis l'axe de recherche principal du projet car il impactera les orientations
    technologiques liées à l'exploitation des plateformes matérielles de demain.
  \item[Point 3 (\textit{lien entre HPC et SoC embarquÃ©})]\mbox{}
    \\ %\note{X.1}
    Le HPC est un terme employÃ© dans tant de contextes qu'il ne veut pas
    dire grand chose de prÃ©cis. Ce que nous entendons par le terme HPC est
    spÃ©cifiÃ© section~\ref{HPC:definition} (page~\pageref{HPC:definition}) et
    le fait que notre HPC est une sur-couche du module de conception de SoC
    est montrÃ© sur la figure~\ref{coach-flow} (page~\pageref{coach-flow}).\\
    BriÃšvement notre HPC consiste Ã  accÃ©lÃ©rer une application existante qui
    tourne sur un PC. Ceci est fait par:
        1) l'isolation de moteur de calcul de l'application,
        2) l'implantation de ce moteur dans un SoC,
        3) l'ajout sur le bus PCI/E du PC une carte FPGA.\\
    Comment COACH aide l'utilisateur Ã  isoler le moteur de calcul de l'application
    est expliquÃ© dans la section~\ref{HPC:howto} (page~\pageref{HPC:howto}) et
    sur la figure~\ref{archi-hpc} (page~\pageref{archi-hpc}).
    Comment l'application accÃ©lÃ©rÃ©e est gÃ©nÃ©rÃ©e fait l'objet de la
    figure~\ref{coach-flow} (page~\pageref{coach-flow}).
  \item[Autres]\mbox{}
    \begin{description}
      \item[Ã‰tat de l'art incomplet]\mbox{}
        \\ %\note{EA}
        Dans l'Ã©tat de l'art, nous nous sommes concentrÃ© d'une part sur les outils
        de mÃªme niveau que COACH,
            le HPC (\sectionVpage{soa:hpc}) et
            la synthÃšse de systÃšme (\sectionVpage{soa:system:synthesis})
        et d'autre part sur les technologies utilisÃ©es,
            la HLS (\sectionVpage{soa:hls}),
            l'ASIP (\sectionVpage{soa:asip}),
            et la parallÃ©lisation automatique
                (\sectionVpage{soa:automatic:parallelization}).
        \\ %\note{EA}
        Nous avions fait l'impasse sur les outils de plus haut niveau de
        conception de SoC, ceux-ci n'Ã©tant pas directement le sujet de COACH.
        Nous avons ajoutÃ© le chapitre
        \og SoC design flow automation using IP-XACT{\fg}
        (\sectionPpageP{soa:ip-xact}) pour palier ce manque.
        \\ %\note{EA}
        Nous sommes conscients que cet Ã©tat de l'art est loin d'Ãªtre complet
        mais Ã  notre dÃ©charge, il y a le nombre limitÃ© de pages et la grande
        variÃ©tÃ© de domaines abordÃ©s dans ce projet.
      \item[Articulation avec SoCLib]\mbox{}\\
        Voir la note de marge \seenote{SL1} dans la section \ref{coach+soclib} ci-dessous.
      \item[PÃ©rennitÃ© Ã  long terme du logiciel]\mbox{}\\
        Voir la section \ref{perennite+dissemination} ci-dessous.
      \item[Mauvais positionnement du projet]\mbox{}\\
        Il Ã©tait mentionnÃ© qu'il aurait mieux fallu positionner le projet
        en \og plateforme {\fg} plutÃŽt qu'en \og recherche industrielle \fg.
        Il nous a Ã©tÃ© signifiÃ© que pour projet plateforme, il faut mieux
        qu'il y ai plusieurs gros industriels leader.
        Ce n'est pas le cas de ce projet, nous sommes restÃ© en \og recherche
        industrielle \fg.
    \end{description}
\end{description}
%
\subsubsection{QualitÃ© de la construction de la proposition}
\begin{description}
  \item[Manque un industriel pour assurer la pÃ©rennitÃ©]\mbox{}\\
        \note{IND1}
        Il Ã©tait mentionnÃ© qu'il fallait un industriel pour assurer
        la pÃ©rennitÃ© et la dissÃ©mination du projet. \mds est entrÃ© dans
        le consortium pour assurer ce rÃŽle.\\
        Voyez aussi la section \ref{perennite+dissemination} ci-dessous
        pour plus d'information.
  \item[Trop ambitieux]\mbox{}\\
        Voir la section \ref{trop:ambitieux} ci-dessous.
\end{description}
%
\subsubsection{Impact global du projet}
\begin{description}
  \item[VolontÃ© de tout refaire]\mbox{}\\
    \note{REF}
    Les experts mentionnent \og une volontÃ© de tout refaire {\fg}. Il est dommage
    qu'ils n'aient pas explicitÃ© leurs pensÃ©es. En effet le projet s'appuie sur
    des briques existantes pour la plus part de ses composants et sur les
    environnements QUARTUS \& ISE pour la synthÃšse de bas niveau.\\
    Les seuls composants manquants sont les composants matÃ©riels de
    communication mais ils sont incontournables pour la rÃ©alisation du projet
    sur le les trois plateforme cible.
  \item[Trop gros travail de dÃ©veloppement]\mbox{}\\
    Voir la section \ref{trop:ambitieux} ci-dessous.
  \item[Absence d'utilisation de standard]\mbox{}\\
    \note{STD}
    En effet, le projet n'utilisait pas le standard IP-XACT des flots de
    conception de SoC. Ceci a Ã©tÃ© corrigÃ© dans cette soumission en introduisant
    le standard IP-XACT (livrable \NOVERScsgImplementation),
    d'une part en entrÃ©e pour faciliter la configuration de COACH sur d'autre plateforme
    et d'autre par en ajoutant une sortie au format IP-XACT des SoC gÃ©nÃ©rÃ©s pour
    leur intÃ©gration comme IP dans d'autres outils de conception de SoC.
    Les livrables {\NOVERStrtSpearde} et {\NOVERSmdsAppSpecification} dÃ©montrent cette
    possibilitÃ©.
  \item[Utilisation d'RTOS non industriels]\mbox{}\\
    L'OS bien que indispensable n'est pas une piÃšce maitresse du projet.
    En effet, on doit pouvoir passer facilement Ã  un autre OS si ce
    dernier supporte les thread POSIX.
  \item[Le projet est trop basÃ© sur les composants SoCLib]\mbox{}\\
    Voir la note de marge \seenote{SL2} dans la section \ref{coach+soclib} ci-dessous.
\end{description}
%
\subsubsection{QualitÃ© du consortium}
\begin{description}
    \item[Xilinx n'a pas une part assez active]\mbox{}\\
        Xilinx ne fait plus parti du consortium.
    \item[Manque un industriel pour assurer la pÃ©rennitÃ©]\mbox{}\\
        \note{IND2}
        Les experts suggÃšrent la sociÃ©tÃ© \mds. \mds est entrÃ© dans le
        consortium pour remplir ce rÃŽle.
    \item[Pas de vision pour intÃ©grer COACH dans un flot de conception
          industriel]\mbox{}\\
      Voir les notes de marge \seenote{INT} et \seenote{STD} ci-dessus.
\end{description}
%
\subsubsection{Moyens humains et financiers}
\begin{description}
    \item[IncongruitÃ©s de quelques demandes financiÃšres]\mbox{}\\
        Les experts n'ont pas prÃ©cisÃ© leurs pensÃ©es, nous ne les avons pas
        trouvÃ©es et donc pas corrigÃ©es.
    \item[DÃ©sÃ©quilibre entre l'ampleur du dÃ©veloppement et les moyens]\mbox{}\\
        Voir la section \ref{trop:ambitieux} ci-dessous.
    \item[Doute sur la possibilitÃ© d'intÃ©grer l'ensemble des outils existants en
          un tout cohÃ©rent]\mbox{}\\
        \note{DOU}
        Cette remarque sous entend que les acadÃ©miques sont incapables de
        concevoir, dÃ©velopper, maintenir de gros logiciel.
        Cette remarque est assez tendancieuse, on peut certes trouver beaucoup
        de projets acadÃ©miques qui n'ont pas abouti mais on peut en trouver
        encore plus du cÃŽtÃ© des industriels.
\end{description}
%
\subsubsection{Avis GÃ©nÃ©ral}
\begin{description}
    \item[DÃ©sÃ©quilibre entre l'ampleur du dÃ©veloppement et les moyens]\mbox{}\\
        Voir la section \ref{trop:ambitieux} ci-dessous.
    \item[Doute sur la possibilitÃ© d'intÃ©grer l'ensemble des outils existants en
          un tout cohÃ©rent]\mbox{}\\
        Voir la note de marge \seenote{DOU} au-dessus.
    \item[\parbox{\linewidth}{COACH Ã©tant une continuation de SoCLib,
           SoCLib n'Ã©tant pas une rÃ©ussite industrielle $\Longrightarrow$
           faut-il financer COACH pour donner une chance Ã  SoCLib?}]\mbox{}\\
        Voir la note de marge \seenote{SL3} dans la section \ref{coach+soclib} ci-dessous.
    \item[Manque un industriel pour assurer la pÃ©rennitÃ©]\mbox{}\\
        Voir les notes de marge \seenote{IND1} et \seenote{IND2} au-dessus.
    \item[Justifier le positionnement comme une continuitÃ© de SoCLib]\mbox{}\\
        La section \ref{coach+soclib} ci-dessous montre que COACH n'est pas une
        continuitÃ© de SoCLib et cette justification est donc sans objet.
    \item[Absence de considÃ©ration pour les outils/standard industriels]\mbox{}\\
        Voir les notes de marge \seenote{INT} et \seenote{STD} au-dessus.
    \item[VolontÃ© de tout refaire]\mbox{}\\
        Voir la note de marge \seenote{REF} au-dessus.
\end{description}
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{SynthÃšse}
%
\subsubsection{Projet trop ambitieux}
\label{trop:ambitieux}
Par rapport au projet 2010, on a grandement rÃ©duit la voilure en nous
concentrant sur le cÅ“ur de COACH. Les principales rÃ©ductions sont:
\begin{itemize}
  \item Suppression d'un OS:\\
    Dans la proposition 2010, nous avions choisi 2 OS (Mutekh et DNA) pour
    montrer que COACH Ã©tait assez indÃ©pendant de l'OS. \\
    L'OS bien que indispensable n'est pas une piÃšce maitresse du projet.
    En effet, on doit pouvoir passer facilement Ã  un autre OS si ce
    dernier supporte les thread POSIX.\\
    \textit{Nous avons ÃŽtÃ© l'OS Mutekh}. Ceci diminue les dÃ©veloppements systÃšme
    de moitiÃ©.
  \item Suppression de la reconfiguration dynamique:\\
    Dans la proposition 2010, la tÃ¢che~6 (PC/FPGA communication middleware)
    contenait une partie importante qui consistait Ã  partager le FPGA entre
    plusieurs applications et charger dynamiquement certaine de ses parties
    en fonction des applications qui tournent sur le PC.\\
    \textit{Nous avons ÃŽtÃ© la reconfiguration dynamique}. Ceci diminue de 30 Ã 
    40 \% les dÃ©veloppements de la tÃ¢che~6 et enlÃšve quelques homme mois dans la
    tache~3 (System generation).
  \item Diminution des dÃ©veloppements materiels:\\
    Dans la proposition 2010, nous avions projetÃ© 1) de prototyper les SoC des
    diffÃ©rentes patrons architecturaux de faÃ§on exacte, 2) d'implanter le
    composant de communication (MWMR) pour les patrons architecturaux XILINX et ALTERA.
    Ces choix conduisaient Ã  4 implantations du composants de communication
    (MWMR) (1 VHDL MWMR/\xilinxbus, 1 VHDL MWMR/AVALON, 1 SystemC
    MWMR/\xilinxbus et
    1 SystemC MWMR/AVALON) et probablement Ã  quelques autres modules SystemC.\\
    \textit{Nous avons ÃŽtÃ© ces dÃ©veloppements}.
    En effet pour l'implantation matÃ©riel des patrons architecturaux, on
    utilisera les ponts VCI/\xilinxbus et VCI/AVALON qui sont nÃ©cessaires au HPC et
    pour le prototypage, on se limitera au patron architectural neutre.
\end{itemize}
%
\subsubsection{Projet \& SoCLib}
\label{coach+soclib}
{$\bullet$}\note{SL1}
Dans l'Ã©valuation de la soumission 2010, les experts se posent plusieurs
questions sur les liens entre le projet COACH et le projet ANR SoCLib.
Pour rÃ©pondre Ã  ces questions listons les composants de SoCLib utilisÃ©s dans COACH:
\begin{itemize}
  \item Les descriptions SystemC de 6 composants sur environ 70.
  \item L'explorateur de l'espace de conception DSX qui devra Ãªtre Ã©tendu pour
    supporter la gÃ©nÃ©ration matÃ©rielle des architectures (VHDL synthÃ©tisablÃ©).
  \item Un OS sur cinq.
\end{itemize}
Cette liste montre clairement que SoCLib n'est qu'un composant logiciel parmi
la dizaine d'autres sur les quels COACH s'appuie.
Ce n'est pas et de loin le plus irremplaÃ§able, les modÃšles VHDL du patron
architectural neutre comme les outils de synthÃšse seraient bien plus difficiles
Ã  refaire et GCC comme les environnements QUARTUS et ISE sont absolument
indispensables.
\t\note{SL2}
On ne peut donc pas dire que COACH est trop basÃ© sur SoCLIB.
\t\note{SL3}
A la question posÃ©e par les experts:
  \og Faut il financer COACH pour donner une chance Ã  SoCLib? {\fg}
La rÃ©ponse est que financer COACH n'influencera pas la vie de SoCLib,
les 2 projets n'Ã©tant pas assez corrÃ©lÃ©s.
D'ailleurs COACH pourrait trÃšs bien survivre Ã  une mort de SoCLib en maintenant
les quelques composants SoCLib qu'il utilise.
\t\note{SL4}
Enfin une rÃ©serve concerne l'utilisation du bus VCI jugÃ© obsolÃšte via les composants
SoCLib. Le projet prÃ©voit le dÃ©veloppement de pont VCI/AVALON et VCI/\xilinxbus ce qui
permettra l'utilisation des IP de XILINX et ALTERA dans la patron architectural
neutre.
%
\subsubsection{PÃ©rennitÃ©/dissÃ©mination du projet}
\label{perennite+dissemination}
\mustbecompleted{EMMANUEL C'EST POUR TOI}
%
\subsubsection{Projet trop acadÃ©mique}
\label{trop:academique}
Le projet a Ã©tÃ© jugÃ© trop acadÃ©mique. Ceci est un peu corrigÃ© par l'arrivÃ©e de
\mds mais l'essentiel du dÃ©veloppement reste Ã  la charge des partenaires
acadÃ©miques.
Ceci s'explique par l'historique du projet qui est nÃ© de l'initiative des
partenaires acadÃ©miques.
