source: anr/annexe-reponse.tex @ 320

Last change on this file since 320 was 320, checked in by coach, 14 years ago

Additions de TIMA et quelques corrections de typos

  • Property svn:eol-style set to native
  • Property svn:keywords set to Revision HeadURL Id Date
File size: 15.8 KB
Line 
1%\def\t{\\\hspace*{.5em}}
2\def\t{\\{$\bullet$}~}
3\def\sectionPpageP#1{section~\ref{#1} (page~\pageref{#1})\xspace}
4\def\sectionVpage#1{section~\ref{#1}, page~\pageref{#1}\xspace}
5%
6Le projet a été soumis en 2010 au programme ARPEGE.
7Dans la premiÚre section, nous présentons nos réponses aux suggestions et
8remarques des experts en suivant l'ordre du dossier d'évaluation qui nous a été
9retourné. La seconde section, quant à elle, synthétise ces réponses.
10%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
11\subsection{Réponses séquentielles}
12%
13\subsubsection{Pertinence de la proposition au regard de l'appel à projet}
14Pas de faiblesse signalée.
15\subsubsection{Qualité scientifique et technique de la proposition}
16\begin{description}
17  \item[Point 1 (\textit{non prise en compte des outils existants})]\mbox{}
18    \t%\note{O.1}
19    Pour la synthÚse de bas niveau sur FPGA, nous utiliserons intensivement
20    les environnements industriels QUARTUS \& ISE.
21    \t%\note{O.2}
22    Pour la synthÚse de SoC, on pourrait effectivement utiliser des outils
23    tels \mustbecompleted{XXX ou XXX}.
24    Nous avons choisi DSX/SoCLib, car il est open source, et c'est celui que
25    nous maitrisons le plus et nous savons déjà que son moteur couvre une
26    grande partie des besoins de COACH à ce niveau.
27    \t\note{INT}
28    Enfin COACH ne vise pas les flots de conception de systÚmes complexes tels
29    \mustbecompleted{SOCKET, MDA de MAGILLEM, SPEAR-DE ou XXX}.
30    Il se trouvent à un niveau bien inférieur.
31    Cependant, il est vrai que dans la micro électronique d'aujourd'hui ce
32    niveau ne peut être ignoré.
33    \textit{Nous avons ajouté à COACH ce qui est nécessaire pour qu'il puisse
34    être intégré dans de tels environnements de conception:
35    configuration et description des SoC générés en IP-XACT}.
36    Les livrables {\NOVERStrtSpearde} et {\NOVERSmdsAppSpecification} démontrent cette
37    possibilité.
38  \item[Point 2 (\textit{pas de dimension recherche})]\mbox{}
39    \\ La dimension recherche est présente à différents niveaux de ce projet.
40    \t%\note{R.1}
41    Tour d'abord, le fait de synthétiser la même description de haut niveau soit par HLS
42    soit par ASIP, est à notre connaissance non encore réalisé à ce jour.
43    \t%\note{R.2}
44    De plus, l'utilisation de transformations polyédriques  dans des outils de HLS
45    opérationnels n'est pas courant.
46    \t%\note{R.3}
47    \mustbecompleted{je ne comprends pas cet argument}
48        Les IPs sont d'abord des composants matériels génériques, COACH permettra
49    de concevoir des IPs trÚs paramétrables (hardware + software), il sera
50    intéressant de voir ce que de tel IP peuvent apporter à la micro
51    électronique.
52    \t%\note{R.4}
53    Les outils de conception de SoC actuels ont soit une approche matérielle
54    (sans limite sur les choix architecturaux), soit massivement parallÚle à
55    gros grain (MPSoC à mémoire cohérente). Il en résulte des systÚmes trÚs complexes nécessitant des spécialistes en
56    matériel (approche matérielle) ou en programmation parallÚle.
57    A l'opposé, dans COACH l'architecture matérielle  est simple et quasiment fixée.
58    Le moyen d'accélération est  le parallélisme à grain trÚs fin généré au sein
59    des coprocesseurs par HLS. Il en résulte que des développeurs de logiciel
60    standard pourront utiliser COACH. \\
61    La démonstration de la pertinence ou de la non pertinence de ces choix est
62   Ã  notre avis l'axe de recherche principal du projet car il impactera les orientations
63    technologiques liées à l'exploitation des plateformes matérielles de demain.
64  \item[Point 3 (\textit{lien entre HPC et SoC embarqué})]\mbox{}
65    \\ %\note{X.1}
66    Le HPC est un terme employé dans tant de contextes qu'il ne veut pas
67    dire grand chose de précis. Ce que nous entendons par le terme HPC est
68    spécifié section~\ref{HPC:definition} (page~\pageref{HPC:definition}) et
69    le fait que notre HPC est une sur-couche du module de conception de SoC
70    est montré sur la figure~\ref{coach-flow} (page~\pageref{coach-flow}).\\
71    BriÚvement notre HPC consiste à accélérer une application existante qui
72    tourne sur un PC. Ceci est fait par:
73        1) l'isolation de moteur de calcul de l'application,
74        2) l'implantation de ce moteur dans un SoC,
75        3) l'ajout sur le bus PCI/E du PC une carte FPGA.\\
76    Comment COACH aide l'utilisateur à isoler le moteur de calcul de l'application
77    est expliqué dans la section~\ref{HPC:howto} (page~\pageref{HPC:howto}) et
78    sur la figure~\ref{archi-hpc} (page~\pageref{archi-hpc}).
79    Comment l'application accélérée est générée fait l'objet de la
80    figure~\ref{coach-flow} (page~\pageref{coach-flow}).
81  \item[Autres]\mbox{}
82    \begin{description}
83      \item[État de l'art incomplet]\mbox{}
84        \\ %\note{EA}
85        Dans l'état de l'art, nous nous sommes concentré d'une part sur les outils
86        de même niveau que COACH,
87            le HPC (\sectionVpage{soa:hpc}) et
88            la synthÚse de systÚme (\sectionVpage{soa:system:synthesis})
89        et d'autre part sur les technologies utilisées,
90            la HLS (\sectionVpage{soa:hls}),
91            l'ASIP (\sectionVpage{soa:asip}),
92            et la parallélisation automatique
93                (\sectionVpage{soa:automatic:parallelization}).
94        \\ %\note{EA}
95        Nous avions fait l'impasse sur les outils de plus haut niveau de
96        conception de SoC, ceux-ci n'étant pas directement le sujet de COACH.
97        Nous avons ajouté le chapitre
98        \og SoC design flow automation using IP-XACT{\fg}
99        (\sectionPpageP{soa:ip-xact}) pour palier ce manque.
100        \\ %\note{EA}
101        Nous sommes conscients que cet état de l'art est loin d'être complet
102        mais à notre décharge, il y a le nombre limité de pages et la grande
103        variété de domaines abordés dans ce projet.
104      \item[Articulation avec SoCLib]\mbox{}\\
105        Voir la note de marge \seenote{SL1} dans la section \ref{coach+soclib} ci-dessous.
106      \item[Pérennité à long terme du logiciel]\mbox{}\\
107        Voir la section \ref{perennite+dissemination} ci-dessous.
108      \item[Mauvais positionnement du projet]\mbox{}\\
109        Il était mentionné qu'il aurait mieux fallu positionner le projet
110        en \og plateforme {\fg} plutÃŽt qu'en \og recherche industrielle \fg.
111        Il nous a été signifié que pour projet plateforme, il faut mieux
112        qu'il y ai plusieurs gros industriels leader.
113        Ce n'est pas le cas de ce projet, nous sommes resté en \og recherche
114        industrielle \fg.
115    \end{description}
116\end{description}
117%
118\subsubsection{Qualité de la construction de la proposition}
119\begin{description}
120  \item[Manque un industriel pour assurer la pérennité]\mbox{}\\
121        \note{IND1}
122        Il était mentionné qu'il fallait un industriel pour assurer
123        la pérennité et la dissémination du projet. \mds est entré dans
124        le consortium pour assurer ce rÃŽle.\\
125        Voyez aussi la section \ref{perennite+dissemination} ci-dessous
126        pour plus d'information.
127  \item[Trop ambitieux]\mbox{}\\
128        Voir la section \ref{trop:ambitieux} ci-dessous.
129\end{description}
130%
131\subsubsection{Impact global du projet}
132\begin{description}
133  \item[Volonté de tout refaire]\mbox{}\\
134    \note{REF}
135    Les experts mentionnent \og une volonté de tout refaire {\fg}. Il est dommage
136    qu'ils n'aient pas explicité leurs pensées. En effet le projet s'appuie sur
137    des briques existantes pour la plus part de ses composants et sur les
138    environnements QUARTUS \& ISE pour la synthÚse de bas niveau.\\
139    Les seuls composants manquants sont les composants matériels de
140    communication mais ils sont incontournables pour la réalisation du projet
141    sur les trois plateformes cibles.
142  \item[Trop gros travail de développement]\mbox{}\\
143    Voir la section \ref{trop:ambitieux} ci-dessous.
144  \item[Absence d'utilisation de standard]\mbox{}\\
145    \note{STD}
146    En effet, le projet n'utilisait pas le standard IP-XACT des flots de
147    conception de SoC. Ceci a été corrigé dans cette soumission en introduisant
148    le standard IP-XACT (livrable \NOVERScsgImplementation),
149    d'une part en entrée pour faciliter la configuration de COACH sur d'autre plateforme
150    et d'autre par en ajoutant une sortie au format IP-XACT des SoC générés pour
151    leur intégration comme IP dans d'autres outils de conception de SoC.
152    Les livrables {\NOVERStrtSpearde} et {\NOVERSmdsAppSpecification} démontrent cette
153    possibilité.
154  \item[Utilisation d'RTOS non industriels]\mbox{}\\
155    L'OS bien que indispensable n'est pas une piÚce maitresse du projet.
156    En effet, on doit pouvoir passer facilement à un autre OS si ce
157    dernier supporte les thread POSIX.
158  \item[Le projet est trop basé sur les composants SoCLib]\mbox{}\\
159    Voir la note de marge \seenote{SL2} dans la section \ref{coach+soclib} ci-dessous.
160\end{description}
161%
162\subsubsection{Qualité du consortium}
163\begin{description}
164    \item[Xilinx n'a pas une part assez active]\mbox{}\\
165        Xilinx ne fait plus parti du consortium.
166    \item[Manque un industriel pour assurer la pérennité]\mbox{}\\
167        \note{IND2}
168        Les experts suggÚrent la société \mds. \mds est entré dans le
169        consortium pour remplir ce rÃŽle.
170    \item[Pas de vision pour intégrer COACH dans un flot de conception
171          industriel]\mbox{}\\
172      Voir les notes de marge \seenote{INT} et \seenote{STD} ci-dessus.
173\end{description}
174%
175\subsubsection{Moyens humains et financiers}
176\begin{description}
177    \item[Incongruités de quelques demandes financiÚres]\mbox{}\\
178        Les experts n'ont pas précisé leurs pensées, nous ne les avons pas
179        trouvées et donc pas corrigées.
180    \item[Déséquilibre entre l'ampleur du développement et les moyens]\mbox{}\\
181        Voir la section \ref{trop:ambitieux} ci-dessous.
182    \item[Doute sur la possibilité d'intégrer l'ensemble des outils existants en
183          un tout cohérent]\mbox{}\\
184        \note{DOU}
185        Cette remarque sous entend que les académiques sont incapables de
186        concevoir, développer, maintenir de gros logiciel.
187        Cette remarque est assez tendancieuse, on peut certes trouver beaucoup
188        de projets académiques qui n'ont pas abouti mais on peut en trouver
189        encore plus du cÃŽté des industriels.
190\end{description}
191%
192\subsubsection{Avis Général}
193\begin{description}
194    \item[Déséquilibre entre l'ampleur du développement et les moyens]\mbox{}\\
195        Voir la section \ref{trop:ambitieux} ci-dessous.
196    \item[Doute sur la possibilité d'intégrer l'ensemble des outils existants en
197          un tout cohérent]\mbox{}\\
198        Voir la note de marge \seenote{DOU} au-dessus.
199    \item[\parbox{\linewidth}{COACH étant une continuation de SoCLib,
200           SoCLib n'étant pas une réussite industrielle $\Longrightarrow$
201           faut-il financer COACH pour donner une chance à SoCLib?}]\mbox{}\\
202        Voir la note de marge \seenote{SL3} dans la section \ref{coach+soclib} ci-dessous.
203    \item[Manque un industriel pour assurer la pérennité]\mbox{}\\
204        Voir les notes de marge \seenote{IND1} et \seenote{IND2} au-dessus.
205    \item[Justifier le positionnement comme une continuité de SoCLib]\mbox{}\\
206        La section \ref{coach+soclib} ci-dessous montre que COACH n'est pas une
207        continuité de SoCLib et cette justification est donc sans objet.
208    \item[Absence de considération pour les outils/standard industriels]\mbox{}\\
209        Voir les notes de marge \seenote{INT} et \seenote{STD} au-dessus.
210    \item[Volonté de tout refaire]\mbox{}\\
211        Voir la note de marge \seenote{REF} au-dessus.
212\end{description}
213%
214%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
215\subsection{SynthÚse}
216%
217\subsubsection{Projet trop ambitieux}
218\label{trop:ambitieux}
219Par rapport au projet 2010, on a grandement réduit la voilure en nous
220concentrant sur le cœur de COACH. Les principales réductions sont:
221\begin{itemize}
222  \item Suppression d'un OS:\\
223    Dans la proposition 2010, nous avions choisi 2 OS (Mutekh et DNA) pour
224    montrer que COACH était assez indépendant de l'OS. \\
225    L'OS bien que indispensable n'est pas une piÚce maitresse du projet.
226    En effet, on doit pouvoir passer facilement à un autre OS si ce
227    dernier supporte les thread POSIX.\\
228    \textit{Nous avons ÃŽté l'OS Mutekh}. Ceci diminue les développements systÚme
229    de moitié.
230  \item Suppression de la reconfiguration dynamique:\\
231    Dans la proposition 2010, la tâche~6 (PC/FPGA communication middleware)
232    contenait une partie importante qui consistait à partager le FPGA entre
233    plusieurs applications et charger dynamiquement certaine de ses parties
234    en fonction des applications qui tournent sur le PC.\\
235    \textit{Nous avons ÃŽté la reconfiguration dynamique}. Ceci diminue de 30 à
236    40 \% les développements de la tâche~6 et enlÚve quelques homme mois dans la
237    tache~3 (System generation).
238  \item Diminution des développements materiels:\\
239    Dans la proposition 2010, nous avions projeté 1) de prototyper les SoC des
240    différentes patrons architecturaux de façon exacte, 2) d'implanter le
241    composant de communication (MWMR) pour les patrons architecturaux XILINX et ALTERA.
242    Ces choix conduisaient à 4 implantations du composants de communication
243    (MWMR) (1 VHDL MWMR/\xilinxbus, 1 VHDL MWMR/AVALON, 1 SystemC
244    MWMR/\xilinxbus et
245    1 SystemC MWMR/AVALON) et probablement à quelques autres modules SystemC.\\
246    \textit{Nous avons ÃŽté ces développements}.
247    En effet pour l'implantation matériel des patrons architecturaux, on
248    utilisera les ponts VCI/\xilinxbus et VCI/AVALON qui sont nécessaires au HPC et
249    pour le prototypage, on se limitera au patron architectural neutre.
250\end{itemize}
251%
252\subsubsection{Projet \& SoCLib}
253\label{coach+soclib}
254{$\bullet$}\note{SL1}
255Dans l'évaluation de la soumission 2010, les experts se posent plusieurs
256questions sur les liens entre le projet COACH et le projet ANR SoCLib.
257Pour répondre à ces questions listons les composants de SoCLib utilisés dans COACH:
258\begin{itemize}
259  \item Les descriptions SystemC de 6 composants sur environ 70.
260  \item L'explorateur de l'espace de conception DSX qui devra être étendu pour
261    supporter la génération matérielle des architectures (VHDL synthétisablé).
262  \item Un OS sur cinq.
263\end{itemize}
264Cette liste montre clairement que SoCLib n'est qu'un composant logiciel parmi
265la dizaine d'autres sur les quels COACH s'appuie.
266Ce n'est pas et de loin le plus irremplaçable, les modÚles VHDL du patron
267architectural neutre comme les outils de synthÚse seraient bien plus difficiles
268à refaire et GCC comme les environnements QUARTUS et ISE sont absolument
269indispensables.
270\t\note{SL2}
271On ne peut donc pas dire que COACH est trop basé sur SoCLIB.
272\t\note{SL3}
273A la question posée par les experts:
274  \og Faut il financer COACH pour donner une chance à SoCLib? {\fg}
275La réponse est que financer COACH n'influencera pas la vie de SoCLib,
276les 2 projets n'étant pas assez corrélés.
277D'ailleurs COACH pourrait trÚs bien survivre à une mort de SoCLib en maintenant
278les quelques composants SoCLib qu'il utilise.
279\t\note{SL4}
280Enfin une réserve concerne l'utilisation du bus VCI jugé obsolÚte via les composants
281SoCLib. Le projet prévoit le développement de pont VCI/AVALON et VCI/\xilinxbus ce qui
282permettra l'utilisation des IP de XILINX et ALTERA dans la patron architectural
283neutre.
284%
285\subsubsection{Pérennité/dissémination du projet}
286\label{perennite+dissemination}
287\mustbecompleted{EMMANUEL C'EST POUR TOI}
288%
289\subsubsection{Projet trop académique}
290\label{trop:academique}
291Le projet a été jugé trop académique. Ceci est un peu corrigé par l'arrivée de
292\mds mais l'essentiel du développement reste à la charge des partenaires
293académiques.
294Ceci s'explique par l'historique du projet qui est né de l'initiative des
295partenaires académiques.
Note: See TracBrowser for help on using the repository browser.