Changes between Initial Version and Version 1 of reunion-2009-05-04

Timestamp:

Aug 24, 2009, 4:27:07 PM (16 years ago)

Author:

coach

Comment:

--

reunion-2009-05-04

@@ +1 @@
+{{{
+COMPTE RENDU DE LA REUNION DU 4 Mai 2009
+
+-----------------------------------------------------------------
+A) Informations diverses
+
+  Nom du projet
+    10 personnes ont voté:
+       1) COACH (5 voix)
+       2) FLEXSOC, SYNPHONIE, OASYS (4 voix)
+       3) OPENSOC (1 voix)
+    Il faut donc maintenant utiliser COACH et bannir "projet HLS".
+
+  Date des prochaines réunions
+    - Mardi 16 Juin
+    - Jeudi 16 Juillet
+
+-----------------------------------------------------------------
+B) Résumé de la réunion
+
+Présentation de CAIRN:
+
+     Steven Derrien a présenté CAIRN la contribution que l'IRISA propose
+  à COACH.  Cette présentation est disponible sur le site
+  http://yaka.ensiie.fr/coach.
+  L'IRISA propose d'intégrer à COACH un outil qui adapte le (ou les)
+  processeur du SoC à l'application. Le principe de cet outil est le suivant:
+    1) Détection dans le source de l'application d'instructions qui
+       permettent d'accélérer l'application.
+    2) Reécriture de l'application en remplaçant dans le code C les
+       sections de code qui correspondent aux instructions accélératrices
+       par de l'assembleur embarqué faisant référence aux instructions.
+    3) Ajout au coeur du processeur des instructions accélératrices.
+  Cette technique a été expérimentée sur NIOS, les gains en rapidité
+  allant de 10 à 300 pour cent suivant l'application. 
+
+    Cette approche bien que un peu éloignée de la HLS classique a été
+  bien accueillie par le groupe car elle entre tout à fait dans le cadre
+  primaire de COACH (la conception de SoC sur FPGA).
+
+    Il a été soulevé le problème suivant: cet outil utilise en interne
+  un autre outil Jacob qui n'est pas open source, ce qui est contraire
+  à la directive principale du projet.
+
+Présentation des formats d'entrée des outils
+
+  Les entrées des outils BEE, GAUT, SYNTOL et UGH ont été présentées.
+  Ces présentations sont disponibles sur le site http://yaka.ensiie.fr/coach.
+  
+  L'entrée de GAUT est actuellement un DFG. Toutefois le futur modèle 
+  supportera la modélisation explicite du contrôle et sera basé sur un 
+  CDFG ou un HTG (voir: http://yaka.ensiie.fr/coach/2009-04-07/hls-model.pdf). 
+  L'entrée de UGH est un CFG et celles de BEE et SYNTOL sont des AST.
+  Une longue discussion a eu lieu sur lequel des 3 formats doit servir
+  d'entrée commune aux 4 outils.
+
+  HTG:
+    - GAUT est évidemment pour une forme de CDFG / HTG.
+    - UGH doit pouvoir s'en sortir car il ne fait pas de
+      modifications, il se contente d'annoter. De plus une
+      telle structure lui permettrai dans un futur faire
+      quelques optimisations.
+    - BEE et SYNTOL ne sont pas trop chauds. En effet passer
+      du HTG à un AST est possible. Ils travaillent sur l'AST
+      initial pour fournir un AST différent en sortie. De ce fait,
+      reconstruire un HTG cohérent ne semble pas trivial.
+    - un avantage majeur des formats type CDFG/HTG est que l'on 
+      peut bénéficier des optimisations de gcc.
+
+  AST:
+   - BEE et SYNTOL sont pour.
+   - UGH doit encore pouvoir s'en sortir car l'AST n'est pas très éloigné
+     du CFG.
+   - GAUT n'est pas très partant pour les mêmes raisons HTG 3ième item.
+   - Craintes que l'on perde les optimisations de GCC.
+
+  Néanmoins il est apparu un consensus sur le fait que le compilateur
+  commun est gcc. Gcc pourrait générer un premier modèle (exprimé en XML) 
+  sur lequel travailleraient les outils amont (Syntol, Bee) et qui serait 
+  ensuite traduit en un second modèle utilisable par GAUT et UGH. Toutefois,
+  une reflexion plus profonde doit etre menée : peut on utiliser un modèle
+  commun (proche de l'AST ou d'un CDFG) ou alors les modèles intermédiaires
+  et internes de gcc tels GENERIC (entre un AST et un CDFG) ou GIMPLE
+  (dans lequel les boucles ont été transformées en if-goto, utilisation
+  des 3 address forms, procédure non mises en ligne...).
+  A voir donc à la prochaine réunion après la présentation de Dominique Heller
+  sur Gcc.
+
+-----------------------------------------------------------------
+C) Actions pour la réunion du Mardi 16 Juin
+
+  Pour tous, réfléchir au format d'entrée HTG ou AST ou CFG ou CDFG?
+
+  Dominique s'est proposé pour nous faire un compte rendu de la sortie
+  AST en XML, les modèles internes, les passes d'optimisation, les plug-in
+  et la compilation sous contraintes de GCC-4.4.
+ 
+  GRAPHITE http://gcc.gnu.org/wiki/Graphite
+
+  Pour les participants qui n'ont pas encore présentés leur
+  contribution à COACH (CITI, Alain Darte) une présentation
+  de 30 minutes est encore et toujours la bienvenue afin de nous
+  permettre d'appréhender le projet dans son ensemble.
+  
+-----------------------------------------------------------------
+
+}}}