%\def\t{\\\hspace*{.5em}} \def\mysubsection{\subsubsection} \def\mysubsubsection#1{\subsubsection*{\underline{#1}}} \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 nos réponses par rapport aux principales faiblesses qui ont été relevée pour la précédente version de la proposition. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \mysubsection{Réponses séquentielles} % \mysubsubsection{Pertinence de la proposition au regard de l'appel à projet} Pas de faiblesse signalée. \mysubsubsection{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 système, on pourrait effectivement utiliser des outils tels que SOP C builder, mais ceux-ci ne permettent pas de faire de prototypage et ne sont pas libres et trop spécifiques à une famille d'IPs propriétaire. Nous avons donc 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 que SOCKET, TOPCASED, SPEAR-DE. COACH se positionne en effet comme une sous-partie de ces flots complets et doit être considéré comme un point tool. Cependant, dans la nouvelle version de la proposition, nous avons \textit{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} Tout 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} 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 intéressant de voir ce que de tel IP peuvent apporter au monde de la conception de systèmes embarqués. \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 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 défini section~\ref{HPC:definition} (page~\pageref{HPC:definition}); il s'agit bien d'une sur-couche du module de conception de SoC comme illustré 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 d'une carte FPGA sur le bus PCI/E du PC. Le FPGA intègrera le SoC.\\ La façon dont COACH aide l'utilisateur à isoler le moteur de calcul de l'application est expliquée dans la section~\ref{HPC:howto} (page~\pageref{HPC:howto}) et sur la figure~\ref{archi-hpc} (page~\pageref{archi-hpc}). La façon dont 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és 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{}\\ Concernant la remarque sur un positionnement du projet en \og plateforme {\fg} plutôt qu'en \og recherche industrielle \fg, nous avons considéré que l'effort devait être concentré sur les aspects techniques innovants plutôt que sur leur mise en application dans un nombre important de flots. En effet, 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. \end{description} \end{description} % \mysubsubsection{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} % \mysubsubsection{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 plupart 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 les trois plateformes cibles. \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 IEEE 1685 IP-XACT (livrable \NOVERScsgImplementation), d'une part en entrée pour faciliter la configuration de COACH sur d'autre plateforme et d'autre part en ajoutant une sortie au format IP-XACT des SoC générés pour leur intégration comme sous-système dans les flots de conception de SoC. Les livrables {\NOVERStrtSpearde} et {\NOVERSmdsAppSpecification} démontrent cette possibilité. \item[Utilisation de RTOS non industriels]\mbox{}\\ L'OS bien qu'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} % \mysubsubsection{Qualité du consortium} \begin{description} \item[Xilinx n'a pas une part assez active]\mbox{}\\ Xilinx ne fait plus partie 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} % \mysubsubsection{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. Néanmoins, la répartition financière a été complètement revue. \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} Un rôle principal de \mds tant que chef de file sera d'assurer la coordination de manière professionnelle de ce projet. \end{description} % \mysubsubsection{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} % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \mysubsection{Synthèse} % \mysubsubsection{Projet trop ambitieux} \label{trop:ambitieux} Par rapport au projet 2010, nous avons réduit la surface du projet de 20\% 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 indépendant de l'OS. L'OS bien qu'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érents 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} % \mysubsubsection{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étisable). \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 le patron architectural neutre. % \mysubsubsection{Pérennité/dissémination du projet} \label{perennite+dissemination} L’arrivée de la société Magillem Design Services dans le consortium permettra de répondre aux problèmes liés à la pérennité et la dissémination des résultats du projets. Le rôle de ce nouveau partenaire sera d’orienter les choix afin de pouvoir anticiper les besoins des futurs utilisateurs industriels de COACH. Deux versions de l’outil seront développées: \begin{itemize} \item une version libre qui sans bénéficier de l’environnement complet intégrée à Magillem (sous Eclipse), intègrera des moteurs en entrée et en sortie pour assurer la compatibilité du code généré avec un flot standard IP-XACT, \item une version complète à vocation commerciale qui pourra être personnalisée en fonctions des besoins spécifiques des futurs clients. \end{itemize} La société Magillem détient une expertise dans les flots de production des SoC car depuis plusieurs années elle a réussi avec succès à assister les leaders de ce domaine (STM, NXP, TI, Qualcomm, etc.) dans leur migration vers le standard IEEE 1685 IP-XACT. Ainsi sa présence assure que les outils développés dans COACH seront en adéquation avec les besoins correspondant à ce type de clientèle. Magillem a également dans sa clientèle des systémiers utilisateurs de FPGA (Thales, Astrium, ESA, etc.) dont les besoins sont différents qui seront considérés comme les cibles privilégiés du projet. % \mysubsubsection{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.