source: anr/annexe-reponse.tex @ 357

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

1ere Pre-release

  • Property svn:eol-style set to native
  • Property svn:keywords set to Revision HeadURL Id Date
File size: 17.8 KB
Line 
1%\def\t{\\\hspace*{.5em}}
2\def\mysubsection{\subsubsection}
3\def\mysubsubsection#1{\subsubsection*{\underline{#1}}}
4\def\t{\\{$\bullet$}~}
5\def\sectionPpageP#1{section~\ref{#1} (page~\pageref{#1})\xspace}
6\def\sectionVpage#1{section~\ref{#1}, page~\pageref{#1}\xspace}
7%
8Le projet a été soumis en 2010 au programme ARPEGE.
9Dans la premiÚre section, nous présentons nos réponses aux suggestions et
10remarques des experts en suivant l'ordre du dossier d'évaluation qui nous a été
11retourné. La seconde section, quant à elle, synthétise nos réponses par rapport
12aux principales faiblesses qui ont été relevée pour la précédente version de la
13proposition.
14%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
15\mysubsection{Réponses séquentielles}
16%
17\mysubsubsection{Pertinence de la proposition au regard de l'appel à projet}
18Pas de faiblesse signalée.
19\mysubsubsection{Qualité scientifique et technique de la proposition}
20\begin{description}
21  \item[Point 1 (\textit{non prise en compte des outils existants})]\mbox{}
22    \t%\note{O.1}
23    Pour la synthÚse de bas niveau sur FPGA, nous utiliserons intensivement
24    les environnements industriels QUARTUS \& ISE.
25    \t%\note{O.2}
26    Pour la synthÚse de systÚme, on pourrait effectivement utiliser des outils
27    tels que SOP C builder, mais ceux-ci ne permettent pas de faire de prototypage
28    et ne sont pas libres et trop spécifiques à une famille d'IPs propriétaire.
29    Nous avons donc choisi DSX/SoCLib, car il est open source, et c'est celui que
30    nous maitrisons le plus et nous savons déjà que son moteur couvre une
31    grande partie des besoins de COACH à ce niveau.
32    \t\note{INT}
33    Enfin COACH ne vise pas les flots de conception de systÚmes complexes tels
34    que SOCKET, TOPCASED, SPEAR-DE.
35    COACH se positionne en effet comme une sous-partie de ces flots complets et
36    doit être considéré comme un point tool. Cependant, dans la nouvelle
37    version de la proposition, nous avons
38    \textit{ajouté à COACH ce qui est nécessaire pour qu'il puisse
39      être intégré dans de tels environnements de conception:
40      configuration et description des SoC générés en IP-XACT}.
41    Les livrables {\NOVERStrtSpearde} et {\NOVERSmdsAppSpecification} démontrent cette
42    possibilité.
43  \item[Point 2 (\textit{pas de dimension recherche})]\mbox{}
44    \\ La dimension recherche est présente à différents niveaux de ce projet.
45    \t%\note{R.1}
46    Tout d'abord, le fait de synthétiser la même description de haut niveau soit par HLS
47    soit par ASIP, est à notre connaissance non encore réalisé à ce jour.
48    \t%\note{R.2}
49    De plus, l'utilisation de transformations polyédriques  dans des outils de HLS
50    opérationnels n'est pas courant.
51    \t%\note{R.3}
52    Les IPs courantes du marché sont des composants matériels certes génériques mais à configuration/paramétrisation limitées. COACH permettra au contraire de concevoir des IPs qui constitueront de véritables sous-systÚmes à fonctionnalités complexes et trÚs paramétrables (hardware + software), il sera
53    intéressant de voir ce que de tel IP peuvent apporter au monde de la conception de systÚmes embarqués.
54    \t%\note{R.4}
55    Les outils de conception de SoC actuels ont soit une approche matérielle
56    (sans limite sur les choix architecturaux), soit massivement parallÚle à
57    gros grain (MPSoC à mémoire cohérente). Il en résulte des systÚmes trÚs complexes nécessitant des spécialistes en
58    matériel (approche matérielle) ou en programmation parallÚle.
59    A l'opposé, dans COACH l'architecture matérielle  est simple et quasiment fixée.
60    Le moyen d'accélération est  le parallélisme à grain trÚs fin généré au sein
61    des coprocesseurs par HLS. Il en résulte que des développeurs de logiciel
62    standard pourront utiliser COACH. \\
63    La démonstration de la pertinence ou de la non pertinence de ces choix est
64   Ã  notre avis l'axe de recherche principal du projet car il impactera les orientations
65    technologiques liées à l'exploitation des plateformes matérielles de demain.
66  \item[Point 3 (\textit{lien entre HPC et SoC embarqué})]\mbox{}
67    \\ %\note{X.1}
68    Le terme HPC est employé dans de nombreux contextes et il est difficile de s'entendre sur sa définition exacte. Dans notre proposition, le terme HPC est
69    défini section~\ref{HPC:definition} (page~\pageref{HPC:definition}); il
70    s'agit bien d'une sur-couche du module de conception de SoC
71    comme illustré sur la figure~\ref{coach-flow} (page~\pageref{coach-flow}).\\
72    BriÚvement notre HPC consiste à accélérer une application existante qui
73    tourne sur un PC. Ceci est fait par:
74        1) l'isolation de moteur de calcul de l'application,
75        2) l'implantation de ce moteur dans un SoC,
76        3) l'ajout d'une carte FPGA sur le bus PCI/E du PC. Le FPGA intÚgrera le SoC.\\
77    La façon dont COACH aide l'utilisateur à isoler le moteur de calcul de l'application
78    est expliquée dans la section~\ref{HPC:howto} (page~\pageref{HPC:howto}) et
79    sur la figure~\ref{archi-hpc} (page~\pageref{archi-hpc}).
80    La façon dont l'application accélérée est générée fait l'objet de la
81    figure~\ref{coach-flow} (page~\pageref{coach-flow}).
82  \item[Autres]\mbox{}
83    \begin{description}
84      \item[État de l'art incomplet]\mbox{}
85        \\ %\note{EA}
86        Dans l'état de l'art, nous nous sommes concentrés d'une part sur les outils
87        de même niveau que COACH,
88            le HPC (\sectionVpage{soa:hpc}) et
89            la synthÚse de systÚme (\sectionVpage{soa:system:synthesis})
90        et d'autre part sur les technologies utilisées,
91            la HLS (\sectionVpage{soa:hls}),
92            l'ASIP (\sectionVpage{soa:asip}),
93            et la parallélisation automatique
94                (\sectionVpage{soa:automatic:parallelization}).
95        \\ %\note{EA}
96        Nous avions fait l'impasse sur les outils de plus haut niveau de
97        conception de SoC, ceux-ci n'étant pas directement le sujet de COACH.
98        Nous avons ajouté le chapitre
99        \og SoC design flow automation using IP-XACT{\fg}
100        (\sectionPpageP{soa:ip-xact}) pour palier ce manque.
101        \\ %\note{EA}
102        Nous sommes conscients que cet état de l'art est loin d'être complet
103        mais à notre décharge, il y a le nombre limité de pages et la grande
104        variété de domaines abordés dans ce projet.
105      \item[Articulation avec SoCLib]\mbox{}\\
106        Voir la note de marge \seenote{SL1} dans la section \ref{coach+soclib} ci-dessous.
107      \item[Pérennité à long terme du logiciel]\mbox{}\\
108        Voir la section \ref{perennite+dissemination} ci-dessous.
109      \item[Mauvais positionnement du projet]\mbox{}\\
110        Concernant la remarque sur un positionnement du projet
111        en \og plateforme {\fg} plutÃŽt qu'en \og recherche industrielle \fg,
112        nous avons considéré que l'effort devait être concentré sur les aspects
113techniques innovants plutÃŽt que sur leur mise en application dans un nombre important de flots. En
114effet, dans la nouvelle mouture, nous utilisons les résultats des projets SoCket et Topcased, avec compatibilité IP-XACT, assurant ainsi une généricité pour l'intégration dans de nombreux flots de production, sans pour autant multiplier à outrance les expérimentations dans le cadre du projet. Ainsi la taille du projet nous permet de rester en positionnement \og recherche industrielle \fg.
115    \end{description}
116\end{description}
117%
118\mysubsubsection{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\mysubsubsection{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 plupart 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 IEEE 1685 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 part en ajoutant une sortie au format IP-XACT des SoC générés pour
151    leur intégration comme sous-systÚme dans les flots de conception de SoC.
152    Les livrables {\NOVERStrtSpearde} et {\NOVERSmdsAppSpecification} démontrent cette
153    possibilité.
154  \item[Utilisation de RTOS non industriels]\mbox{}\\
155    L'OS bien qu'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\mysubsubsection{Qualité du consortium}
163\begin{description}
164    \item[Xilinx n'a pas une part assez active]\mbox{}\\
165        Xilinx ne fait plus partie 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\mysubsubsection{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. Néanmoins, la répartition financiÚre a été complÚtement revue.
179
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        Un rÃŽle principal de \mds tant que chef de file sera d'assurer la coordination de maniÚre professionnelle de ce projet.
186       
187\end{description}
188%
189\mysubsubsection{Avis Général}
190\begin{description}
191    \item[Déséquilibre entre l'ampleur du développement et les moyens]\mbox{}\\
192        Voir la section \ref{trop:ambitieux} ci-dessous.
193    \item[Doute sur la possibilité d'intégrer l'ensemble des outils existants en
194          un tout cohérent]\mbox{}\\
195        Voir la note de marge \seenote{DOU} au-dessus.
196    \item[\parbox{\linewidth}{COACH étant une continuation de SoCLib,
197           SoCLib n'étant pas une réussite industrielle $\Longrightarrow$
198           faut-il financer COACH pour donner une chance à SoCLib?}]\mbox{}\\
199        Voir la note de marge \seenote{SL3} dans la section \ref{coach+soclib} ci-dessous.
200    \item[Manque un industriel pour assurer la pérennité]\mbox{}\\
201        Voir les notes de marge \seenote{IND1} et \seenote{IND2} au-dessus.
202    \item[Justifier le positionnement comme une continuité de SoCLib]\mbox{}\\
203        La section \ref{coach+soclib} ci-dessous montre que COACH n'est pas une
204        continuité de SoCLib et cette justification est donc sans objet.
205    \item[Absence de considération pour les outils/standard industriels]\mbox{}\\
206        Voir les notes de marge \seenote{INT} et \seenote{STD} au-dessus.
207    \item[Volonté de tout refaire]\mbox{}\\
208        Voir la note de marge \seenote{REF} au-dessus.
209\end{description}
210%
211%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
212\mysubsection{SynthÚse}
213%
214\mysubsubsection{Projet trop ambitieux}
215\label{trop:ambitieux}
216Par rapport au projet 2010, nous avons réduit la surface du projet de 20\% en nous
217concentrant sur le cœur de COACH. Les principales réductions sont:
218\begin{itemize}
219  \item Suppression d'un OS:\\
220    Dans la proposition 2010, nous avions choisi 2 OS (Mutekh et DNA) pour
221    montrer que COACH était indépendant de l'OS.
222    L'OS bien qu'indispensable n'est pas une piÚce maitresse du projet.
223    En effet, on doit pouvoir passer facilement à un autre OS si ce
224    dernier supporte les thread POSIX.\\
225    \textit{Nous avons ÃŽté l'OS Mutekh}. Ceci diminue les développements systÚme
226    de moitié.
227  \item Suppression de la reconfiguration dynamique:\\
228    Dans la proposition 2010, la tâche~6 (PC/FPGA communication middleware)
229    contenait une partie importante qui consistait à partager le FPGA entre
230    plusieurs applications et charger dynamiquement certaine de ses parties
231    en fonction des applications qui tournent sur le PC.\\
232    \textit{Nous avons ÃŽté la reconfiguration dynamique}. Ceci diminue de 30 à
233    40 \% les développements de la tâche~6 et enlÚve quelques homme mois dans la
234    tache~3 (System generation).
235  \item Diminution des développements materiels:\\
236    Dans la proposition 2010, nous avions projeté 1) de prototyper les SoC des
237    différents patrons architecturaux de façon exacte, 2) d'implanter le
238    composant de communication (MWMR) pour les patrons architecturaux XILINX et ALTERA.
239    Ces choix conduisaient à 4 implantations du composants de communication
240    (MWMR) (1 VHDL MWMR/\xilinxbus, 1 VHDL MWMR/AVALON, 1 SystemC
241    MWMR/\xilinxbus et
242    1 SystemC MWMR/AVALON) et probablement à quelques autres modules SystemC.\\
243    \textit{Nous avons ÃŽté ces développements}.
244    En effet pour l'implantation matériel des patrons architecturaux, on
245    utilisera les ponts VCI/\xilinxbus et VCI/AVALON qui sont nécessaires au HPC et
246    pour le prototypage, on se limitera au patron architectural neutre.
247\end{itemize}
248%
249\mysubsubsection{Projet \& SoCLib}
250\label{coach+soclib}
251{$\bullet$}\note{SL1}
252Dans l'évaluation de la soumission 2010, les experts se posent plusieurs
253questions sur les liens entre le projet COACH et le projet ANR SoCLib.
254Pour répondre à ces questions listons les composants de SoCLib utilisés dans COACH:
255\begin{itemize}
256  \item Les descriptions SystemC de 6 composants sur environ 70.
257  \item L'explorateur de l'espace de conception DSX qui devra être étendu pour
258    supporter la génération matérielle des architectures (VHDL synthétisable).
259  \item Un OS sur cinq.
260\end{itemize}
261Cette liste montre clairement que SoCLib n'est qu'un composant logiciel parmi
262la dizaine d'autres sur les quels COACH s'appuie.
263Ce n'est pas, et de loin, le plus irremplaçable, les modÚles VHDL du patron
264architectural neutre comme les outils de synthÚse seraient bien plus difficiles
265à refaire et GCC comme les environnements QUARTUS et ISE sont absolument
266indispensables.
267\t\note{SL2}
268On ne peut donc pas dire que COACH est trop basé sur SoCLIB.
269\t\note{SL3}
270A la question posée par les experts:
271  \og faut il financer COACH pour donner une chance à SoCLib? {\fg}
272La réponse est que financer COACH n'influencera pas la vie de SoCLib,
273les 2 projets n'étant pas assez corrélés.
274D'ailleurs COACH pourrait trÚs bien survivre à une mort de SoCLib en maintenant
275les quelques composants SoCLib qu'il utilise.
276\t\note{SL4}
277Enfin une réserve concerne l'utilisation du bus VCI jugé obsolÚte via les composants
278SoCLib. Le projet prévoit le développement de pont VCI/AVALON et VCI/\xilinxbus ce qui
279permettra l'utilisation des IP de XILINX et ALTERA dans le patron architectural
280neutre.
281%
282\mysubsubsection{Pérennité/dissémination du projet}
283\label{perennite+dissemination}
284L’arrivée de la société Magillem Design Services dans le consortium permettra de
285répondre aux problÚmes liés à la pérennité et la dissémination des résultats du
286projets. Le rÃŽle de ce nouveau partenaire sera d’orienter les choix afin de
287pouvoir anticiper les besoins des futurs utilisateurs industriels de COACH.
288Deux versions de l’outil seront développées:
289\begin{itemize}
290   \item une version libre qui sans bénéficier de l’environnement complet
291   intégrée à Magillem (sous Eclipse), intÚgrera des moteurs en entrée et en
292   sortie pour assurer la compatibilité du code généré avec un flot standard
293   IP-XACT,
294   \item une version complÚte à vocation commerciale qui pourra être
295   personnalisée en fonctions des besoins spécifiques des futurs clients.
296\end{itemize}
297La société Magillem détient une expertise dans les flots de production
298des SoC car depuis plusieurs années elle a réussi avec succÚs à assister les
299leaders de ce domaine (STM, NXP, TI, Qualcomm, etc.) dans leur migration vers le
300standard IEEE 1685 IP-XACT.
301Ainsi sa présence assure que les outils développés dans COACH seront en
302adéquation avec les besoins correspondant à ce type de clientÚle.
303Magillem a également dans sa clientÚle des systémiers utilisateurs de FPGA
304(Thales, Astrium, ESA, etc.) dont les besoins sont différents qui seront
305considérés comme les cibles privilégiés du projet.
306%
307\mysubsubsection{Projet trop académique}
308\label{trop:academique}
309Le projet a été jugé trop académique. Ceci est un peu corrigé par l'arrivée de
310\mds mais l'essentiel du développement reste à la charge des partenaires
311académiques.
312Ceci s'explique par l'historique du projet qui est né de l'initiative des
313partenaires académiques.
Note: See TracBrowser for help on using the repository browser.