Index: /anr-2010/.project
===================================================================
--- /anr-2010/.project (revision 274)
+++ /anr-2010/.project (revision 274)
@@ -0,0 +1,22 @@
+
+
+ anr
+
+
+
+
+
+ net.sourceforge.texlipse.builder.TexlipseBuilder
+
+
+
+
+ fr.irisa.triskell.kermeta.kpm.kpmBuilder
+
+
+
+
+
+ net.sourceforge.texlipse.builder.TexlipseNature
+
+
Index: /anr-2010/.texlipse
===================================================================
--- /anr-2010/.texlipse (revision 274)
+++ /anr-2010/.texlipse (revision 274)
@@ -0,0 +1,13 @@
+#TeXlipse project settings
+#Wed Nov 25 18:13:04 CET 2009
+builderNum=2
+outputDir=
+makeIndSty=
+bibrefDir=
+outputFormat=pdf
+tempDir=
+mainTexFile=anr.tex
+outputFile=anr.pdf
+langSpell=
+markDer=true
+srcDir=
Index: /anr-2010/Makefile
===================================================================
--- /anr-2010/Makefile (revision 274)
+++ /anr-2010/Makefile (revision 274)
@@ -0,0 +1,53 @@
+# set here all the sources files
+# required to build anr.pdf
+SOURCES= anr.tex anr.bib section-1.tex \
+ section-2.tex section-2.1.tex section-2.2.tex \
+ flow.pdf section-3.1.tex section-3.2.tex \
+ task-0.tex task-1.tex task-2.tex task-3.tex \
+ task-4.tex task-5.tex task-6.tex \
+ section-4.1.tex section-4.4.tex \
+ architecture-csg.pdf architecture-hls.pdf architecture-hpc.pdf \
+ dependence-task-h.pdf \
+ section-4.2.tex section-5.tex \
+ section-6.1.tex section-6.2.tex section-7.tex
+
+TABLES= table_upmc_full.tex table_upmc_short.tex \
+ table_tima_full.tex table_tima_short.tex \
+ table_inria_cairn_full.tex table_inria_cairn_short.tex \
+ table_inria_compsys_full.tex table_inria_compsys_short.tex \
+ table_ubs_full.tex table_ubs_short.tex \
+ table_xilinx_full.tex table_xilinx_short.tex \
+ table_bull_full.tex table_bull_short.tex \
+ table_thales_full.tex table_thales_short.tex \
+ table_zied_full.tex table_zied_short.tex \
+ table_navtel_full.tex table_navtel_short.tex \
+ table_livrable_01.tex table_livrable_02.tex
+
+# PROGRAMS
+FIG2DEV = fig2dev
+
+%.pdf: %.fig
+ @echo "Converting $< to $@"
+ @$(FIG2DEV) -L pdf -p aaa $< $@
+
+anr.pdf: $(SOURCES) gantt1.tex gantt2.tex gantt $(TABLES)
+ @echo "Generating pdf file"
+ @pdflatex anr.tex || true
+ @bibtex anr
+ @./gantt < anr.gantt
+ @pdflatex anr.tex
+ @pdflatex anr.tex
+ @grep ndefine anr.log
+
+anr.bbl:anr.aux anr.bib
+ bibtex anr || true
+
+anr.aux gantt1.tex gantt2.tex $(TABLES):
+ touch $@
+
+gantt: gantt.l
+ @flex gantt.l && gcc -g lex.yy.c -o gantt
+ @rm lex.yy.c
+
+clean:
+ rm -f $(TABLES) anr.aux gantt1.tex gantt2.tex anr.pdf anr.gantt
Index: /anr-2010/README
===================================================================
--- /anr-2010/README (revision 274)
+++ /anr-2010/README (revision 274)
@@ -0,0 +1,20 @@
+Pour generer le document:
+ $ make
+ou + sur
+ $ rm anr.pdf ; make
+
+Pour enlever les annotations anr ou les mustbecompleted
+ il suffit de commenter les macro dans la section CONFIG
+ de anr.tex
+
+Les anciens fichiers sont dans obsoletes.
+
+
+******** GENERATION AUTOMATIQUE DES TABLES BUDGETAIRES********
+Pour remplir automatiquement les tables budgetaires short et full,
+il faut renseigner soit le champ itemL s'il s'agit d'un délivrable
+ \itemL{mois_debut_livrable}{mois_fin}{rien}{\Smonentité}{Description courte du livrable}{cout 1année:2A:3A}
+ par ex: \itemL{6}{36}{}{\Supmc}{release handling}{1:.5:.5}
+soit rajouter un champ cout hors délivrable
+ \CoutHorsD{mois_debut_livrable}{mois_fin}{\Smonentité}{Description courte du cout}{cout 1année:2A:3A}
+ par ex: \CoutHorsD{6}{36}{\Stima}{dissemination}{0:2:2}
Index: /anr-2010/anr.bib
===================================================================
--- /anr-2010/anr.bib (revision 274)
+++ /anr-2010/anr.bib (revision 274)
@@ -0,0 +1,693 @@
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%% LIP6
+% HPC
+@InProceedings{hpc06a,
+ author = {{M.B. Gokhale and al.}},
+ title = {{Promises and Pitfalls of Reconfigurable Supercomputing}},
+ booktitle = {Systems and Algorithms, CSREA Press},
+ pages = {11-20},
+ year = {2006},
+}
+@MISC{hpc06b,
+ author = {{D. Buell}},
+ title = {{Programming Reconfigurable Computers}},
+ booktitle = {Summer Institute},
+ howpublished = {http://gladiator.ncsa.uiuc.edu/PDFs/rssi06/presentations/00\_Duncan\_Buell.pdf},
+ year = {2006},
+}
+@InProceedings{hpc07a,
+ author = {{T. Van Court and al.}},
+ title = {{ Achieving High Performance with FPGA-Based Computing}},
+ booktitle = {Computer, vol. 40, no. 3},
+ pages = {50-57},
+ month = {mars},
+ year = {2007},
+}
+@misc{hpc08,
+ title = {Mitrionics},
+ howpublished = {http://www.mitrionics.com/},
+ year = {2009},
+}
+@misc{hpc09,
+ title = {Gidel},
+ howpublished = {http://www.gidel.com/},
+ year = {2009},
+}
+@misc{hpc10,
+ title = {Convey Computer},
+ howpublished = {http://www.conveycomputers.com/},
+ year = {2009},
+}
+@InProceedings{hpc11,
+ author = {E. El-Araby, I. Gonzalez and T. El-Ghazawi},
+ title = {Virtual Architecture and Design Automation for Partial Reconfiguration },
+ booktitle = {HPRCTA},
+ year = {2008},
+}
+@InProceedings{hpc12,
+ author = {{P. Lysaght and J. Dunlop}},
+ title = {Dynamic Reconfiguration of Field Programmable Gate Arrays},
+ booktitle = {Field Programmable Logic and Applications, Oxford, England},
+ month = {Sept},
+ year = {1993},
+}
+
+
+% System design
+@misc{soclib,
+ title = {Soclib},
+ howpublished = {http://www.soclib.fr/},
+ year = {2009},
+}
+
+@misc{system-generateur-for-dsp,
+ title = {{System Generator for DSP}},
+ howpublished = {http://www.xilinx.com/tools/sysgen.htm},
+ year = {2009},
+}
+
+@misc{spoc-builder,
+ title = {{sopc builder support}},
+ howpublished = {http://www.altera.com/support/software/system/sopc/sof-sopc\_builder.html},
+ year = {2009},
+}
+
+@InProceedings{cosy,
+ author = { J.Y Brunel, al },
+ title = { COSY: a methodology for system design based on reusable hardware \& software IP's},
+ booktitle = { Technologies for the Information Society },
+ publisher = { IOS Press },
+ year = {1998},
+ pages = {709-716},
+}
+
+@InProceedings{disydent05,
+ author = {{Ivan Aug\'{e}, Fr\'{e}d\'{e}ric P\'{e}trot, Franï¿œois Donnet and Pascal Gomez}},
+ title = {{Platform-based design from parallel C specifications}},
+ booktitle = {IEEE Transaction on CAD of Integrated Circuits and Systems},
+ pages = {1811--1826},
+ month = {December},
+ year = {2005},
+}
+@inproceedings{dspin08,
+ author = {Miro-Panades, Ivan and Clermidy, Fabien and Vivet, Pascal and Greiner, Alain},
+ title = {Physical Implementation of the DSPIN Network-on-Chip in the FAUST Architecture},
+ booktitle = {NOCS '08: Proceedings of the Second ACM/IEEE International Symposium on Networks-on-Chip},
+ year = {2008},
+ isbn = {978-0-7695-3098-7},
+ pages = {139--148},
+ publisher = {IEEE Computer Society},
+ address = {Washington, DC, USA},
+ }
+
+
+% HLS
+% http://mesl.ucsd.edu/spark/index.shtml
+@INBOOK{spark04,
+ author = {S. Gupta and al.},
+ title = {SPARK: A Parallelizing Approach to the High-Level Synthesis of Digital Circuits},
+ publisher = {Springer},
+ year = {2004},
+}
+
+
+@INBOOK{ugh08,
+ author = {Ivan Aug\'{e} and Fr\'{e}d\'{e}ric P\'{e}trot},
+ title = {User Guided High Level Synthesis},
+ booktitle = {High-Level Synthesis: From Algorithm to Digital Circuits},
+ publisher = {Springer},
+ chapter = {10},
+ year = {2008},
+}
+
+@misc{pico,
+ title = {{PICO}},
+ howpublished = {http://www.synfora.com/},
+ year = {2009},
+}
+
+@misc{catapult-c,
+ title = {{CATAPULT-C Mentor HLS tool}},
+ howpublished = {http://www.mentor.com/products/esl/high\_level\_synthesis/},
+ year = {2009},
+}
+
+@misc{cynthetizer,
+ title = {{Forte's CYNTHESIZER}},
+ howpublished = {http://www.forteds.com/},
+ year = {2009},
+}
+
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%% UBS
+
+@INBOOK{IEEEDT,
+author = {Philippe Coussy and Andres Takach},
+title = {Special Issue on High-Level Synthesis},
+journal ={IEEE Design and Test of Computers},
+volume = {25},issn = {0740-7475},
+year = {2008},
+pages = {393},doi = {http://doi.ieeecomputersociety.org/10.1109/MDT.2008.147},
+publisher = {IEEE Computer Society},
+address = {Los Alamitos, CA, USA},}
+
+
+@INBOOK{HLSBOOK,
+ author = {P. Coussy and A. Morawiec},
+ booktitle = {High-Level Synthesis: From Algorithm to Digital Circuits},
+ publisher = {Springer},
+ year = {2008},
+}
+
+@INBOOK{CATRENE,
+ author = {CATRENE, Cluster for Application and Technology Research in Europe on NanotElectronics},
+ booktitle = {European Roadmap for EDA},
+ publisher = {CATRENE, Cluster for Application and Technology Research in Europe on NanotElectronics},
+ year = {2009},
+}
+
+@INBOOK{gaut08,
+ author = {P. Coussy and al.},
+ title = {GAUT: A High-Level Synthesis Tool for DSP applications},
+ booktitle = {High-Level Synthesis: From Algorithm to Digital Circuits},
+ publisher = {Springer},
+ year = {2008},
+}
+
+@article{DBLP:journals/dt/CoussyT09,
+ author = {Philippe Coussy and
+ Andres Takach},
+ title = {Guest Editors' Introduction: Raising the Abstraction Level
+ of Hardware Design},
+ journal = {IEEE Design {\&} Test of Computers},
+ volume = {26},
+ number = {4},
+ year = {2009},
+ pages = {4-6},
+ ee = {http://doi.ieeecomputersociety.org/10.1109/MDT.2009.80},
+ bibsource = {DBLP, http://dblp.uni-trier.de}
+}
+
+
+@article{DBLP:journals/dt/CoussyGMT09,
+ author = {Philippe Coussy and
+ Daniel D. Gajski and
+ Michael Meredith and
+ Andres Takach},
+ title = {An Introduction to High-Level Synthesis},
+ journal = {IEEE Design {\&} Test of Computers},
+ volume = {26},
+ number = {4},
+ year = {2009},
+ pages = {8-17},
+ ee = {http://doi.ieeecomputersociety.org/10.1109/MDT.2009.69},
+ bibsource = {DBLP, http://dblp.uni-trier.de}
+}
+
+
+@article{DBLP:journals/vlsisp/ThabetCHM09,
+ author = {Farhat Thabet and
+ Philippe Coussy and
+ Dominique Heller and
+ Eric Martin},
+ title = {Exploration and Rapid Prototyping of DSP Applications using
+ SystemC Behavioral Simulation and High-level Synthesis},
+ journal = {Signal Processing Systems},
+ volume = {56},
+ number = {2-3},
+ year = {2009},
+ pages = {167-186},
+ ee = {http://dx.doi.org/10.1007/s11265-008-0235-1},
+ bibsource = {DBLP, http://dblp.uni-trier.de}
+}
+
+
+
+@inproceedings{CHAVET:2007:HAL-00153994:1,
+ title = { {A} {M}ethodology for {E}fficient {S}pace-{T}ime {A}dapter {D}esign {S}pace {E}xploration: {A} {C}ase {S}tudy of an {U}ltra {W}ide {B}and {I}nterleaver},
+ author = {{C}havet, {C}yrille and {C}oussy, {P}hilippe and {U}rard, {P}ascal and {M}artin, {E}ric},
+ abstract = {{T}his paper presents a solution to efficiently explore the design space of communication adapters. {I}n most digital signal processing ({DSP}) applications, the overall architecture of the system is significantly affected by communication architecture, so the designers need specifically optimized adapters. {B}y explicitly modeling these communications within an effective graph-theoretic model and analysis framework, we automatically generate an optimized architecture, named {S}pace-{T}ime {A}dapte{R} ({STAR}). {O}ur design flow inputs a {C} description of {I}nput/{O}utput data scheduling, and user requirements (throughput, latency, parallelism...), and formalizes communication constraints through a {R}esource {C}onstraints {G}raph ({RCG}). {T}he {RCG} properties enable an efficient architecture space exploration in order to synthesize a {STAR} component. {T}he proposed approach has been tested to design an industrial data mixing block example: an {U}ltra-{W}ideband interleaver.},
+ language = {{A}nglais},
+ affiliation = {{L}aboratoire d'{E}lectronique des {S}yst{\`e}mes {TE}mps {R}{\'e}el - {LESTER} - {CNRS} : {FRE}2734 - {U}niversit{\'e} de {B}retagne {S}ud - {STM}icroelectronics - {STM} - {STM}icroelectronics },
+ booktitle = {{P}roceedings of the {IEEE} {I}nternational {S}ymposium on {C}ircuits and {S}ystems ({ISCAS}) {T}he {IEEE} {I}nternational {S}ymposium on {C}ircuits and {S}ystems ({ISCAS}) },
+ publisher = {{L}ibrary of {C}ongress },
+ pages = {2946 },
+ address = {{N}ew {O}rleans {\'E}tats-{U}nis d'{A}m{\'e}rique },
+ editor = {{IEEE} },
+ note = {{ISBN}:1-4244-0921-7 },
+ audience = {internationale },
+ day = {28},
+ month = {05},
+ year = {2007},
+ URL = {http://hal.archives-ouvertes.fr/hal-00153994/en/},
+ URL = {http://hal.archives-ouvertes.fr/hal-00153994/PDF/ISCAS_Chavet1992.pdf},
+}
+
+
+@inproceedings{DBLP:conf/iccad/ChavetACCJUM07,
+ author = {Cyrille Chavet and
+ Caaliph Andriamisaina and
+ Philippe Coussy and
+ Emmanuel Casseau and
+ Emmanuel Juin and
+ Pascal Urard and
+ Eric Martin},
+ title = {A design flow dedicated to multi-mode architectures for
+ DSP applications},
+ booktitle = {ICCAD},
+ year = {2007},
+ pages = {604-611},
+ ee = {http://doi.acm.org/10.1145/1326073.1326199},
+ crossref = {DBLP:conf/iccad/2007},
+ bibsource = {DBLP, http://dblp.uni-trier.de}
+}
+
+
+@inproceedings{DBLP:conf/glvlsi/ChavetCUM07,
+ author = {Cyrille Chavet and
+ Philippe Coussy and
+ Pascal Urard and
+ Eric Martin},
+ title = {A design methodology for space-time adapter},
+ booktitle = {ACM Great Lakes Symposium on VLSI},
+ year = {2007},
+ pages = {347-352},
+ ee = {http://doi.acm.org/10.1145/1228784.1228868},
+ crossref = {DBLP:conf/glvlsi/2007},
+ bibsource = {DBLP, http://dblp.uni-trier.de}
+}
+
+
+@inproceedings{CHAVET:2007:HAL-00154025:1,
+ title = { {A}pplication of a design space exploration tool to enhance interleaver generation},
+ author = {{C}havet, {C}yrille and {C}oussy, {P}hilippe and {U}rard, {P}ascal and {M}artin, {E}ric},
+ abstract = {{T}his paper presents a methodology to efficiently explore the design space of communication adapters. {I}n most digital signal processing ({DSP}) applications, the overall performance of the system is significantly affected by communication architectures, as a consequence the designers need specifically optimized adapters. {B}y explicitly modeling these communications within an effective graph-theoretic model and analysis framework, we automatically generate an optimized architecture, named {S}pace-{T}ime {A}dapte{R} ({STAR}). {O}ur design flow inputs a {C} description of {I}nput/{O}utput data scheduling, and user requirements (throughput, latency, parallelism...), and formalizes communication constraints through a {R}esource {C}onstraints {G}raph ({RCG}). {D}esign space exploration is then performed through associated tools, to synthesize a {STAR} component under time-to-market constraints. {T}he proposed approach has been tested to design an industrial data mixing block example: an {U}ltra-{W}ideband interleaver.},
+ language = {{A}nglais},
+ affiliation = {{L}aboratoire d'{E}lectronique des {S}yst{\`e}mes {TE}mps {R}{\'e}el - {LESTER} - {CNRS} : {FRE}2734 - {U}niversit{\'e} de {B}retagne {S}ud - {STM}icroelectronics - {STM} - {STM}icroelectronics },
+ booktitle = {{P}roceedings of the {E}uropean {S}ignal {P}rocessing {C}onference ({EUSIPCO}-2007) {E}uropean {S}ignal {P}rocessing {C}onference ({EUSIPCO}-2007) },
+ publisher = {{E}urasip },
+ pages = {??? },
+ address = {{P}oznan {P}ologne },
+ audience = {internationale },
+ day = {03},
+ month = {09},
+ year = {2007},
+ URL = {http://hal.archives-ouvertes.fr/hal-00154025/en/},
+ URL = {http://hal.archives-ouvertes.fr/hal-00154025/PDF/EUSIPCO_chavet.pdf},
+}
+
+
+@inproceedings{ANDRIAMISAINA:2007:HAL-00153086:1,
+ title = { {S}ynthesis of {M}ultimode digital signal processing systems},
+ author = {{A}ndriamisaina, {C}aaliph and {C}asseau, {E}mmanuel and {C}oussy, {P}hilippe},
+ abstract = {{I}n this paper, we propose a design methodology for implementing a multimode (or multi-configuration) and multi-throughput system into a single hardware architecture. {T}he inputs of the design flow are the data flow graphs ({DFG}s), representing the different modes (i.e. the different applications to be implemented), with their respective throughput constraints. {W}hile traditional approaches merge {DFG}s together before the synthesis process, we propose to use ad-hoc scheduling and binding steps during the synthesis of each {DFG}. {T}he scheduling, which assigns operations to specific time steps, maximizes the similarity between the control steps and thus decreases the controller complexity. {T}he binding process, which assigns operations to specific functional units and data to specific storage elements, maximizes the similarity between datapaths and thus minimizes steering logic and register overhead. {F}irst results show the interest of the proposed synthesis flow.},
+ language = {{A}nglais},
+ affiliation = {{L}aboratoire d'{E}lectronique des {S}yst{\`e}mes {TE}mps {R}{\'e}el - {LESTER} - {CNRS} : {FRE}2734 - {U}niversit{\'e} de {B}retagne {S}ud - {R}2{D}2 - {INRIA} - {IRISA} - {CNRS} : {UMR}6074 - {INRIA} - {I}nstitut {N}ational des {S}ciences {A}ppliqu{\'e}es de {R}ennes - {E}cole {N}ationale {S}up{\'e}rieure des {S}ciences {A}ppliqu{\'e}es et de {T}echnologie - {U}niversit{\'e} de {R}ennes 1 },
+ booktitle = {{P}roceeding of {A}daptive {H}ardware and {S}ystems {NASA}/{ESA} {C}onference on {A}daptive {H}ardware and {S}ystems },
+ publisher = {{AHS} },
+ pages = {7 },
+ address = {{E}dinburgh {R}oyaume-{U}ni },
+ audience = {internationale },
+ year = {2007},
+ URL = {http://hal.archives-ouvertes.fr/hal-00153086/en/},
+ URL = {http://hal.archives-ouvertes.fr/hal-00153086/PDF/PID411805.pdf},
+}
+
+
+@inproceedings{COUSSY:2005:HAL-00077301:1,
+ title = { {A} {M}ore {E}fficient and {F}lexible {DSP} {D}esign {F}low from {MATLAB}-{SIMULINK}},
+ author = {{C}oussy, {P}hilippe and {C}orre, {G}wenol{\'e} and {B}omel, {P}ierre and {S}enn, {E}ric and {M}artin, {E}ric},
+ abstract = {{T}he design of complex {D}igital {S}ignal {P}rocessing systems implies to minimize architectural cost and to maximize timing performances while taking into account communication and memory accesses constraints for the integration of dedicated hardware accelerator. {U}nfortunately, the traditional {M}atlab/{S}imulink design flows gather not very flexible hardware blocs. {I}n this paper, we present a methodology and a tool that permit the {H}igh-{L}evel {S}ynthesis of {DSP} applications, under both {I}/{O} timing and memory constraints. {B}ased on formal models and a generic architecture, this tool helps the designer in finding a reasonable trade-off between the circuit's latency and its architectural complexity. {T}he efficiency of our approach is demonstrated on the case study of a {FFT} algorithm.},
+ keywords = {{DSP} application, synthesis under memory and communication constraints},
+ language = {{A}nglais},
+ affiliation = {{L}aboratoire d'{E}lectronique des {S}yst{\`e}mes {TE}mps {R}{\'e}el - {LESTER} - {CNRS} : {FRE}2734 - {U}niversit{\'e} de {B}retagne {S}ud },
+ booktitle = {{IEEE} {I}nternational {C}onference on {A}coustic, {S}peech and {S}ignal {P}rocessing },
+ publisher = {{IEEE} },
+ pages = {{V}ol. {V} p. 61-64 },
+ editor = {{IEEEE} },
+ year = {2005},
+ URL = {http://hal.archives-ouvertes.fr/hal-00077301/en/},
+ URL = {http://hal.archives-ouvertes.fr/hal-00077301/PDF/coussy_final.pdf},
+}
+
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%% IRISA
+@InProceedings{KluterCodes08,
+ author = {{Theo Kluter and Philip Brisk and Paolo Ienne and and Edoardo Charbon}},
+ title = {{Speculative DMA for Architecturally Visible Storage in Instruction Set Extensions}},
+ booktitle = {ISSS/CODES},
+ year = {2008},
+}
+
+@InProceedings{KluterDAC09,
+ author = {{Theo Kluter and Philip Brisk and Paolo Ienne and and Edoardo Charbon}},
+ title = {{Way Stealing : Cache-assisted Automatic Instruction Set Extensions}},
+ booktitle = {Design Automation Conference (DAC)},
+ year = {2009},
+}
+
+@InProceedings{YuCodes04,
+ author = {{Pan Yu and Tulika Mitra}},
+ title = {{Scalable Custom Instructions Identification for Instruction Set Extensible Processors}},
+ booktitle = {ISSS/CODES},
+ year = {2004},
+}
+
+@InProceedings{Dinh08,
+ author = {{Quang Dinh and Deming Chen and Martin D.~F.~Wong}},
+ title = {{Efficient ASIP Design for Configurable Processors with Fine-Grained Resource Sharing}},
+ booktitle = {ACM Internatibnal Conference Field Programmable Gate Arrays (FPGA)},
+ year = {2008},
+}
+
+@Misc{NIOS2UG,
+ title = {{Nios II Custom Instruction User Guide, Altera Corp.}},
+ year = {2008},
+}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%% CITI
+@book{Polis,
+ author = {Balarin, Felice},
+ publisher = {Kluwer Academic Publishers},
+ title = {Hardware-software co-design of embedded systems : the POLIS
+ approach},
+ year = {1997}
+}
+
+@INPROCEEDINGS{Coware,
+ author = {Ivo Bolsens and Hugo J. De Man and Bill Lin and Karl Van
+ Rompaey and Steven Vercauteren and Diederik Verkest},
+ title = {Hardware/Software Co-Design of Digital Telecommunication Systems},
+ booktitle = {Proceedings of the IEEE},
+ year = {1997},
+ pages = {391--418}
+}
+
+@article{Jantsch,
+ author = {Mattias O'Nil and Axel Jantsch},
+ title = {Device Driver and DMA Controller Synthesis from HW/SW
+ Communication protocol specifications},
+ journal = {Design Automation for Embedded Systems},
+ year = {2001},
+ volume = {6},
+ pages = {177-205}
+}
+
+@InProceedings{Park01,
+ author = {Joonseok Park and Pedro C.~Diniz},
+ title = {Synthesis of Pipelined Memory Access Controllers for Streamed
+ Data Applications on {FPGA}-Based Computing Engines},
+ booktitle = {International Symposium on System Synthesis (ISSS)},
+ pages = {221-226},
+ year = {2001},
+}
+
+@article{FR-vlsi,
+ author = {Antoine Fraboulet and Tanguy Risset},
+ title = {Master Interface for On-Chip Hardware Accelerator Burst Communications},
+ journal = {Journal of VLSI Signal Processing},
+ publisher = {Springer Science},
+ year = {2007},
+ volume = {59},
+ pages = {73-85}
+}
+
+@InProceedings{jerraya,
+ author = {Sungjoo Yoo and Jerraya Ahmed},
+ title = {Introduction to Hardware Abstraction Layers for SoC},
+ OPTcrossref = {},
+ OPTkey = {},
+ booktitle = {Design, Automation and Test in Europe Conference and Exhibition},
+ pages = {336 -- 337},
+ year = 2003,
+ OPTeditor = {},
+ OPTvolume = {},
+ OPTnumber = {},
+ OPTseries = {},
+ OPTaddress = {},
+ OPTmonth = {},
+ OPTorganization = {},
+ OPTpublisher = {},
+ OPTnote = {},
+ OPTannote = {}
+}
+
+@INPROCEEDINGS{FAUST,
+ author = {D. Lattard and E. Beigne and C. Bernard and C. Bour and F.
+ Clermidy and Y. Durand and J. Durupt and D. Varreau and P. Vivet and
+ P. Penard and A. Bouttier and F. Berens},
+ title = "A Telecom Baseband Circuit-Based on an Asynchronous Network-on-Chip",
+ pages = {},
+ BOOKTITLE="ISSCC\'2007",
+ year = {2007},
+ publisher = {IEEE Computer Society},
+ address = {San Francisco, USA},
+};
+
+@inproceedings{JerrayaPetrot,
+ author = {Ahmed A. Jerraya and Aimen Bouchhima and Fr\'{e}d\'{e}ric P\'{e}trot},
+ title = {Programming models and HW-SW interfaces abstraction for multi-processor SoC},
+ booktitle = {DAC '06: Proceedings of the 43rd annual conference on Design automation},
+ year = {2006},
+ isbn = {1-59593-381-6},
+ pages = {280--285},
+ location = {San Francisco, CA, USA},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+}
+
+@inproceedings{mwmr,
+ author = {E. Faure and A. Greiner and D. Genius},
+ title = {A generic hardware/software communication mechanism for
+ Multi-Processor System on Chip, Targeting Telecommunication Applications},
+ booktitle = {ReCoSoC'06},
+ year = {2006},
+ pages = {237--242},
+ address = {Montpellier, France}
+ }
+
+@inproceedings{Alberto,
+ author = {Roberto Passerone and
+ James A. Rowson and
+ Alberto L. Sangiovanni-Vincentelli},
+ title = {Automatic Synthesis of Interfaces Between Incompatible Protocols},
+ booktitle = {DAC},
+ year = {1998},
+ pages = {8-13}
+}
+
+@article{Avnit,
+ author = {Karin Avnit and
+ Vijay D'Silva and
+ Arcot Sowmya and
+ S. Ramesh and
+ Sri Parameswaran},
+ title = {Provably correct on-chip communication: A formal approach
+ to automatic protocol converter synthesis},
+ journal = {ACM Trans. Design Autom. Electr. Syst.},
+ volume = {14},
+ number = {2},
+ year = {2009}
+}
+
+@inproceedings{smith,
+ author = {James Smith and
+ Giovanni De Micheli},
+ title = {Automated Composition of Hardware Components},
+ booktitle = {DAC},
+ year = {1998},
+ pages = {14-19}
+}
+
+@inproceedings{Narayan,
+ author = {Sanjiv Narayan and
+ Daniel Gajski},
+ title = {Interfacing Incompatible Protocols Using Interface Process
+ Generation},
+ booktitle = {DAC},
+ year = {1995},
+ pages = {468-473}
+}
+
+@TECHREPORT{Ptolemy,
+ AUTHOR = { E.A. Lee et al.},
+ INSTITUTION = {University of California, Berkeley},
+ NUMBER = {UCB/ERL No. M99/37},
+ TITLE = {Overview of the Ptolemy Project},
+ YEAR = {1999},
+ MONTH = {july}
+}
+
+@article{syntol,
+ author={Paul Feautrier},
+ title={Scalable and Structured Scheduling},
+ journal={Int. J. of Parallel Programming},
+ year=2006,
+ month=May, number=5, volume=34,
+ pages="459--487"
+}
+
+@InProceedings{bee,
+ author={Christophe Alias and Fabrice Baray and Alain Darte},
+ title={Bee+Cl@k: An Implementation of Lattice-Based Array Contraction in the Source-to-Source Translator ROSE},
+ booktitle = {LCTES},
+ year = {2007},
+ publisher = {ACM}
+}
+
+%%%%%%%%%%%%% ASIP %%%%%%%%%%%%%%%%
+
+@inproceedings{DAC09,
+ author = {Kluter, Theo and Brisk, Philip and Ienne, Paolo and Charbon, Edoardo},
+ title = {Way Stealing: cache-assisted automatic instruction set extensions},
+ booktitle = {DAC '09: Proceedings of the 46th Annual Design Automation Conference},
+ year = {2009},
+ isbn = {978-1-60558-497-3},
+ pages = {31--36},
+ location = {San Francisco, California},
+ doi = {http://doi.acm.org/10.1145/1629911.1629923},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+ }
+
+@inproceedings{CODES08,
+ author = {Kluter, Theo and Brisk, Philip and Ienne, Paolo and Charbon, Edoardo},
+ title = {Speculative DMA for architecturally visible storage in instruction set extensions},
+ booktitle = {CODES/ISSS '08: Proceedings of the 6th IEEE/ACM/IFIP international conference on Hardware/Software codesign and system synthesis},
+ year = {2008},
+ isbn = {978-1-60558-470-6},
+ pages = {243--248},
+ location = {Atlanta, GA, USA},
+ doi = {http://doi.acm.org/10.1145/1450135.1450191},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+ }
+
+@article{TVLSI06,
+ author = {Cong, Jason and Han, Guoling and Zhang, Zhiru},
+ title = {Architecture and compiler optimizations for data bandwidth improvement in configurable processors},
+ journal = {IEEE Trans. Very Large Scale Integr. Syst.},
+ volume = {14},
+ number = {9},
+ year = {2006},
+ issn = {1063-8210},
+ pages = {986--997},
+ doi = {http://dx.doi.org/10.1109/TVLSI.2006.884050},
+ publisher = {IEEE Educational Activities Department},
+ address = {Piscataway, NJ, USA},
+}
+
+
+@Book{NIOS2,
+ title = {{Nios II Processor Reference Handbook}},
+ publisher = {Altera},
+ year = {2009},
+}
+
+
+@inproceedings{ARC08,
+ author = {Galuzzi, Carlo and Bertels, Koen},
+ title = {The Instruction-Set Extension Problem: A Survey},
+ booktitle = {ARC '08: Proceedings of the 4th international workshop on Reconfigurable Computing},
+ year = {2008},
+ isbn = {978-3-540-78609-2},
+ pages = {209--220},
+ location = {London, UK},
+ doi = {http://dx.doi.org/10.1007/978-3-540-78610-8_21},
+ publisher = {Springer-Verlag},
+ address = {Berlin, Heidelberg},
+ }
+
+@inproceedings{CODES99,
+ author = {Charot, Fran\c{c}ois and Mess\'{e}, Vincent},
+ title = {{A flexible code generation framework for the design of application specific programmable processors}},
+ booktitle = {CODES '99: Proceedings of the seventh international workshop on Hardware/software codesign},
+ year = {1999},
+ pages = {27--31},
+ location = {Rome, Italy},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+ }
+
+@inproceedings{ASAP05,
+ author = {L'Hours, Ludovic},
+ title = {{Generating Efficient Custom FPGA Soft-Cores for Control-Dominated Applications}},
+ booktitle = {ASAP '05: Proceedings of the 2005 IEEE International Conference on Application-Specific Systems, Architecture Processors},
+ year = {2005},
+ pages = {127--133},
+ publisher = {IEEE Computer Society},
+ address = {Washington, DC, USA},
+}
+
+@inproceedings{roma,
+ author = {Menard, Daniel and Casseau, Emmanuel and Khan, Shafqat and Sentieys, Olivier and Chevobbe, St\'{e}phane and Guyetant, St\'{e}phane and David, Raphael},
+ title = {Reconfigurable Operator Based Multimedia Embedded Processor},
+ booktitle = {ARC '09: Proceedings of the 5th International Workshop on Reconfigurable Computing: Architectures, Tools and Applications},
+ year = {2009},
+ pages = {39--49},
+ location = {Karlsruhe, Germany},
+ publisher = {Springer-Verlag},
+ address = {Berlin, Heidelberg},
+ }
+
+%%%%%%%%%%%%% AUTRES %%%%%%%%%%%%%%%%
+
+@inproceedings{thales-viola,
+ author = {Viola, Jones},
+ title = {{Rapid Object Detection using a Boosted Cascade of Simple Feature}},
+ booktitle = {Proceedings of Conference on Computer Vision and Pattern recognition},
+ year = {2001},
+}
+@INPROCEEDINGS{FP:96
+ ,AUTHOR = "Paul Feautrier"
+ ,TITLE = "Automatic Parallelization in the Polytope Model"
+ ,BOOKTITLE = "The Data-Parallel Programming Model"
+ ,YEAR = 1996
+ ,EDITOR = "Guy-Ren\'e Perrin and Alain Darte"
+ ,PAGES = "79--103"
+ ,VOLUME = "LNCS 1132"
+ ,PUBLISHER = "Springer"
+}
+
+@book{DRV:2000,
+ author={Alain Darte and Yves Robert and Fr\'ed\'eric Vivien},
+ title={Scheduling and automatic Parallelization},
+ publisher={Birkh\"auser}, year=2000
+}
+
+@Article{Feau:92aa,
+ author = "Paul Feautrier",
+ title = "Some Efficient Solutions to the Affine Scheduling
+ Problem, {I}, One Dimensional Time",
+ volume = "21",
+ number = "5",
+ month = Oct,
+ pages = "313--348",
+ journal = "Int. J. of Parallel Programming",
+ year = "1992"
+}
+
+@Article{Feau:92bb,
+ author = "Paul Feautrier",
+ title = "Some Efficient Solutions to the Affine Scheduling
+ Problem, {II}, Multidimensional Time",
+ volume = "21",
+ number = "6",
+ journal = "Int. J. of Parallel Programming",
+ month = Dec,
+ pages = "389--420",
+ year = "1992"
+}
+
+@ARTICLE{Feau:96
+ ,AUTHOR = {Paul Feautrier}
+ ,TITLE = {Distribution Automatique des Donn\'es et des
+ calculs}
+ ,JOURNAL = {T.S.I.}
+ ,YEAR = 1996, VOLUME = 15, NUMBER = 5, PAGES = {529--557}
+}
Index: /anr-2010/anr.sty
===================================================================
--- /anr-2010/anr.sty (revision 274)
+++ /anr-2010/anr.sty (revision 274)
@@ -0,0 +1,264 @@
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\catcode`\@=11
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\newlength{\desclen}
+\newlength{\yearlen}
+\newlength{\mmlen}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%{\catcode`\<=1\catcode`\>=2
+% <\catcode`\{=12\gdef\OBraceTw<{>>
+% <\catcode`\}=12\gdef\CBraceTw<}>>
+%>
+%\@ifundefined{specHasManual}{\let\specHasManual\relax}{}
+\let\specHasManual\relax
+\let\specCsgManual\relax
+\let\specXilinxOptimization\relax
+
+\def\setMacroInAuxFile#1{%
+ \global\expandafter\edef\csname#1\endcsname{\name}
+ \expandafter\immediate\expandafter\write\@auxout\expandafter{\expandafter\string\expandafter\gdef\expandafter\string\csname #1\endcsname{\name}}
+}
+\def\eoa{end-of-args}
+\def\@novers#1-#2\eoa{#1}
+\def\novers#1{\ifx\relax#1\def\next{{\color{red}FIXME}}\else\def\next{\expandafter\@novers#1\eoa}\fi\next}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\newcount\supportercnt\supportercnt=1
+\newwrite\supporter
+\immediate\openout\supporter=anr-supporter.tex
+\def\letterOfInterest#1#2{{%
+ \let\subsection\relax%
+ \let\label\relax%
+ \let\begin\relax%
+ \let\end\relax%
+ \let\includegraphics\relax%
+ \let\linewidth\relax%
+ \let\newpage\relax%
+ \immediate\write\supporter{%
+ \subsection{#1} \label{supp:\the\supportercnt}}%
+ \immediate\write\supporter{%
+ \begin{center}\includegraphics[width=0.9\linewidth]{#2}\end{center}}%
+ \newpage%
+ }%
+ #1 (page \pageref{supp:\the\supportercnt})%
+ \advance\supportercnt1%
+}
+\def\letterOfInterestPlus#1{{%
+ \let\begin\relax%
+ \let\end\relax%
+ \let\includegraphics\relax%
+ \let\linewidth\relax%
+ \let\newpage\relax%
+ \immediate\write\supporter{%
+ \begin{center}\includegraphics[width=0.9\linewidth]{#1}\end{center}}%
+ \newpage%
+ }%
+}
+
+\def\letterOfInterestNb{?}
+\def\letterOfInterestClose{
+ \advance\supportercnt-1
+ \immediate\closeout\supporter
+ \immediate\write\@auxout{%
+ \string\gdef\string\letterOfInterestNb{\the\supportercnt}
+ }
+}
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\let\ganttlf\relax
+\newwrite\ganttdata
+\immediate\openout\ganttdata=anr.gantt
+
+\def\enable{enable}
+\def\disable{disable}
+\def\leader{leader}
+\newenvironment{taskinfo}%
+{%
+\let\ALL\disable%
+\let\IRISA\disable%
+\let\LIP\disable%
+\let\TIMA\disable%
+\let\UBS\disable%
+\let\UPMC\disable%
+\let\XILINX\disable%
+\let\BULL\disable%
+\let\THALES\disable%
+\let\NAVTEL\disable%
+\let\ZIED\disable%
+}{%
+\ifx\ALL\enable%
+ \ifx\IRISA\disable\let\IRISA\enable\fi%
+ \ifx\LIP\disable\let\LIP\enable\fi%
+ \ifx\UPMC\disable\let\UPMC\enable\fi%
+ \ifx\TIMA\disable\let\TIMA\enable\fi%
+ \ifx\UBS\disable\let\UBS\enable\fi%
+ \ifx\XILINX\disable\let\XILINX\enable\fi%
+ \ifx\BULL\disable\let\BULL\enable\fi%
+ \ifx\THALES\disable\let\THALES\enable\fi%
+ \ifx\NAVTEL\disable\let\NAVTEL\enable\fi%
+ \ifx\ZIED\disable\let\ZIED\enable\fi%
+\fi%
+\def\@leader{\begin{small}\textcolor{red}{lead.}\end{small}}
+\def\@partner{\begin{small}\textcolor{blue}{part.}\end{small}}
+\def\@IRISA{\ifx\IRISA\disable{}\else\ifx\IRISA\enable{\@partner}\else{\@leader}\fi\fi}%
+\def\@LIP{\ifx\LIP\disable{}\else\ifx\LIP\enable{\@partner}\else{\@leader}\fi\fi}%
+\def\@UPMC{\ifx\UPMC\disable{}\else\ifx\UPMC\enable{\@partner}\else{\@leader}\fi\fi}%
+\def\@TIMA{\ifx\TIMA\disable{}\else\ifx\TIMA\enable{\@partner}\else{\@leader}\fi\fi}%
+\def\@UBS{\ifx\UBS\disable{}\else\ifx\UBS\enable{\@partner}\else{\@leader}\fi\fi}%
+\def\@XILINX{\ifx\XILINX\disable{}\else\ifx\XILINX\enable{\@partner}\else{\@leader}\fi\fi}%
+\def\@BULL{\ifx\BULL\disable{}\else\ifx\BULL\enable{\@partner}\else{\@leader}\fi\fi}%
+\def\@THALES{\ifx\THALES\disable{}\else\ifx\THALES\enable{\@partner}\else{\@leader}\fi\fi}%
+\def\@NAVTEL{\ifx\NAVTEL\disable{}\else\ifx\NAVTEL\enable{\@partner}\else{\@leader}\fi\fi}%
+\def\@ZIED{\ifx\ZIED\disable{}\else\ifx\ZIED\enable{\@partner}\else{\@leader}\fi\fi}%
+\begin{tabular}{|c|c|c|c|c|c|c|c|c|c|}\hline
+\Sirisa & \Slip & \Stima & \Subs & \Supmc & \Sxilinx & \Sbull & \Sthales & \Snavtel & \Szied \\\hline
+\@IRISA & \@LIP & \@TIMA & \@UBS & \@UPMC & \@XILINX & \@BULL & \@THALES & \@NAVTEL & \@ZIED \\\hline
+\end{tabular}\par
+}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\newenvironment{objectif}%
+{\begin{description}\item[Objectives]}
+{\end{description}}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\newcount\taskcnt\taskcnt=0
+\newcount\subtaskcnt
+\newcount\livrablecnt
+\newenvironment{workpackage}%
+{\global\advance\taskcnt1
+ \global\subtaskcnt0
+ \def\taskname{T\the\taskcnt}%
+ \begin{description}%
+ %\let\itemsave\item%
+ \def\subtask{%
+ \global\advance\subtaskcnt1
+ \def\subtaskname{S\taskname-\the\subtaskcnt}%
+ \item[\subtaskname]}}
+{\end{description}}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\def\writeganttinfo#1#2#3#4#5#6{{%
+ \let\xcoach\relax
+ \let\xcoachplus\relax
+ \let\irisa\relax \let\Sirisa\relax
+ \let\lip\relax \let\Slip\relax
+ \let\tima\relax \let\Stima\relax
+ \let\ubs\relax \let\Subs\relax
+ \let\upmc\relax \let\Supmc\relax
+ \let\altera\relax \let\Saltera\relax
+ \let\xilinx\relax \let\Sxilinx\relax
+ \let\bull\relax \let\Sbull\relax
+ \let\thales\relax \let\Sthales\relax
+ \let\zied\relax \let\Szied\relax
+ \let\navtel\relax \let\Snavtel\relax
+ \immediate\write\ganttdata{%
+ T=\the\taskcnt\space S=\the\subtaskcnt\space%
+ D=\the\livrablecnt\space V=\vers\space%
+ BM=#1 EM=#2 R=#3 PART={#4} KIND={#5} TITLE=#6%
+ }
+}}
+\newenvironment{livrable}%
+{%
+ \newcount\verscnt\verscnt=-1
+ \newif\ifIsLivrableStarted\IsLivrableStartedfalse
+ \newif\ifLivrableTopLine\LivrableTopLinetrue
+ \def\livrableTableDef{\begin{tabular}{|c|c|c|c|p{.625\linewidth}|}\hline}
+ \def\livrableTableLine##1##2##3##4{%
+ \makebox[3.5em]{\begin{small}##1\end{small}} &
+ \makebox[2.2em]{\begin{small}##2\end{small}} &
+ \makebox[1.5em]{\begin{small}##3\end{small}} &
+ \makebox[2.2em]{\begin{small}##4\end{small}} &
+ }
+ \def\livrableTableTopLine{%
+ \livrableTableLine{number}{date}{type}{resp.} description
+ }
+ \livrablecnt-1
+ \ifvmode \else\par\fi
+
+ \def\itemV##1##2##3##4##5{%
+ \ifIsLivrableStarted
+ \global\advance\verscnt1
+ \else
+ \global\advance\livrablecnt1
+ \global\verscnt1
+ \fi
+ \def\vers{V\the\verscnt}
+ \global\edef\name{D\the\taskcnt\the\subtaskcnt\the\livrablecnt-\vers}%
+ \writeganttinfo{##1}{##2}{none}{##4}{##3}{##5}
+ \\\hline
+ \ifLivrableTopLine
+ \ifIsLivrableStarted\else\hline\hline\fi
+ \else
+ \ifIsLivrableStarted\else\end{tabular}\\\livrableTableDef\fi
+ \fi
+ \global\LivrableTopLinefalse
+ \global\IsLivrableStartedtrue
+ %\global\LivrableStartfalse
+ \livrableTableLine%
+ {\textsc{\name}}%
+ {\textsc{T0+##2}}%
+ {\textsc{##3}}%
+ {\textsc{##4}}%
+ }
+ \def\itemL##1##2##3##4##5##6{%
+ \ifIsLivrableStarted
+ %\global\advance\verscnt1
+ \else
+ \global\advance\livrablecnt1
+ %\global\verscnt1
+ \fi
+ \def\vers{VF}
+ \global\edef\name{D\the\taskcnt\the\subtaskcnt\the\livrablecnt-\vers}%
+ \writeganttinfo{##1}{##2}{##6}{##4}{##3}{##5}
+ \\\hline
+ \ifLivrableTopLine
+ \ifIsLivrableStarted\else\hline\hline\fi
+ \else
+ \ifIsLivrableStarted\else\end{tabular}\\\livrableTableDef\fi
+ \fi
+ \global\LivrableTopLinefalse
+ \global\IsLivrableStartedfalse
+ %\global\LivrableStartfalse
+ \livrableTableLine%
+ {\textsc{\name}}%
+ {\textsc{T0+##2}}%
+ {\textsc{##3}}%
+ {\textsc{##4}}%
+ }
+ \def\CoutHorsD##1##2##3##4##5{%
+ \let\xcoach\relax
+ \let\xcoachplus\relax
+ \let\irisa\relax \let\Sirisa\relax
+ \let\lip\relax \let\Slip\relax
+ \let\tima\relax \let\Stima\relax
+ \let\ubs\relax \let\Subs\relax
+ \let\upmc\relax \let\Supmc\relax
+ \let\altera\relax \let\Saltera\relax
+ \let\xilinx\relax \let\Sxilinx\relax
+ \let\bull\relax \let\Sbull\relax
+ \let\thales\relax \let\Sthales\relax
+ \let\zied\relax \let\Szied\relax
+ \let\navtel\relax \let\Snavtel\relax
+ \immediate\write\ganttdata{%
+ T=\the\taskcnt\space S=\the\subtaskcnt\space%
+ D=none BM=##1 EM=##2 R=##5 PART={##3} TITLE=##4%
+ }
+ }
+% \begin{small}
+ \livrableTableDef
+ \livrableTableTopLine
+ %\begin{tabular}{|c|c|c|c|p{.55\linewidth}|}\hline%
+ %\makebox[3.5em]{number} & \makebox[1.5em]{date} & type & resp. & description
+}
+{\\\hline\end{tabular}\\%
+%\end{small}\\%
+}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\catcode`\@=12
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Index: /anr-2010/anr.tex
===================================================================
--- /anr-2010/anr.tex (revision 274)
+++ /anr-2010/anr.tex (revision 274)
@@ -0,0 +1,412 @@
+\documentclass[11pt,a4paper]{article}
+
+\usepackage[french,english]{babel}
+%\usepackage[utf8x]{inputenc}
+\usepackage{times}
+\usepackage[T1]{fontenc}
+\usepackage{aeguill}
+\usepackage{verbatim}
+\usepackage{algorithm,algorithmic}
+\usepackage{xmpmulti}
+\usepackage{graphicx}
+\usepackage{color}
+\usepackage{xspace}
+\usepackage{geometry}
+\usepackage{textcomp}
+\usepackage{multirow}
+\usepackage{lscape}
+\geometry{verbose,a4paper,tmargin=3cm,bmargin=2cm,lmargin=2cm,rmargin=2cm}
+
+\usepackage{anr}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\usepackage{fancyhdr}
+\usepackage{lastpage}
+\pagestyle{fancy}
+\lhead{\begin{minipage}{1.5cm}\includegraphics[width=\linewidth]{logo-anr}\vspace*{1mm}\end{minipage}}
+\chead{\begin{minipage}{5cm}\small\center Programme ARPEGE\\Edition 2010\vspace*{1mm}\end{minipage}}
+\rhead{\begin{minipage}{5cm}\small\raggedleft Project COACH\\Scientific document\vspace*{1mm}\end{minipage}}
+\lfoot{\begin{minipage}{1.5cm}\end{minipage}}
+\cfoot{\begin{minipage}{5cm}\end{minipage}}
+\rfoot{\begin{minipage}{2cm}\small\center\thepage/\pageref{LastPage}\end{minipage}}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\def\xcoach{\texttt{xcoach}\xspace}
+\def\xcoachplus{\texttt{xcoach+}\xspace}
+\def\backbone{backbone infrastructure\xspace}
+\def\Backbone{Backbone infrastructure\xspace}
+\def\hommemois{men*months\xspace}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\def\anrdoc#1{}
+\let\pagefeed\relax
+\def\euro{\mbox{\raisebox{.25ex}{{\it =}}\hspace{-.5em}{\sf C}}}
+\definecolor{gris}{gray}{0.75}
+\definecolor{rouge}{rgb}{1.0,0.2,0.2}
+\def\mustbecompleted#1{}
+\def\parlf{\par\vspace*{1.0ex}}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\def\Sformat#1{\begin{small}\textsc{#1}\end{small}}
+\def\inria{INRIA\xspace} \def\Sinria{\Sformat{INRIA}\xspace}
+\def\irisa{INRIA/CAIRN\xspace} \def\Sirisa{\Sformat{INRI}\xspace}
+\def\lip{ENS Lyon/LIP\xspace} \def\Slip{\Sformat{LIP}\xspace}
+\def\tima{TIMA\xspace} \def\Stima{\Sformat{TIMA}\xspace}
+\def\ubs{LAB-STICC\xspace} \def\Subs{\Sformat{UBS}\xspace}
+\def\upmc{LIP6\xspace} \def\Supmc{\Sformat{LIP6}\xspace}
+\def\altera{ALTERA\xspace} \def\Saltera{\Sformat{ALTE}\xspace}
+\def\xilinx{XILINX\xspace} \def\Sxilinx{\Sformat{XILX}\xspace}
+\def\bull{BULL\xspace} \def\Sbull{\Sformat{BULL}\xspace}
+\def\thales{THALES\xspace} \def\Sthales{\Sformat{TRT}\xspace} \let\TRT\thales
+\def\zied{FLEXRAS\xspace} \def\Szied{\Sformat{FLEX}\xspace}
+\def\navtel{NAVTEL-SYSTEM\xspace} \def\Snavtel{\Sformat{NAV}\xspace}
+
+\def\alllabs{\irisa \citi \lip \tima \ubs \upmc}
+\def\allcompagnies{\bull \thales \zied\xspace}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\def\ST{sub-task\xspace}
+\def\STs{sub-tasks\xspace}
+% FIXME \def\taskresponsable#1#2#3{\ifvmode\else\\\fi
+% FIXME The coordinator of this task is #1 member of #2.
+% FIXME The partners collaborating in this task are #3.\\}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% DEBUT CONFIG
+% Comment next marcro to suppress the printing of anr directives
+%\def\anrdoc#1{\noindent\begin{scriptsize}\textcolor{red}{#1}\end{scriptsize}\ifhmode\par\fi}
+% Comment the next macro to suppress the pagefeed
+%\let\pagefeed\newpage
+% Comment the next macro to suppress it
+\def\mustbecompleted#1{\textcolor{red}{#1}}
+% FIN CONFIG
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%\title{%
+%\textbf{COACH:}
+%\textbf{C}onception d'\textbf{A}rchitecture par
+%\textbf{C}ompilation et synt\textbf{H}\`{e}se\\
+%\begin{normalsize}
+%(Architecture design by compilation and synthesis)%
+%\end{normalsize}
+%}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\begin{document}
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% 1
+%\maketitle
+\def\boitecochee{\fcolorbox{black}{black}{\makebox(0.20,0.20){}}}
+\noindent
+\begin{tabular}{|p{5cm}|p{10cm}|}\hline
+Acronym of the proposal & COACH \\\hline
+Title of the proposal in French &
+ \textbf{C}onception d'\textbf{A}rchitecture sur FPGA par
+ \textbf{C}ompilation et synt\textbf{H}\`{e}se\\\hline
+\begin{minipage}{\linewidth}Title of the proposal in\\ English\end{minipage}
+ & Architecture Design on FPGA by Compilation and Synthesis \\\hline
+\begin{minipage}{\linewidth}Theme\\\end{minipage}
+ & \setlength{\unitlength}{5.0mm}\begin{picture}(20,2)
+ \put( 0.5,1.1){\boitecochee} \put( 1.5,0.9){1}
+ \put( 3.5,0.9){\framebox(0.6,0.6){$\bullet$}} \put( 4.5,0.9){2}
+ \put( 6.5,0.9){\framebox(0.6,0.6){$\bullet$}} \put( 7.5,0.9){3}
+ \put( 9.5,0.9){\framebox(0.6,0.6){ }} \put(10.5,0.9){4}
+ \put(12.5,0.9){\framebox(0.6,0.6){$\bullet$}} \put(13.5,0.9){5}
+ \put( 0.5,0){\mbox{{\scriptsize $\bullet$: secondary theme}}}
+ \end{picture}\\\hline
+\begin{minipage}{\linewidth}\mbox{}\\Type of research\\\end{minipage}
+ & \begin{minipage}{\linewidth}
+ \setlength{\unitlength}{5.0mm}\begin{picture}(20,3.2)
+ \put(0.5,0.2){\framebox(0.6,0.6){ }} \put(1.5,0.2){Basic Research}
+ \put(0.5,1.4){\boitecochee} \put(1.5,1.2){Industrial Research}
+ \put(0.5,2.2){\framebox(0.6,0.6){ }} \put(1.5,2.2){Experimental Development}
+ \end{picture}\end{minipage}\\\hline
+Type of scientific project & \setlength{\unitlength}{5.0mm}\begin{picture}(20,1)
+ \put(0.5,0){\framebox(0.6,0.6){ }} \put(1.5,0){Platform}
+ \end{picture}\\\hline
+\end{tabular}\vspace{.5ex}\\
+\begin{tabular}{|c|c|c|c|}\hline
+ \begin{minipage}{4cm}\center
+ \vspace*{0.5ex}Total requested \\ funding
+ \end{minipage}
+ & \makebox[3cm]{1195931 \euro}
+ & \begin{minipage}{4.15cm}\center Project Duration \end{minipage}
+ & \begin{minipage}{3cm}\center 36 months \end{minipage} \\\hline
+\end{tabular}
+%
+\tableofcontents
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% 1
+\section{Executive summary}
+\anrdoc{(2 pages maximum) Résumer la problématique que le projet propose
+de résoudre, et comment cet objectif sera poursuivi (quelle approche
+technique, etc.). \\
+Ce résumé devra démontrer l'originalité du projet notamment sur les points
+suivants:
+\begin{itemize}
+\item les objectifs globaux, les verrous scientifiques et techniques,
+\item le programme de travail,
+\item les retombées scientifiques, techniques et économiques.
+\end{itemize}
+Ces éléments peuvent être recopiés dans les champs «résumés scientifiques»
+du site de soumission.}
+\input{section-1}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% 2
+\pagefeed\section{Context and relevance to the call }
+\anrdoc{(1 page maximum) Présentation générale du problème qu'il est
+proposé de traiter dans le projet et du cadre de travail
+(recherche fondamentale, industrielle ou développement expérimental).}
+\input{section-2}
+
+% 2.1
+\pagefeed\subsection{Economic and societal issues}
+\anrdoc{(2 pages maximum) Décrire le contexte économique, social, réglementaire
+dans lequel se situe le projet en présentant une analyse des enjeux sociaux,
+économiques, environnementaux, industriels. Donner si possible des arguments
+chiffrés, par exemple, pertinence et portée du projet par rapport à la
+demande économique (analyse du marché, analyse des tendances), analyse
+de la concurrence, indicateurs de réduction de coûts, perspectives de
+marchés (champs d'application, ...). Indicateurs des gains environnementaux,
+cycle de vie.}
+\input{section-2.1}
+
+% 2.2
+\pagefeed\subsection{Relevance of the proposal}
+\anrdoc{(2 pages maximum) Préciser :\begin{itemize}
+\item positionnement du projet par rapport au contexte développé précédemment:
+ vis- à-vis des projets et recherches concurrents, complémentaires ou
+ antérieurs, des brevets et standards...
+\item positionnement du projet par rapport aux axes thématiques de l'appel
+ à projets.
+\item positionnement du projet aux niveaux européen et international.
+\end{itemize}}
+\input{section-2.2}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% 3
+\section{Scientific and technical Description}
+
+% 3.1
+\pagefeed\subsection{State of the Art}
+\anrdoc{(3 pages maximum) écrire le contexte et les enjeux scientifiques
+dans lequel se situe le projet en présentant un état de l'art national et
+international dressant l'état des connaissances sur le sujet. Faire
+apparaître d'éventuels résultats préliminaires. Inclure les références
+bibliographiques nécessaires en annexe 7.1.}
+\input{section-3.1}
+
+% 3.2
+\pagefeed\subsection{S \& T objectives, progress beyond the state of the art}
+\anrdoc{(2 pages maximum)
+Décrire les objectifs scientifiques/techniques du projet.\\
+Présenter l'avancée scientifique attendue. Préciser l'originalité et le
+caractère ambitieux du projet.\\
+Détailler les verrous scientifiques et techniques à lever par la
+réalisation du projet.\\
+Décrire éventuellement le ou les produits finaux développés à l'issue du
+projet montrant le caractère innovant du projet.\\
+Présenter les résultats escomptés en proposant si possible des critères de
+réussite et d'évaluation adaptés au type de projet, permettant d'évaluer
+les résultats en fin de projet.\\
+Le cas échéant (programmes exigeant la pluridisciplinarité), démontrer
+l'articulation entre les disciplines scientifiques.}
+\input{section-3.2}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% 4
+\section{Scientific and technical objectives / project description}
+
+% 4.1
+\pagefeed\subsection{Scientific Programme, Project structure}
+\anrdoc{(2 pages maximum)
+Présentez le programme scientifique et justifiez la décomposition en tâches
+du programme de travail en cohérence avec les objectifs poursuivis.\\
+Utilisez un diagramme pour présenter les liens entre les différentes tâches
+(organigramme technique)\\
+Les tâches représentent les grandes phases du projet. Elles sont en nombre
+limité.\\
+N'oubliez pas les activités et actions correspondant à la dissémination et
+à la valorisation.}
+\input{section-4.1}
+
+% 4.2
+\pagefeed\subsection{Project management}
+\anrdoc{(2 pages maximum)
+Préciser les aspects organisationnels du projet et les modalités de
+coordination (si possible individualisation d'une tâche coordination : cf.
+tâche 0 du document de soumission A).}
+\input{section-4.2}
+
+% 4.3
+\pagefeed\subsection{Description of the tasks}
+\label{task-description}
+\anrdoc{(idéalement 1 ou 2 pages par tâche)
+Pour chaque tâche, décrire:\begin{itemize}
+\item les objectifs de la tâche et éventuels indicateurs de succès,
+\item le responsable de la tâche et les partenaires impliqués (possibilité
+de l'indiquer sous forme graphique),
+\item le programme détaillé des travaux par tâche,
+\item les livrables de la tâche,
+\item les contributions des partenaires (le «qui fait quoi»),
+\item la description des méthodes et des choix techniques et de la manière
+dont les solutions seront apportées,
+\item les risques de la tâche et les solutions de repli envisagées.
+\end{itemize}}
+In this document, we use the following abbreviations in the tables and Gantt diagrams:
+\begin{description}
+ \item[partner]
+ \Sirisa for \irisa, \Slip for \lip, \Stima for \tima, \Subs for \ubs,
+ \Supmc for \upmc, \Sxilinx for \xilinx, \Sbull for \bull, \Sthales for \thales,
+ \Szied for \zied and \Snavtel for \navtel.
+ \item[kind of the deliverable]
+ \texttt{x} for a software, \texttt{d} for a document and \texttt{h} for a hardware
+ component.
+ \item[task contribution]
+ "{\color{red}lead.}" for leader and
+ "{\color{blue}part.}" for participant.
+ \item[other abbreviations] "resp." for responsible patrner, "kd" for kind of
+ deliverable.
+\end{description}
+
+\subsubsection{Task 1: \textit{Project management}}
+\input{task-0}
+
+\subsubsection{Task 2: \textit{\Backbone}}
+\input{task-1}
+
+\subsubsection{Task 3: \textit{System generation}}
+\input{task-2}
+
+\subsubsection{Task 4: \textit{HAS front-end}}
+\input{task-3}
+
+\subsubsection{Task 5: \textit{HAS back-end}}
+\input{task-4}
+
+\subsubsection{Task 6: \textit{PC/FPGA communication middleware}}
+\input{task-5}
+
+\subsubsection{Task 7: \textit{Industrial demonstrators}}
+\input{task-6}
+
+\subsubsection{Task 8: \textit{Dissemination}}
+\label{task-7}
+\input{task-7}
+
+\subsection{Tasks schedule, deliverables and milestones}
+\anrdoc{(3 pages maximum)\begin{itemize}
+\item Présenter sous forme graphique un échéancier des différentes tâches
+et leurs dépendances (diagramme de Gantt par exemple).
+\item Présenter un tableau synthétique de l'ensemble des livrables du
+projet (numéro de tâche, date, intitulé, responsable).
+\item Préciser de façon synthétique les jalons scientifiques et/ou
+techniques, les principaux points de rendez-vous, les points bloquants ou
+aléas qui risquent de remettre en cause l'aboutissement du projet ainsi que
+les réunions de projet prévues.\end{itemize}}
+\input{section-4.4.tex}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\section{Dissemination and exploitation of results.
+ Management of intellectual property}
+\anrdoc{(1 à 2 pages)\\
+Présenter les stratégies de valorisation des résultats :
+\begin{itemize}
+\item la communication scientifique;
+\item la communication auprès du grand public;
+\item la valorisation des résultats attendus;
+\item les retombées scientifiques, techniques, industrielles, économiques,
+\item la place du projet dans la stratégie industrielle des entreprises partenaires du projet
+\item autres retombées (normalisation, information des pouvoirs publics, ...)
+\item les échéances et la nature des retombées technico- économiques attendues
+\item l'incidence éventuelle sur l'emploi, la création d'activités nouvelles.
+\end{itemize}
+Présenter les grandes lignes des modes de protection et d'exploitation des
+résultats\\
+Pour les projets partenariaux organismes de recherche/entreprises, les
+partenaires devront conclure, sous l'égide du coordinateur du projet, un
+accord de consortium dans un délai de un an si le projet est retenu pour
+financement.\\
+Pour les projets académiques, l'accord de consortium n'est pas obligatoire
+mais fortement conseillé.}
+\input{section-5.tex}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\section{Consortium Description}
+
+\subsection{Partners description \& relevance, complementarity}
+\anrdoc{(maximum 0,5 page par partenaire) Décrire brièvement chaque
+partenaire et fournir ici les éléments permettant d'apprécier la
+qualification des partenaires dans le projet (le « pourquoi qui fait quoi
+»). Il peut s'agir de réalisations passées, d'indicateurs (publications,
+brevets), de l'intérêt du partenaire pour le projet.\\
+Montrer la complémentarité et la valeur ajoutée des coopérations entre les
+différents partenaires. L'interdisciplinarité et l'ouverture à diverses
+collaborations seront à justifier en accord avec les orientations du
+projet. (1 page maximum)}
+\input{section-6.1.tex}
+
+\subsection{Relevant experience of the project coordinator}
+\input{section-6.2.tex}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\section{Scientific justification for the mobilisation of the resources}
+\anrdoc{On présentera ici la justification scientifique et technique des moyens
+demandés dans le document de soumission A par chaque partenaire et
+synthétisés à l'échelle du projet dans la fiche «Tableaux récapitulatifs»
+du document de soumission A.\\
+Chaque partenaire justifiera les moyens qu'il demande en distinguant les
+différents postes de dépenses.}
+\def\ressourcehelp{\anrdoc{\begin{itemize}
+\item Equipment: 1) Préciser la nature des équipements* et justifier le
+ choix des équipements. 2) Si nécessaire, préciser la part de financement
+ demandé sur le projet et si les achats envisagés doivent être complétés
+ par d'autres sources de financement. Si tel est le cas, indiquer le
+ montant et l'origine de ces financements complémentaires.
+ 3) Attention: Un devis sera demandé si le projet est retenu pour
+ financement.
+\item Personnel costs
+ 1) Le personnel non permanent (thèses, post- doctorants,CDD...)
+ financé sur le projet devra être justifié.
+ 2) Fournir les profils des postes à pourvoir pour les personnels à
+ recruter (1/2 page maximum par type de poste)
+ 3) Pour les thèses, préciser si des demandes de bourse de thèse sont
+ prévues ou en cours, en préciser la nature et la part de financement
+ imputable au projet.
+\item Subcontracting. Préciser: 1) la nature des prestations
+ 2) le type de prestataire.
+\item Travel. Préciser: 1) les missions liées aux travaux d'acquisition
+ sur le terrain (campagnes de mesures),
+ 2) les missions relevant de colloques, congrès.
+\item Expenses for inward billing (Costs justified by internal procedures
+of invoicing). Préciser la nature des prestations
+\item Other working costs. Toute dépense significative relevant de ce poste
+devra être justifiée.
+\end{itemize}}}
+\input{section-7}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\appendix
+\newpage
+\section{Bibliography}
+%\subsection{References}
+\anrdoc{Inclure la liste des références bibliographiques utilisées dans la
+partie «Etat de l'art» et les références bibliographiques des
+partenaires ayant trait au projet.}
+\bibliographystyle{plain}
+\bibliography{anr}
+
+\newpage
+\section{Letters of interest}
+\label{lettre-soutien}.
+\input{anr-supporter.tex}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\end{document}
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Index: /anr-2010/architecture-csg.fig
===================================================================
--- /anr-2010/architecture-csg.fig (revision 274)
+++ /anr-2010/architecture-csg.fig (revision 274)
@@ -0,0 +1,125 @@
+#FIG 3.2 Produced by xfig version 3.2.5b
+Landscape
+Center
+Metric
+Letter
+100.00
+Single
+-2
+1200 2
+6 3892 1126 5532 2807
+5 1 0 2 0 7 50 -1 -1 0.000 0 1 1 0 4886.631 1711.404 4857 2042 5139 1927 5211 1641
+ 1 1 2.00 57.15 114.30
+6 4397 1798 4861 2262
+1 4 0 2 0 7 50 -1 -1 0.000 1 0.0000 4629 2030 217 217 4412 2030 4846 2030
+4 0 0 50 -1 2 12 0.0000 4 150 240 4515 2099 T0\001
+-6
+6 4217 2372 5192 2732
+4 1 0 50 -1 2 16 0.0000 4 195 855 4704 2507 process\001
+4 1 0 50 -1 2 16 0.0000 4 195 975 4704 2732 network\001
+-6
+1 4 0 2 0 7 50 -1 -1 0.000 1 0.0000 4214 1427 217 217 3996 1427 4431 1427
+1 4 0 2 0 7 50 -1 -1 0.000 1 0.0000 5180 1439 217 217 4963 1439 5398 1439
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 2.00 57.15 114.30
+ 4997 1427 4425 1427
+2 1 1 2 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 3917 2332 5517 2332
+2 4 0 2 0 7 50 -1 -1 0.000 0 0 7 0 0 5
+ 5507 2792 3907 2792 3907 1141 5507 1141 5507 2792
+4 0 0 50 -1 2 12 0.0000 4 150 240 4139 1498 T1\001
+4 0 0 50 -1 2 12 0.0000 4 150 240 5068 1498 T2\001
+-6
+6 3945 135 5505 890
+4 1 0 50 -1 2 14 0.0000 4 165 1275 4725 300 architecture\001
+4 1 0 50 -1 2 14 0.0000 4 225 1080 4725 470 parameter\001
+4 1 0 50 -1 2 14 0.0000 4 120 135 4715 640 +\001
+4 1 0 50 -1 2 14 0.0000 4 225 1650 4725 830 hw/sw mapping\001
+-6
+6 6525 1070 7895 1580
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 6540 1085 7880 1085 7880 1565 6540 1565 6540 1085
+4 1 0 50 -1 2 16 0.0000 4 195 585 7220 1415 CSG\001
+-6
+6 6165 3240 8100 4455
+5 1 1 2 0 7 50 -1 -1 4.000 0 1 0 0 7132.500 1087.813 6205 4281 7052 4412 8060 4281
+6 6165 3240 8100 4325
+6 6528 3544 7697 4325
+4 1 0 50 -1 2 13 0.0000 4 148 1142 7106 3722 architecture\001
+4 1 0 50 -1 2 13 0.0000 4 202 658 7146 4228 library\001
+4 1 0 50 -1 2 13 0.0000 4 202 820 7106 3968 template\001
+-6
+1 1 1 2 0 7 50 -1 -1 4.000 1 0.0000 7133 3370 927 87 7133 3370 8060 3370
+-6
+2 1 1 2 0 7 50 -1 -1 4.000 0 0 -1 0 0 3
+ 6205 3370 6205 4281 6205 4195
+2 1 1 2 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 8060 3370 8060 4281
+-6
+6 5715 2115 6885 3015
+5 1 1 2 0 7 50 -1 -1 4.000 0 1 0 0 6300.000 1324.603 5739 2886 6251 2983 6861 2886
+1 1 1 2 0 7 50 -1 -1 4.000 1 0.0000 6300 2211 561 64 6300 2211 6861 2211
+2 1 1 2 0 7 50 -1 -1 4.000 0 0 -1 0 0 3
+ 5739 2211 5739 2886 5739 2822
+2 1 1 2 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 6861 2211 6861 2886
+-6
+6 7110 2025 8640 3105
+5 1 1 2 0 7 50 -1 -1 4.000 0 1 0 0 7875.000 723.628 7141 2950 7811 3067 8609 2950
+1 1 1 2 0 7 50 -1 -1 4.000 1 0.0000 7876 2140 734 77 7876 2140 8609 2140
+2 1 1 2 0 7 50 -1 -1 4.000 0 0 -1 0 0 3
+ 7141 2140 7141 2950 7141 2874
+2 1 1 2 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 8609 2140 8609 2950
+-6
+6 5895 2295 6660 2835
+4 1 0 50 -1 2 14 0.0000 4 165 315 6300 2475 OS\001
+4 1 0 50 -1 2 14 0.0000 4 225 735 6285 2745 library\001
+-6
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 -1 1 0 2
+ 0 0 2.00 120.00 240.00
+ 2932 1922 3912 1922
+2 4 0 2 0 7 50 -1 -1 6.000 0 0 7 0 0 5
+ 10365 1595 10365 920 9240 920 9240 1595 10365 1595
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 -1 1 0 2
+ 0 0 2.00 120.00 240.00
+ 5625 455 6465 1250
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 -1 1 0 2
+ 0 0 2.00 120.00 240.00
+ 5505 1430 6435 1430
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 -1 1 0 2
+ 0 0 2.00 120.00 240.00
+ 7890 1220 9195 1220
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 -1 1 0 2
+ 0 0 2.00 120.00 240.00
+ 7890 1415 9210 1880
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 6510 110 7875 110 7875 545 6510 545 6510 110
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 -1 1 0 2
+ 0 0 2.00 120.00 240.00
+ 7200 1085 7200 560
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 -1 1 0 2
+ 0 0 2.00 120.00 240.00
+ 6255 2105 6690 1595
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 -1 1 0 2
+ 0 0 2.00 120.00 240.00
+ 7695 2120 7575 1595
+2 4 0 2 0 7 50 -1 -1 6.000 0 0 7 0 0 5
+ 10335 2290 10335 1840 9210 1840 9210 2290 10335 2290
+2 1 1 2 0 7 50 -1 -1 6.000 0 0 -1 1 0 2
+ 0 0 2.00 120.00 240.00
+ 9767 2310 9767 3210
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 -1 1 0 2
+ 0 0 2.00 120.00 240.00
+ 7040 3260 7025 1565
+4 1 0 50 -1 2 14 0.0000 4 165 1005 9810 1445 bitstream\001
+4 1 0 50 -1 2 14 0.0000 4 165 660 9810 1205 FPGA\001
+4 1 0 50 -1 2 14 0.0000 4 165 1005 9795 2110 simulator\001
+4 1 0 50 -1 2 14 0.0000 4 225 1140 7905 2690 component\001
+4 1 0 50 -1 2 14 0.0000 4 165 885 7890 2960 libraries\001
+4 1 0 50 -1 2 14 0.0000 4 165 1005 7905 2435 hardware\001
+4 1 0 50 -1 2 14 0.0000 4 225 1320 9810 3470 performance\001
+4 1 0 50 -1 2 14 0.0000 4 225 825 9810 3770 analysis\001
+4 1 0 50 -1 2 16 0.0000 4 195 585 7185 425 HAS\001
+4 1 0 50 -1 2 14 0.0000 4 165 720 2259 1852 initilal\001
+4 1 0 50 -1 2 14 0.0000 4 225 1185 2259 2152 application\001
Index: /anr-2010/architecture-hls.fig
===================================================================
--- /anr-2010/architecture-hls.fig (revision 274)
+++ /anr-2010/architecture-hls.fig (revision 274)
@@ -0,0 +1,109 @@
+#FIG 3.2 Produced by xfig version 3.2.5b
+Landscape
+Center
+Metric
+Letter
+100.00
+Single
+-2
+1200 2
+6 4680 -855 6120 -270
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 4725 -810 6075 -810 6075 -315 4725 -315 4725 -810
+4 0 0 50 -1 2 14 0.0000 4 165 990 4857 -480 front-end\001
+-6
+6 4905 405 5895 1395
+2 4 1 2 0 7 50 -1 -1 6.000 0 0 7 0 0 5
+ 5847 1350 5847 450 4947 450 4947 1350 5847 1350
+4 1 0 50 -1 2 14 0.0000 4 165 705 5397 945 xcoach\001
+-6
+6 6878 -720 7613 -195
+4 1 0 50 -1 2 14 0.0000 4 225 735 7245 -255 library\001
+4 1 0 50 -1 2 14 0.0000 4 165 360 7245 -555 cell\001
+-6
+6 6615 -1125 7875 45
+5 1 1 2 0 7 50 -1 -1 4.000 0 1 0 0 7269.206 -978.870 6644 -211 7188 8 7846 -174
+1 1 1 2 0 7 50 -1 -1 4.000 1 0.0000 7245 -942 602 146 7245 -942 7846 -942
+2 1 1 2 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 6644 -942 6644 -211
+2 1 1 2 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 7846 -906 7846 -174
+-6
+6 10260 450 11430 855
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 -1 1 0 2
+ 0 0 2.00 120.00 240.00
+ 10980 675 11377 652
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 10305 495 10980 495 10980 810 10305 810 10305 495
+-6
+6 10260 990 11430 1395
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 -1 1 0 2
+ 0 0 2.00 120.00 240.00
+ 10980 1215 11377 1192
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 10305 1035 10980 1035 10980 1350 10305 1350 10305 1035
+-6
+6 10260 1440 11430 1845
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 -1 1 0 2
+ 0 0 2.00 120.00 240.00
+ 10980 1665 11377 1642
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 10305 1485 10980 1485 10980 1800 10305 1800 10305 1485
+-6
+1 4 0 2 0 7 50 -1 -1 6.000 1 0.0000 1758 828 699 699 1061 791 2456 866
+2 2 0 2 0 7 50 -1 -1 6.000 0 0 7 0 0 5
+ 3150 225 4275 225 4275 900 3150 900 3150 225
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 3150 900 4275 900 4275 1575 3150 1575 3150 900
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 -1 1 0 2
+ 0 0 2.00 120.00 240.00
+ 2472 872 3120 595
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 -1 1 0 2
+ 0 0 2.00 120.00 240.00
+ 4252 1262 4905 900
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 7 1 1 2
+ 0 0 2.00 120.00 240.00
+ 0 0 2.00 120.00 240.00
+ 5355 -358 5355 450
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 6660 540 7875 540 7875 1170 6660 1170 6660 540
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 7 1 0 2
+ 0 0 2.00 120.00 240.00
+ 5847 900 6565 900
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 7 1 0 2
+ 0 0 2.00 120.00 240.00
+ 7872 900 8590 900
+2 4 1 2 0 7 50 -1 -1 6.000 0 0 7 0 0 5
+ 9585 1395 9585 450 8550 450 8550 1395 9585 1395
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 7 1 0 2
+ 0 0 2.00 120.00 240.00
+ 9632 642 10302 642
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 7 1 0 2
+ 0 0 2.00 120.00 240.00
+ 5475 1635 10302 1642
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 5505 1620 5505 1350
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 9045 1395 9045 1650
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 -1 1 0 2
+ 0 0 2.00 120.00 240.00
+ 7249 -8 7245 540
+2 4 1 2 0 7 50 -1 -1 6.000 0 0 7 0 0 5
+ 9585 1395 9585 450 8550 450 8550 1395 9585 1395
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 7 1 0 2
+ 0 0 2.00 120.00 240.00
+ 9632 1170 10302 1170
+4 1 0 50 -1 2 14 0.0000 4 165 705 3690 1125 xcoach\001
+4 1 0 50 -1 2 14 0.0000 4 165 645 3690 1425 driver\001
+4 1 0 50 -1 2 14 0.0000 4 180 330 3690 630 gcc\001
+4 1 0 50 -1 2 14 0.0000 4 165 840 9042 945 xcoach+\001
+4 0 0 50 -1 2 14 0.0000 4 165 945 6795 945 back-end\001
+4 1 0 50 -1 2 16 0.0000 4 195 975 1757 1165 network\001
+4 1 0 50 -1 2 16 0.0000 4 195 855 1757 895 process\001
+4 1 0 50 -1 2 16 0.0000 4 195 780 1757 625 task of\001
+4 0 0 50 -1 0 12 0.0000 4 150 525 10395 720 X2SC\001
+4 0 0 50 -1 0 12 0.0000 4 150 570 10395 1260 X2vhd\001
+4 0 0 50 -1 2 16 0.0000 4 195 825 11385 1260 VHDL\001
+4 0 0 50 -1 2 16 0.0000 4 255 1065 11430 720 SystemC\001
+4 0 0 50 -1 2 16 0.0000 4 195 195 11430 1755 C\001
+4 0 0 50 -1 0 12 0.0000 4 150 405 10395 1710 X2C\001
Index: /anr-2010/architecture-hpc.fig
===================================================================
--- /anr-2010/architecture-hpc.fig (revision 274)
+++ /anr-2010/architecture-hpc.fig (revision 274)
@@ -0,0 +1,84 @@
+#FIG 3.2 Produced by xfig version 3.2.5b
+Landscape
+Center
+Metric
+Letter
+100.00
+Single
+-2
+1200 2
+6 3375 1485 4725 2160
+4 1 0 50 -1 2 14 0.0000 4 165 1155 4050 1710 FPGA SoC\001
+4 1 0 50 -1 2 14 0.0000 4 225 450 4050 2010 part\001
+-6
+6 3825 -90 4275 585
+4 1 0 50 -1 2 14 0.0000 4 165 315 4050 135 PC\001
+4 1 0 50 -1 2 14 0.0000 4 225 450 4050 435 part\001
+-6
+6 5580 1530 7020 2070
+4 1 0 50 -1 2 14 0.0000 4 165 1410 6300 1710 comunication\001
+4 1 0 50 -1 2 14 0.0000 4 225 735 6300 2010 library\001
+-6
+6 3600 630 4500 855
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 3
+ 3825 780 4050 705 4275 780
+-6
+6 3600 1170 4500 1395
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 3
+ 3825 1245 4050 1320 4275 1245
+-6
+6 5445 1260 7155 2250
+5 1 1 2 0 7 50 -1 -1 4.000 0 1 0 0 6374.758 -598.790 5490 2070 6165 2205 7110 2115
+1 1 1 2 0 7 50 -1 -1 4.000 1 0.0000 6300 1395 810 90 6300 1395 7110 1395
+2 1 1 2 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 5490 1395 5490 2115
+2 1 1 2 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 7110 1395 7110 2115
+-6
+2 2 0 2 0 7 50 -1 -1 0.000 0 0 7 0 0 5
+ 5625 -225 6975 -225 6975 675 5625 675 5625 -225
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 7 1 0 2
+ 0 0 2.00 120.00 240.00
+ 2700 225 3375 225
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 7 0 0 2
+ 2250 990 2722 982
+2 4 0 2 0 7 50 -1 -1 6.000 0 0 7 0 0 5
+ 4725 675 4725 -225 3375 -225 3375 675 4725 675
+2 4 0 2 0 7 50 -1 -1 6.000 0 0 7 0 0 5
+ 4725 2250 4725 1350 3375 1350 3375 2250 4725 2250
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 -1 1 0 2
+ 0 0 2.00 120.00 240.00
+ 2700 1800 3375 1800
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 7 0 0 2
+ 2700 225 2700 1800
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 -1 1 0 2
+ 0 0 2.00 120.00 240.00
+ 4725 225 5625 225
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 -1 1 0 2
+ 0 0 2.00 120.00 240.00
+ 4725 1800 5625 450
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 -1 1 0 2
+ 0 0 2.00 120.00 240.00
+ 6300 1350 6300 675
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 -1 1 0 2
+ 0 0 2.00 120.00 240.00
+ 6975 225 7875 225
+2 4 0 2 0 7 50 -1 -1 6.000 0 0 7 0 0 5
+ 9000 450 9000 0 7875 0 7875 450 9000 450
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 2
+ 3825 810 3825 1215
+2 1 0 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 2
+ 4275 765 4275 1215
+2 1 1 2 0 7 50 -1 -1 6.000 0 0 -1 1 0 2
+ 0 0 2.00 120.00 240.00
+ 8432 470 8432 1370
+4 1 0 50 -1 2 14 0.0000 4 225 915 6300 360 compiler\001
+4 1 0 50 -1 2 14 0.0000 4 165 165 6300 90 C\001
+4 1 0 50 -1 2 16 0.0000 4 195 135 2925 1125 1\001
+4 1 0 50 -1 2 16 0.0000 4 195 135 4050 1125 2\001
+4 1 0 50 -1 2 16 0.0000 4 195 135 8655 900 3\001
+4 1 0 50 -1 2 14 0.0000 4 225 825 8505 1920 analysis\001
+4 1 0 50 -1 2 14 0.0000 4 225 1320 8505 1620 performance\001
+4 1 0 50 -1 2 14 0.0000 4 165 1005 8460 270 simulator\001
+4 1 0 50 -1 2 14 0.0000 4 165 720 1575 900 initilal\001
+4 1 0 50 -1 2 14 0.0000 4 225 1185 1575 1200 application\001
Index: /anr-2010/coach_global.txt
===================================================================
--- /anr-2010/coach_global.txt (revision 274)
+++ /anr-2010/coach_global.txt (revision 274)
@@ -0,0 +1,142 @@
+
+The market of digital systems is about 4,600 M\$ today and is estimated to
+5,600 M\$ in 2012. However the ever growing applications complexity involves
+integration of heterogeneous technologies and requires the design of
+complex Multi-Processors System on Chip (MPSoC).
+
+During the last decade, the design of ASICs (Application Specific
+Integrated Circuits) appeared to be more and more reserved to high volume markets, because
+the design and fabrication costs of such components exploded, due to increasing NRE (Non
+Recurring-Engineering) costs.
+Fortunately, FPGA (Field Programmable Gate Array) components, such as the
+Virtex5 family from Xilinx or the Stratix4 family from Altera, can nowadays
+implement a complete MPSoC with multiple processors and several dedicated
+coprocessors for a few Keuros per device. Many applications are initially captured
+algorithmically in High-Level Languages (HLLs) such as C/C++. This has led to growing interest
+in tools that can provide an implementation path directly from HLLs to hardware.
+Thus, Electronic System Level (ESL) design methodologies (Virtual Prototyping,
+Co-design, High-Level Synthesis...) are now mature and allow the automation of
+a system-level design flow. Unfortunately, ESL tool development to date has primarily focused
+on the design of hard-wired devices i.e. ASICs and ASSPs (Application Specific Standard Product).
+However, the increasing sophistication of FPGAs has accelerated the need for FPGA-based ESL design
+methodologies. ESL methodologies hold the promise of streamlining the design approach by accepting
+designs written in C/C++ language and implementing the function straight into FPGA.
+We believe that coupling FPGA technologies and ESL methodologies
+will allow both SMEs (Small and Medium Enterprise) and
+major companies to design innovative devices and to enter new, low and
+medium volume markets.
+
+The objective of COACH is to provide an integrated design flow, based on the
+SoCLib infrastructure~\cite{soclib}, and optimized for the design of
+multi-processors digital systems targeting FPGA devices.
+Such digital systems are generally integrated
+into one or several chips, and there are two types of applications:
+They can be embedded (autonomous) applications
+such as personal digital assistants (PDA), ambiant computing components,
+or wireless sensor networks (WSN).
+They can also be extension boards connected to a PC to accelerate a specific computation,
+as in High-Performance Computing (HPC) or High-Speed Signal Processing (HSSP).
+
+The COACH environment will integrate several hardware and software technologies:
+
+Design Space Exploration:
+ The COACH environment will allow to describe an application as a process
+ network i.e. a set of tasks communicating through FIFO channels.
+ COACH will allow to map the application on a shared-memory, MPSoC architecture.
+ It will permit to easily explore the design space to help the system designer
+ to define the proper hardware/software partitioning of the application.
+ For each point in the design space, metrics such as throughput, latency, power
+ consumption, silicon area, memory allocation and data locality will be provided.
+ These criteria will be evaluated by using the SoCLib virtual prototyping infrastructure
+ and high-level estimation methodologies.
+
+Hardware Accelerators Synthesis (HAS):
+ COACH will allow the automatic generation of hardware accelerators when required.
+ Hence, High-Level Synthesis (HLS) tools, Application Specific Instruction Processor
+ (ASIP) design environment and source-level transformation tools (loop transformations
+ and memory optimisation) will be provided.
+ This will allow further exploration of the micro-architectural design space.
+ HLS tools are sensitive to the coding style of the input specification and the domain
+ they target (control vs. data dominated).
+ The HLS tools of COACH will support a common language and coding style to avoid
+ re-engineering by the designer.
+
+Platform based design:
+ COACH will handle both Altera and Xilinx FPGA devices.
+ COACH will define architectural templates that can be customized by adding
+ dedicated coprocessors and ASIPs and by fixing template parameters such as
+ the number of embedded processors, the number of sizes of embedded memory banks
+ or the embedded the operating system.
+ However, the specification of the application will be independant of both the
+ architectural template and the target FPGA device.
+ Basically, the following three architectural templates will be provided:
+ - A Neutral architectural template based on the SoCLib IP core library and the
+ VCI/OCP communication infrastructure.
+ - An Altera architectural template based on the Altera IP core library, the
+ AVALON system bus and the NIOS processor.
+ - A Xilinx architectural template based on the Xilinx IP core library, the PLB
+ system bus and the Microblaze processor.
+
+Hardware/Software communication middleware:
+ COACH will implement an homogeneous HW/SW communication infrastructure and
+ communication APIs (Application Programming Interface), that will be used for
+ communications between software tasks running on embedded processors and
+ dedicated hardware coprocessors.
+
+The COACH design flow will be dedicated to system designers, and will as
+much as possible hide the hardware characteristics to the end-user.
+
+To reach this ambitious goal, the project will rely on the experience and the
+complementariness of partners in the following domains:
+Operating system and communication middleware (Tima, Lip6),
+MPSoC architectures (Tima, Lab-Sticc, Lip6),
+ASIP architectures (Inria/Cairn),
+High Level Synthesis (Tima, Lab-Sticc, Lip6), and compilation (Ens-Lyon/Lip).
+
+The COACH project does not start from scratch.
+It stronly relies on the SoCLib virtual prototyping platform for prototyping,
+(DSX, component library), operating systems (MUTEKH, DNA/OS).
+It also leverages on several existing technologies:
+on the GAUT and UGH tools for HLS,
+on the ROMA project for ASIP,
+on the SYNTOL and BEE tools for source-level analysis and transformations
+and on the Xilinx and Altera IP core libraries.
+Finally it will use the Xilinx and Altera logic and physical synthesis
+tools to generate the FPGA configuration bitstreams.
+
+The COACH proposal has been prepared during one year by a technical working group
+involving the 5 academic partners (one monthly meeting from january 2009 to february
+2010). The objective was to analyse the issues of integrating
+and enhancing the existing tools and tecnnologies into a unique framework.
+Most of the general software architecture of the proposed design flow (including the
+exchange format specification) has been define by this working group.
+Because the COACH project leanes on the ANR SoCLib platform, it may be described as an
+extension of the SoCLib platform.
+
+Two major FPGA companies are involved in the project: Xilinx will contribute
+as a contractual partner providing documentation and manpower; Altera will contribute as
+a supporter, providing documentation and development boards. These two companies are strongly motivated
+to help the COACH project to generate efficient bitsreams for both FPGA families.
+The role of the industrial partners \bull, \thales, \navtel and \zied is to provide
+real use cases to benchmark the COACH design environment and to analyze the designer productivity
+improvements.
+
+Following the general policy of the SoCLib platform, the COACH project will be an open
+infrastructure, available in the framework of the SoCLib server.
+The architectural templates, and the COACH software tools will be distributed under the
+GPL license. The VHDL synthesizable models for the neutral architectural template (SoCLib
+IP core library) will be freely available for non commercial use. For industrial exploitation
+the technology providers are ready to propose commercial licenses, directly to the end user,
+or through a third party.
+
+Finally, the COACH project is already supported by a large number of PMEs, as demonstrated by the
+"letters of interest", that have collected during the preparation of the project :
+- ADACSYS
+- MDS
+- INPIXAL
+- CAMKA System
+- ATEME
+- ALSIM
+- SILICOMP-AQL
+- ABOUND Logic
+- EADS-ASTRIUM
Index: /anr-2010/coach_objectifs.txt
===================================================================
--- /anr-2010/coach_objectifs.txt (revision 274)
+++ /anr-2010/coach_objectifs.txt (revision 274)
@@ -0,0 +1,30 @@
+
+Embedded systems (SoC and MPSoC) became an inevitable evolution in the microelectronic industry. Due to the exploding fabrication costs, the ASIC technology (Application Specific Integrated Circuit) is not an option for SMEs (Small and Medium Enterprises). Fortunately, the new FPGA (Field Programmable Gate Array) components, such as the Virtex5 family from \xilinx, or the Stratix4 family from \altera can implement a complete multi-processor architecture on a single device. But the design of embedded system is a long and complex task that requires expertise in software, software/hardware partionning, operating system, hardware design, VHDL/Verilog modeling. Only very few SMEs have these multiple expertises and are present on the embedded system market.
+
+The major objective of COACH is to provide to SMEs an open-source framework to design embedded systems on FPGA devices. This framework will be dedicated to system-level designer.
+
+The second objective of COACH is HPC. In HPC (High Performance Computing), the targeted application is running on a PC. The COACH framework will help the system designer to accelerate an HPC applcation by migrating critical parts into a SoC embedded into an FPGA device plugged to the PC PCI/X bus. This will allow SMEs to enter HPC market for applications that cannot be accelerated by he current GPU based solutions.
+
+To reach these objectives, the key scientific and technical issues are :
+
+1) Design Space Exploration by Virtual Prototyping
+
+The COACH environment will allow to easily map a parallel application (described as an abstract process network Model of Computation) on a shared-memory, MPSoC architecture. COACH will permit the system designer to explore the design space, and to define the best hardware/software partitioning of the application.
+
+2) Integration of system-level modeling and HLS tools
+
+COACH will support the automated generation of hardware accelerators when required by using High-Level Synthesis (HLS) tools. These HLS tools will be fully integrated into the system-level design environment. Moreover, COACH will support both data and control dominated applications, and the HLS tools of COACH will support a common language and coding style to avoid re-engineering by the designer.
+
+3) High-level code transformation
+
+COACH will allow to optimize the memory usage, to enhance the parallelism through loop transformations and parallelization. The challenge is to identify the coarse grained parallelism and to generate, from a sequential algorithm, applications containing multiple communicating tasks. Coach will adapt techniques which were developed in the 1990 for the construction of distributed programs. However, in the context of HLS, there are several original problems to be solved, related to the FIFO communication channels and with memory optimization. COACH will support code transformation by providing a source to source C2C tool.
+
+4) Unified Hardware/Software communication middleware
+
+COACH will rely on he SoCLib experience to implement an unified hardware/software communication infrastructure and communication APIs (Application Programming Interface), to support communications between software tasks running on embedded processors and dedicated hardware coprocessors. The main issue here is to support easy migration
+from a software implementation to an hardware implementation.
+
+5) Processor customization
+
+ASIP (Application Specific Instruction Processor) design will be addressed by the COACH project. COACH will allow system designers to explore the various level of interactions between the original CPU micro-architecture and its extension. It will also allow to retarget the compiler instruction-selection pass. Finally, COACH will integrate ASIP synthesis in a complete System-level design framework.
+
Index: /anr-2010/coach_retombees.txt
===================================================================
--- /anr-2010/coach_retombees.txt (revision 274)
+++ /anr-2010/coach_retombees.txt (revision 274)
@@ -0,0 +1,15 @@
+
+Today, FPGAs become important actors in the computational domain that was originally dominated by microprocessors and ASICs. Just like microprocessors, FPGA based systems can be reprogrammed on a per-application basis. For many applications, FPGAs offer significant performance benefits over microprocessors implementation. There is still a performance degradation of one order of magnitude versus an equivalent ASIC implementations, but low cost (500 euros to 10K euros), fast time-to-market and flexibility of FPGAs make them an attractive choice for low-to-medium volume applications.
+
+Since their introduction in the mid eighties, FPGAs evolved from a simple, low-capacity gate array to devices (Altera STRATIX III, xilinx Virtex V) that provide a mix of coarse-grained data path units, memory blocks, microprocessor cores, on chip A/D conversion, and gate counts by millions. This high logic capacity allows to implement complex systems like multi-processors platform with application dedicated coprocessors. This market is in significant expansion and is estimated to 914 M$ in 2012.
+
+Nowadays, there are no commercial or academic tools covering the whole design flow from the system level specification to the bitstream generation neither for embedded system design nor for HPC.
+
+The COACH project proposes an open-source framework for mapping multi-tasks software applications on Field Programmable Gate Array circuits (FPGA). It aims to propose solutions to the societal/economical challenges by providing SMEs novel design capabilities enabling them to increase their design productivity with design exploration and synthesis methods that are placed on top of the state-of-the-art methods.
+
+We believe that the combination of a design environment dedicated to software developpers and FPGA targets, will allow small and even very small companies to propose embedded system and accelerating solutions for standard software applications with attractive and competitive prices. This new market may explode in the same way as the micro-computer market in the eighties, whose success was due to the low cost of the first micro-processors (compared to main frames) and the advent of high level programming languages which allowed a high number of programmers to launch start-ups in software engineering.
+
+The large number of SMEs that have expressed interest for the COACH project (ten letters of interest collected
+in one month) demonstrates that theres is a real need for this type of tools.
+
+The COACH project can have a strong economical impact.
Index: /anr-2010/coach_summary.txt
===================================================================
--- /anr-2010/coach_summary.txt (revision 274)
+++ /anr-2010/coach_summary.txt (revision 274)
@@ -0,0 +1,36 @@
+The objective of COACH is to provide an integrated design flow, based on the SoCLib virtual prototyping infrastructure, and optimized for the design of multi-processors digital systems targeting FPGA devices. Such digital systems are generally integrated into one or several chips, and there are two types of applications:
+- They can be embedded (autonomous) applications such as personal digital assistants (PDA), ambiant computing components, or wireless sensor networks (WSN).
+- They can also be extension boards connected to a PC to accelerate a specific computation, as in High-Performance Computing (HPC) or High-Speed Signal Processing (HSSP).
+
+The COACH project will provide three hardware architectural templates:
+
+ - A Neutral architectural template based on the SoCLib IP core library and the VCI/OCP communication infrastructure.
+ - An Altera architectural template based on the Altera IP core library, the AVALON system bus and the NIOS processor.
+ - A Xilinx architectural template based on the Xilinx IP core library, the PLB system bus and the Microblaze processor.
+
+The COACH design flow will be dedicated to system designers, and will as much as possible hide the hardware characteristics to the end-user. The specification of the application will be independant from the architectural template and the target FPGA device.
+
+To reach this ambitious goal, the project will rely on the experience and the complementariness of partners in the following domains:
+- Operating system and communication middleware (Tima, Lip6)
+- MPSoC architectures (Tima, Lab-Sticc, Lip6)
+- ASIP architectures (Inria/Cairn)
+- High Level Synthesis (Tima, Lab-Sticc, Lip6), and compilation (Ens-Lyon/Lip)
+
+The COACH project does not start from scratch. It stronly relies on the SoCLib virtual prototyping platform for prototyping, (DSX, component library), operating systems (MUTEKH, DNA/OS). It also leverages on several existing technologies: the GAUT and UGH tools for HLS, the ROMA project for ASIP, the SYNTOL and BEE tools for source-level analysis and transformations, and the Xilinx and Altera IP core libraries. Finally it will use the Xilinx and Altera logic and physical synthesis tools to generate the FPGA configuration bitstreams.
+
+Two major FPGA companies are involved in the project: Xilinx will contribute as a contractual partner providing documentation and manpower; Altera will contribute as a supporter, providing documentation and development boards. These two companies are strongly motivated to help the COACH project to generate efficient bitsreams for both FPGA families.
+
+The role of the industrial partners Bull, Thales, Navtel and Flexras is to provide real use cases to benchmark the COACH design environment and to evaluate the designer productivity improvements.
+
+Following the general policy of the SoCLib platform, the COACH project will be an open infrastructure, available in the framework of the SoCLib server. The architectural templates, and the COACH software tools will be distributed under the GPL license. The VHDL synthesizable models for the neutral architectural template (SoCLib IP core library) will be freely available for non commercial use. For industrial exploitation the technology providers are ready to propose commercial licenses, directly to the end user, or through a third party.
+
+Finally, the COACH project is already supported by a large number of PMEs, as demonstrated by the "letters of interest", that have collected during the preparation of the project :
+ - ADACSYS
+ - MDS
+ - INPIXAL
+ - CAMKA System
+ - ATEME
+ - ALSIM
+ - SILICOMP-AQL
+ - ABOUND Logic
+ - EADS-ASTRIUM
Index: /anr-2010/coach_summary_fr.txt
===================================================================
--- /anr-2010/coach_summary_fr.txt (revision 274)
+++ /anr-2010/coach_summary_fr.txt (revision 274)
@@ -0,0 +1,39 @@
+L'objectif du projet COACH est de fournir un environnement complet de conception de systèmes numériques multi-processeurs qui cible les circuits FPGA. Cet environnement sera basé sur la plate-forme SocLib de prototypage virtuel. Ces systèmes numériques sont en général intégrés dans un ou plusieurs circuits et il y a principalement deux types d'applications:
+ - des applications autonomes comme celles embarquées dans des PDA, des composants domotiques ou des réseaux de capteurs;
+ - des cartes d'extension connectées à un PC pour du calcul haute performance (HPC) ou du traitement de signal haute performance (HSSP).
+
+Le projet COACH fournira trois patrons architecturaux.
+ - Le patron architectural neutre qui sera basé sur la bibliothèque d'IP cores de
+ SocLib et sur l'infrastructure de communication VCI/OCP.
+ VCI/OCP communication infrastructure.
+ - Le patron architectural Altera qui sera basé sur la bibliothèque d'IP cores d'Altera,
+ le bus AVALON et le processeur NIOS.
+ - Le patron architectural Xilinx qui sera basé sur la bibliothèque d'IP cores de Xilinx,
+ le bus PLB et le processeur Microblaze.
+
+L'environnement de conception COACH sera conçu pour être utilisable pas un concepteur système. Pour cela il masquera aux utilisateurs les caractéristiques matérielles fines. De plus les descriptions des applications seront totalement indépendante des patrons architecturaux ainsi que du circuit FPGA visé.
+
+Pour atteindre ces objectifs ambitieux, le projet repose sur la complémentarité et l'expérience des partenaires dans les domaines suivants:
+ - système d'exploitation et middleware de communication (Tima, Lip6),
+ - architectures MPSoC (Tima, Lab-Sticc, Lip6),
+ - architectures ASIP (Inria/Cairn),
+ - synthèse de haut niveau (Tima, Lab-Sticc, Lip6), et compilation (Ens-Lyon/Lip).
+
+Le projet COACH ne démarre pas de rien mais s'appuie fortement sur la plate-forme SocLib (DSX, bibliothèque de composants), sur les systèmes d'exploitation (MUTEKH, DNA/OS). Il tirera également profit de plusieurs outils existants: les outils UGH et GAUT pour la synthèse de haut niveau, le projet ROMA pour les processeurs à instructions spécifiques (ASIP), les outils SYNTOL et BEE pour les transformations et l'analyse au niveau source, les bibliothèques de composants d'Altera et Xilinx. Enfin il utilisera les outils de synthèse logique et physique d'Altera et de Xilinx pour générer les bitstreams de configuration des FPGA.
+
+Les deux plus grandes sociétés du domaine des FPGA sont impliquées dans le projet. Xilinx est partenaire du projet. Altera contribue au projet en fournissant au projet de la documentation et des cartes de développement. Ces deux sociétés sont très motivées à aider ce projet pour générer des bitstreams optimisés pour leurs circuits FPGA.
+
+Le rôle des partenaires industriels Bull, Thales, Navtel and Flexras est de fournir des applications industrielles pour évaluer les performances de l'environnement COACH ainsi que mesurer les gains de productivité obtenus.
+
+Conformément à la politique générale de la plate-forme SocLib, le projet COACH sera sous licence libre, et disponible sur le serveur de la plate-forme SocLib. Les patrons architecturaux et les logiciels seront distribués sous la licence GPL, les modèles en VHDL synthétisable des composants du patron architectural neutre seront distribués aussi librement mais leur utilisation sera restreinte à un usage non commercial. Pour une utilisation commerciale de ces composants, les concepteurs de ces modèles fourniront des licences commerciales soit directement à l'utilisateur final soit à une tierce partie.
+
+Finalement, le projet COACH est soutenu par un grand nombre de PME comme le montrent les lettres d'intérêt qui ont été collectées:
+ - ADACSYS
+ - MDS
+ - INPIXAL
+ - CAMKA System
+ - ATEME
+ - ALSIM
+ - SILICOMP-AQL
+ - ABOUND Logic
+ - EADS-ASTRIUM
Index: /anr-2010/coach_tasks.txt
===================================================================
--- /anr-2010/coach_tasks.txt (revision 274)
+++ /anr-2010/coach_tasks.txt (revision 274)
@@ -0,0 +1,38 @@
+
+
+The project is split into 8 tasks described in short below:
+
+T1) Project management
+
+This task relates to the monitoring of the COACH project. It includes a monthy meeting of the steering committee.
+
+T2) Backbone
+
+This task tackles the fundamental points of the project that are the defintion of the COACH inputs and outputs, the inter-tools exchange formats, the three supported architectural templates, the hardware/software communication middleware, and the general design flow. This task contains also the development of the associated tools.
+
+T3) System generation
+
+This task addresses the virtual prototyping and the generation of the final bitstream (including hardware and
+embedded software).
+
+T4) Hardware accelerator synthesis front-end
+
+This task mainly focusses on four functionalities: optimization of the memory usage, parallelism enhancement through loop transformations, coarse grain parallelization and ASIP generation.
+
+T5) Hardware accelerator synthesis back-end
+
+This task groups two functionalities: High-Level Synthesis of data dominated coprocessors and High Level Synthesis of control dominated coprocessors. It contains also the development of a a generic retiming mechanism
+to adapt the coprocessors to the system frequency.
+
+T6) PC/FPGA communication middleware
+
+This task is mainly dedicated to HPC. Subtasks are mainly the partitioning evaluation tool, the software drivers for both PC and FPGA-SoC sides, the hardware communication components and the support for dynamic partial reconfiguration.
+
+T7) Industrial demonstrators
+
+This task groups the demonstrators of the COACH project. Most subtasks are industrial applications that will be used to evaluate the COACH framework. Another subtask is to evaluate the interfacing between the COACH framework and a proprietary system-level design tool (Thales). A third subtask is to evaluate the COACH framework on a third embedded FPGA architecture (Flexras).
+
+T8) Dissemination
+
+This task is related to the dissemination of the project results. It mainly consists of the production of the 4 COACH releases and the publication on the WEB server, the production of tutorials and user manuals, the publication of research papers in international journals and conferences and the organization of workshops and tutorials in international conferences.
+
Index: /anr-2010/dependence-task-h.fig
===================================================================
--- /anr-2010/dependence-task-h.fig (revision 274)
+++ /anr-2010/dependence-task-h.fig (revision 274)
@@ -0,0 +1,59 @@
+#FIG 3.2 Produced by xfig version 3.2.5
+Landscape
+Center
+Metric
+Letter
+100.00
+Single
+-2
+1200 2
+2 1 0 1 0 7 100 -1 -1 0.000 0 0 -1 1 0 2
+ 0 0 1.00 60.00 120.00
+ -659 1954 -209 1459
+2 1 0 1 0 7 100 -1 -1 0.000 0 0 -1 1 0 2
+ 0 0 1.00 60.00 120.00
+ -681 690 -231 1275
+2 2 1 1 0 7 80 -1 -1 4.000 0 0 -1 0 0 5
+ -1665 2475 1800 2475 1800 225 -1665 225 -1665 2475
+2 2 1 1 0 7 70 -1 -1 4.000 0 0 -1 0 0 5
+ -2925 2700 2115 2700 2115 0 -2925 0 -2925 2700
+2 1 0 1 0 7 70 -1 -1 0.000 0 0 -1 1 0 2
+ 0 0 1.00 60.00 120.00
+ 2160 2160 2610 2160
+2 2 0 1 0 7 60 -1 -1 0.000 0 0 -1 0 0 5
+ -3150 2925 3735 2925 3735 -180 -3150 -180 -3150 2925
+2 1 0 1 0 7 80 -1 -1 0.000 0 0 -1 1 0 2
+ 0 0 1.00 60.00 120.00
+ 2160 855 2610 855
+2 1 0 1 0 7 80 -1 -1 0.000 0 0 -1 1 0 2
+ 0 0 1.00 60.00 120.00
+ 2925 1080 2925 1935
+2 2 0 1 0 7 70 -1 -1 0.000 0 0 -1 0 0 5
+ 2610 1935 3240 1935 3240 2385 2610 2385 2610 1935
+2 2 0 1 0 7 90 -1 -1 0.000 0 0 -1 0 0 5
+ 2610 630 3240 630 3240 1080 2610 1080 2610 630
+2 2 0 1 0 7 100 -1 -1 0.000 0 0 -1 0 0 5
+ 855 1125 1485 1125 1485 1575 855 1575 855 1125
+2 2 0 1 0 7 100 -1 -1 0.000 0 0 -1 0 0 5
+ -225 1125 405 1125 405 1575 -225 1575 -225 1125
+2 2 0 1 0 7 100 -1 -1 0.000 0 0 -1 0 0 5
+ -1305 1710 -675 1710 -675 2160 -1305 2160 -1305 1710
+2 2 0 1 0 7 100 -1 -1 0.000 0 0 -1 0 0 5
+ -1305 495 -675 495 -675 945 -1305 945 -1305 495
+2 2 0 1 0 7 80 -1 -1 0.000 0 0 -1 0 0 5
+ -2700 1125 -2070 1125 -2070 1575 -2700 1575 -2700 1125
+2 1 0 4 0 7 90 -1 -1 0.000 0 0 -1 1 0 2
+ 0 0 1.00 60.00 120.00
+ -2070 1350 -1620 1350
+2 1 0 4 0 7 100 -1 -1 0.000 0 0 -1 1 0 10
+ 0 0 1.00 60.00 120.00
+ 405 1350 450 1350 540 1350 585 1350 630 1350 675 1350
+ 720 1350 765 1350 810 1350 855 1350
+4 0 0 70 -1 18 16 0.0000 4 195 315 3330 90 T1\001
+4 1 0 90 -1 18 16 0.0000 4 195 315 2925 945 T7\001
+4 1 0 70 -1 18 16 0.0000 4 195 315 2925 2250 T8\001
+4 1 0 100 -1 18 16 0.0000 4 195 315 1170 1440 T6\001
+4 1 0 100 -1 18 16 0.0000 4 195 315 90 1440 T3\001
+4 1 0 100 -1 18 16 0.0000 4 195 315 -990 2025 T4\001
+4 1 0 100 -1 18 16 0.0000 4 195 315 -990 810 T5\001
+4 1 0 80 -1 18 16 0.0000 4 195 315 -2385 1440 T2\001
Index: /anr-2010/flow.fig
===================================================================
--- /anr-2010/flow.fig (revision 274)
+++ /anr-2010/flow.fig (revision 274)
@@ -0,0 +1,186 @@
+#FIG 3.2 Produced by xfig version 3.2.5b
+Landscape
+Center
+Inches
+Letter
+100.00
+Single
+-2
+1200 2
+5 1 1 1 0 7 50 -1 -1 4.000 0 0 1 0 10197.794 13038.971 5400 2700 6750 2175 10650 1650
+ 1 1 1.00 60.00 120.00
+5 1 1 1 0 7 50 -1 -1 4.000 0 0 1 0 10745.564 6247.984 8250 4050 9750 3075 10875 2925
+ 1 1 1.00 60.00 120.00
+5 1 1 1 0 7 50 -1 -1 4.000 0 1 1 0 9862.500 2550.000 9375 4275 10350 4275 10950 3975
+ 1 1 1.00 60.00 120.00
+5 1 1 1 0 7 50 -1 -1 4.000 0 1 1 0 9315.226 707.707 8775 5100 10575 4950 12300 3975
+ 1 1 1.00 60.00 120.00
+5 1 0 2 0 7 50 -1 -1 0.000 0 1 1 0 8562.500 4437.500 8850 4950 9075 4725 9150 4425
+ 1 1 2.00 60.00 120.00
+6 4275 2475 6675 4950
+2 4 0 2 0 7 50 -1 -1 0.000 0 0 7 0 0 5
+ 6450 3375 4500 3375 4500 2700 6450 2700 6450 3375
+2 4 0 2 0 7 50 -1 -1 0.000 0 0 7 0 0 5
+ 6450 4725 4500 4725 4500 4050 6450 4050 6450 4725
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
+ 1 1 3.00 60.00 120.00
+ 1 1 3.00 60.00 120.00
+ 5475 3375 5475 4050
+2 4 0 2 0 7 50 -1 -1 0.000 0 0 7 0 0 5
+ 6600 4875 4350 4875 4350 2550 6600 2550 6600 4875
+4 0 0 50 -1 2 16 0.0000 4 255 1815 4650 3075 Application PC\001
+4 0 0 50 -1 2 16 0.0000 4 255 1950 4575 4425 Application SoC\001
+-6
+6 1725 3300 3375 4275
+2 4 0 2 0 7 50 -1 -1 0.000 0 0 7 0 0 5
+ 3300 4200 1800 4200 1800 3375 3300 3375 3300 4200
+4 0 0 50 -1 2 16 0.0000 4 195 585 2325 3750 HPC\001
+4 0 0 50 -1 2 16 0.0000 4 255 1335 1950 4050 application\001
+-6
+6 7500 975 9750 3675
+6 7725 1125 9525 3225
+6 7725 1125 8175 2775
+6 7800 1275 8100 2175
+4 1 0 50 -1 2 16 0.0000 4 195 165 7950 1500 P\001
+4 1 0 50 -1 2 16 0.0000 4 195 195 7950 1725 R\001
+4 1 0 50 -1 2 16 0.0000 4 195 225 7950 1950 O\001
+4 1 0 50 -1 2 16 0.0000 4 195 195 7949 2175 C\001
+-6
+2 2 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 7800 1200 8100 1200 8100 2700 7800 2700 7800 1200
+-6
+6 8175 1125 8625 2775
+6 8250 1275 8550 1950
+4 1 0 50 -1 2 16 0.0000 4 195 195 8400 1500 R\001
+4 1 0 50 -1 2 16 0.0000 4 195 195 8400 1725 A\001
+4 1 0 50 -1 2 16 0.0000 4 195 255 8400 1950 M\001
+-6
+2 2 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 8250 1200 8550 1200 8550 2700 8250 2700 8250 1200
+-6
+6 8625 1125 9075 2775
+2 2 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 8700 1200 9000 1200 9000 2700 8700 2700 8700 1200
+4 1 0 50 -1 2 16 0.0000 4 195 105 8850 1500 I\001
+4 1 0 50 -1 2 16 0.0000 4 195 225 8850 1725 O\001
+-6
+6 7725 2775 9525 3225
+2 2 0 2 0 7 50 -1 -1 0.000 0 0 7 0 0 5
+ 7800 2850 9450 2850 9450 3150 7800 3150 7800 2850
+4 1 0 50 -1 2 16 0.0000 4 195 540 8625 3075 BUS\001
+-6
+-6
+2 4 0 2 0 7 50 -1 -1 0.000 0 0 7 0 0 5
+ 9675 3600 9675 1050 7575 1050 7575 3600 9675 3600
+2 1 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 2
+ 7575 3300 9675 3300
+4 1 0 50 -1 2 16 0.0000 4 195 1080 8625 3525 Platform\001
+-6
+6 10575 2250 12825 4950
+6 10800 2400 12600 4500
+6 10800 2400 11250 4050
+6 10875 2550 11175 3450
+4 1 0 50 -1 2 16 0.0000 4 195 165 11025 2775 P\001
+4 1 0 50 -1 2 16 0.0000 4 195 195 11025 3000 R\001
+4 1 0 50 -1 2 16 0.0000 4 195 225 11025 3225 O\001
+4 1 0 50 -1 2 16 0.0000 4 195 195 11024 3450 C\001
+-6
+2 2 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 10875 2475 11175 2475 11175 3975 10875 3975 10875 2475
+-6
+6 11250 2400 11700 4050
+6 11325 2550 11625 3225
+4 1 0 50 -1 2 16 0.0000 4 195 195 11475 2775 R\001
+4 1 0 50 -1 2 16 0.0000 4 195 195 11475 3000 A\001
+4 1 0 50 -1 2 16 0.0000 4 195 255 11475 3225 M\001
+-6
+2 2 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 11325 2475 11625 2475 11625 3975 11325 3975 11325 2475
+-6
+6 11700 2400 12150 4050
+2 2 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 11775 2475 12075 2475 12075 3975 11775 3975 11775 2475
+4 1 0 50 -1 2 16 0.0000 4 195 105 11925 2775 I\001
+4 1 0 50 -1 2 16 0.0000 4 195 225 11925 3000 O\001
+-6
+6 12150 2400 12600 4050
+6 12225 2475 12525 3825
+4 1 0 50 -1 2 16 0.0000 4 195 165 12375 3150 P\001
+4 1 0 50 -1 2 16 0.0000 4 195 195 12375 3375 R\001
+4 1 0 50 -1 2 16 0.0000 4 195 225 12375 3600 O\001
+4 1 0 50 -1 2 16 0.0000 4 195 195 12374 3825 C\001
+4 1 0 50 -1 2 16 0.0000 4 195 225 12375 2925 O\001
+4 1 0 50 -1 2 16 0.0000 4 195 195 12375 2700 C\001
+-6
+2 2 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 12225 2475 12525 2475 12525 3975 12225 3975 12225 2475
+-6
+6 10800 4050 12600 4500
+2 2 0 2 0 7 50 -1 -1 0.000 0 0 7 0 0 5
+ 10875 4125 12525 4125 12525 4425 10875 4425 10875 4125
+4 1 0 50 -1 2 16 0.0000 4 195 540 11700 4350 BUS\001
+-6
+-6
+2 4 0 2 0 7 50 -1 -1 0.000 0 0 7 0 0 5
+ 12750 4875 12750 2325 10650 2325 10650 4875 12750 4875
+2 1 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 2
+ 10650 4575 12750 4575
+4 1 0 50 -1 2 16 0.0000 4 195 1080 11700 4800 Platform\001
+-6
+6 11100 300 12375 900
+4 0 0 50 -1 2 16 0.0000 4 255 1395 11100 525 Application\001
+4 0 0 50 -1 2 16 0.0000 4 255 1425 11100 825 compilation\001
+-6
+6 1725 4650 3375 5625
+2 4 0 2 0 7 50 -1 -1 0.000 0 0 7 0 0 5
+ 3300 5550 1800 5550 1800 4725 3300 4725 3300 5550
+4 0 0 50 -1 2 16 0.0000 4 195 1245 2025 5100 Embedded\001
+4 0 0 50 -1 2 16 0.0000 4 255 1335 1950 5400 application\001
+-6
+1 4 0 2 0 7 50 -1 -1 0.000 1 0.0000 8595 5027 228 228 8367 5027 8823 5027
+1 4 0 2 0 7 50 -1 -1 0.000 1 0.0000 8103 4200 228 228 7875 4200 8331 4200
+1 4 0 2 0 7 50 -1 -1 0.000 1 0.0000 9118 4213 228 228 8890 4213 9346 4213
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 2.00 60.00 120.00
+ 6600 4425 7650 4425
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 2.00 60.00 120.00
+ 3300 3750 4350 3750
+2 1 1 2 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 7050 150 7050 6450
+2 1 1 2 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 10125 150 10125 6450
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
+ 1 1 2.00 60.00 120.00
+ 5475 6450 5475 4875
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
+ 1 1 2.00 60.00 120.00
+ 11700 6450 11700 4875
+2 4 0 2 0 7 50 -1 -1 0.000 0 0 7 0 0 5
+ 12750 1950 10650 1950 10650 1275 12750 1275 12750 1950
+2 1 1 2 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 3750 150 3750 6450
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 2.00 60.00 120.00
+ 3300 5175 7650 5175
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 2.00 60.00 120.00
+ 8925 4200 8325 4200
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
+ 1 1 2.00 60.00 120.00
+ 8550 6450 8550 5775
+2 4 0 2 0 7 50 -1 -1 0.000 0 0 7 0 0 5
+ 9600 5775 7650 5775 7650 3900 9600 3900 9600 5775
+2 1 1 2 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 7650 5325 9600 5325
+4 0 0 50 -1 2 16 0.0000 4 195 1305 11100 1650 Executable\001
+4 0 0 50 -1 2 16 0.0000 4 255 1065 11250 6750 Running\001
+4 0 0 50 -1 2 16 0.0000 4 255 690 2250 675 Input\001
+4 0 0 50 -1 2 16 0.0000 4 255 1290 4800 675 HPC setup\001
+4 0 0 50 -1 2 16 0.0000 4 255 1305 8025 675 SoC design\001
+4 0 0 50 -1 2 12 0.0000 4 150 240 8475 5100 T0\001
+4 0 0 50 -1 2 12 0.0000 4 150 240 8025 4275 T1\001
+4 0 0 50 -1 2 12 0.0000 4 150 240 9000 4275 T2\001
+4 0 0 50 -1 2 16 0.0000 4 195 1905 7725 5625 Process network\001
+4 0 0 50 -1 2 16 0.0000 4 255 2535 4200 6750 Performance analysis\001
+4 0 0 50 -1 2 16 0.0000 4 255 2535 7350 6750 Performance analysis\001
Index: /anr-2010/gantt.l
===================================================================
--- /anr-2010/gantt.l (revision 274)
+++ /anr-2010/gantt.l (revision 274)
@@ -0,0 +1,895 @@
+%{
+#define COLOR_Milestone "gtcMilestone"
+#define COLOR_BOX_HEAVY "gtcBoxHeavy"
+#define COLOR_BOX_LIGHT "gtcBoxLight"
+
+#define PICT_TOPSEP 0.0
+#define PICT_BOTSEP 3.0
+#define PICT_LEFTSEP 2.0
+#define PICT_RIGHTSEP 3.0
+#define PICT_VSEP 2.0
+#define PICT_HSEP 2.0
+
+#define PICT_MONTHHEIGHT 5 // police height
+#define PICT_MONTHWIDTH (10./3.)
+
+#define TASK_VSEP 2
+#define TASK_BGC0 "gtcTaskBG0"
+#define TASK_BGC1 "gtcTaskBG1"
+#define TASK_TITLEHEIGHT 6.
+#define TASK_TITLEFONTHEIGHT 2.
+
+#define DELIVRABLE_VSEP 1
+#define DELIVRABLE_HEIGHT 3
+#define DELIVRABLE_LABELWIDTH 7.5
+#define DELIVRABLE_LABELHEIGHT DELIVRABLE_HEIGHT
+#define DELIVRABLE_TITLEWIDTH 38
+#define DELIVRABLE_TITLEHEIGHT DELIVRABLE_HEIGHT
+#define DELIVRABLE_BOXHEIGHT (DELIVRABLE_HEIGHT)
+
+char* task_names[] = {
+ 0,
+ "Project management",
+ "Backbone infrastructure",
+ "System generation",
+ "HAS front-end",
+ "HAS back-end",
+ "PC/FPGA communication middleware",
+ "Industrial demonstrators",
+ "Dissemination",
+ 0
+};
+struct partner_def { char *key, *name, *fnfull, *fnshort; } partner_table[] = {
+ { "UNKNOW" ,"relax" ,0 ,0 },
+ { "irisa" ,"irisa" ,"table_inria_cairn_full.tex" ,"table_inria_cairn_short.tex" },
+ { "lip" ,"lip" ,"table_inria_compsys_full.tex","table_inria_compsys_short.tex" },
+ { "tima" ,"tima" ,"table_tima_full.tex" ,"table_tima_short.tex" },
+ { "ubs" ,"ubs" ,"table_ubs_full.tex" ,"table_ubs_short.tex" },
+ { "upmc" ,"upmc" ,"table_upmc_full.tex" ,"table_upmc_short.tex" },
+ { "altera" ,"altera" ,"table_altera_full.tex" ,"table_altera_short.tex" },
+ { "xilinx" ,"xilinx" ,"table_xilinx_full.tex" ,"table_xilinx_short.tex" },
+ { "bull" ,"bull" ,"table_bull_full.tex" ,"table_bull_short.tex" },
+ { "thales" ,"thales" ,"table_thales_full.tex" ,"table_thales_short.tex" },
+ { "zied" ,"zied" ,"table_zied_full.tex" ,"table_zied_short.tex" },
+ { "navtel" ,"navtel" ,"table_navtel_full.tex" ,"table_navtel_short.tex" },
+ { 0 ,0 ,0 ,0 },
+};
+
+typedef struct _Tlivrable {
+ int tn,stn,dn,vn; // task, sub-task, number
+ char v; // 0, 1, 2, ..., F
+ char* kind;
+ char* title;
+ int bm,em; // mois de bebut et de fin
+ double hman[3]; // nombre de mh par an
+ int partner; // index dans partner_table
+ // these fields are filled by the program for data[tn][0][0][0]
+ double task_y; // top of task
+ double task_dy; // bot of task is task_y+task_dy
+ double task_y_del; // delivrables start at task_y+task_y_del
+ double nbma[3]; // durée en mois par annee
+ // these fields are filled by the program for data[tn][stn][dn][0]
+ struct _Tlivrable
+ **vers; // null termiated (vers[i] = &data[tn][stn][dn][i])
+ int nbvers; // nombre de vers
+ double height; // height of livrable
+ // int del_bm,del_em; // mois de bebut et de fin cummule
+ // these fields are filled by the program for all elements
+ int nbTitleLines;
+ char* titleLines[5]; // null termiated
+} Tlivrable;
+
+#define T_MAX 10
+#define S_MAX 10
+#define D_MAX 10
+#define V_MAX 10
+typedef struct _Tdata {
+ FILE* os;
+ Tlivrable* ls[T_MAX][S_MAX][D_MAX][V_MAX];
+} Tdata;
+Tdata data_org;
+Tdata* curr;
+
+Tdata* data_new(int *tnplus, int *tnmoins)
+{
+ int i,skip;
+ int tn,stn,dn,v;
+ Tdata* data = malloc(sizeof(*data));
+ memset(data,0,sizeof(*data));
+ for (tn=0 ; tntn ) {
+ skip=0;
+ break;
+ } } }
+ if (skip) continue;
+ // tnmoins treatment
+ skip = 0;
+ if (tnmoins!=0) {
+ for (i=0 ; tnmoins[i]!=-1 ; i++) {
+//fprintf(stderr,"i=%d data_org.ls[tn][stn][dn][v]->tn=%d tnmoins[i]=%d\n",i,data_org.ls[tn][stn][dn][v]->tn,tnmoins[i]);
+ if ( tnmoins[i]==data_org.ls[tn][stn][dn][v]->tn ) {
+ skip=1;
+ break;
+ } } }
+//fprintf(stderr,"selected: [tn][stn][dn][v]=%d,%d,%d,%d skip=%d\n",tn,stn,dn,v,skip);
+ if (skip) continue;
+ Tlivrable* l=malloc(sizeof(*l));
+ *l = *data_org.ls[tn][stn][dn][v];
+ data->ls[tn][stn][dn][v] = l;
+//fprintf(stderr,"selected: [tn][stn][dn][v]=%d,%d,%d,%d\n",tn,stn,dn,v);
+ }
+ return data;
+}
+
+int milestones[100];
+
+char* gen_label_base(char* buf,Tlivrable*p)
+ { if (p->dn >=0) sprintf(buf,"D%d%d%d",p->tn,p->stn,p->dn); else sprintf(buf,""); return buf; }
+char* gen_label_vers(char* buf,Tlivrable*p)
+ { if (p->nbvers<=1) strcpy(buf,""); else sprintf(buf,"V%c",p->v); return buf; }
+char* gen_label_full(char* buf,Tlivrable*p)
+ { char b[100],v[100]; gen_label_base(b,p); gen_label_vers(v,p);
+ sprintf(buf,"%s%s%s",b,*v?"-":"",v); return buf; }
+
+void print_put(double x,double y, const char* object)
+ { fprintf(curr->os,"\\put(%.2f,%.2f){%s}\n",x,y,object); }
+void print_hline(double x,double y, double len, const char* color)
+{
+ char object[1024];
+ if (color!=0) { fprintf(curr->os,"\\bgroup\\color{%s}\n",color); }
+ sprintf(object,"\\line(1,0){%.2f}",len);
+ print_put(x,y,object);
+ if (color!=0) { fprintf(curr->os,"\\egroup\n"); }
+}
+void print_vline(double x,double y, double len, const char* color)
+{
+ char object[1024];
+ if (color!=0) { fprintf(curr->os,"\\bgroup\\color{%s}\n",color); }
+ sprintf(object,"\\line(0,1){%.2f}",len);
+ print_put(x,y,object);
+ if (color!=0) { fprintf(curr->os,"\\egroup\n"); }
+}
+void print_box(
+ int filled, char* vers, // vers may be 0,
+ double x,double y, double dx, double dy,
+ const char* boxcolor, // may be 0 (default COLOR_BOX_HEAVY)
+ const char* bgcolor, // may be 0 (not set)
+ const char* textcolor // may be 0 (black)
+){
+ double tn=.4;
+ char object[1024];
+ if ( boxcolor==0 ) boxcolor = COLOR_BOX_HEAVY;
+ if ( filled==1 ) {
+ sprintf(object,
+ "\\fcolorbox{black}{%s}{\\makebox(%.2f,%.2f){}}",
+ boxcolor,dx-2-tn,dy-2-tn);
+ print_put(x,y+1,object);
+ } else {
+ double tn2=tn/2;
+ double e=.1;
+ fprintf(curr->os,"\\bgroup\\color{%s}\n",boxcolor);
+ fprintf(curr->os,"\\linethickness{%.2fmm}\n",tn);
+ print_hline(x+tn2-e ,y, dx ,0);
+ print_hline(x+tn2-e ,y+dy, dx ,0);
+ print_vline(x+tn-e ,y+e, dy-2*e ,0);
+ print_vline(x+dx-2*e,y+e, dy-2*e ,0);
+ fprintf(curr->os,"\\egroup\n");
+ }
+ if (vers) {
+ sprintf(object,"\\begin{tiny}\\textbf{%s}\\end{tiny}",vers);
+ print_put(x+1,y+.5,object);
+ }
+}
+
+void gen_titleLines(Tlivrable*p)
+{
+ const char* macro="\\ganttlf";
+ char* pc = p->title;
+ char* pc2;
+
+ if (pc==0) return;
+
+ while ( (pc2=strstr(pc,macro))!=0 ) {
+ char c = *pc2;
+ *pc2 = 0;
+ p->titleLines[p->nbTitleLines]=strdup(pc);
+ p->nbTitleLines+=1;
+ *pc2=c;
+ pc=pc2+strlen(macro);
+ }
+ p->titleLines[p->nbTitleLines]=strdup(pc);
+ p->nbTitleLines+=1;
+}
+%}
+
+%option noyywrap
+
+%%
+ int tn,stn,dn,v,bm,em; char* title; char* kind;
+ double an[3];
+ char* an_comment;
+ int partner;
+#.*\n ;
+T=[0-9]+ { tn=atoi(yytext+2); }
+S=[0-9]+ { stn=atoi(yytext+2); }
+D=[0-9]+ { dn=atoi(yytext+2); }
+D=none { dn=-2; }
+V=V[1-8F] { v=yytext[3]; }
+ML=[0-9]+ {
+ int i;
+ for (i=0 ; milestones[i]!=0 ; i++);
+ milestones[i] = atoi(yytext+3);
+ }
+BM=[0-9]+ { bm=atoi(yytext+3); }
+EM=[0-9]+ { em=atoi(yytext+3); }
+R=none { an[0]=0; an[1]=0; an[2]=0; an_comment=0; }
+R=[0-9:.]+ {
+ char tmp[1000];
+ int status = sscanf(yytext+2,"%lf:%lf:%lf:%s",an+0,an+1,an+2,tmp);
+ if (status<3) {
+ fprintf(stderr,
+ "%s: is not resource definition, expected format \"N:N:N\" (near D%d%d%d-V%c)\n",
+ yytext+2,tn,stn,dn,v);
+ an[0]=0; an[1]=0; an[2]=0; an_comment=0;
+ } else if (status==3) {
+ an_comment = 0;
+ } else
+ an_comment = strdup(tmp);
+ }
+PART="{"[^}]+"}" {
+ int i;
+ partner=-1;
+ for (i=0; partner_table[i].key!=0 ; i++) {
+ if (strstr(yytext,partner_table[i].key)!=0 ) {
+ partner=i;
+ break;
+ }
+ }
+ if ( partner==-1 ) {
+ fprintf(stderr,"%s: does not contains a partner key (near D%d%d%d-V%c)\n",
+ yytext+5,tn,stn,dn,v);
+ partner=0;
+ }
+ }
+KIND="{"[^}]+"}" {
+ yytext[yyleng-1]=0;
+ kind= strdup(yytext+6);
+ if ( strcmp(kind,"x")!=0 && strcmp(kind,"d")!=0 && strcmp(kind,"h")!=0 &&
+ strcmp(kind,"d+x")!=0 )
+ fprintf(stderr,"ERROR:D%d%d%d invalid KIND: %s\n",tn,stn,dn,kind);
+ }
+KIND="{}" {
+ yytext[yyleng-1]=0;
+ kind= strdup(yytext+6);
+ }
+TITLE=.*\n {
+ char* pc=yytext+6;
+ yytext[yyleng-1]=0;
+ while ( *pc==' ' || *pc=='\t' ) pc+=1;
+ title=strdup(pc);
+ Tlivrable* p= (Tlivrable*) calloc(sizeof(*p),1);
+ p->tn = tn;
+ p->stn = stn;
+ p->dn = dn;
+ p->v = v;
+ p->hman[0] = an[0];
+ p->hman[1] = an[1];
+ p->hman[2] = an[2];
+ p->partner = partner;
+ p->title = title;
+ p->bm = bm;
+ p->em = em;
+ p->kind = kind;
+ gen_titleLines(p);
+
+ for (v=0; data_org.ls[tn][stn][dn][v]!=0 ; v++);
+ data_org.ls[tn][stn][dn][v] = p;
+//fprintf(stderr,"ADDED: %d %d %d %d\n",tn,stn,dn,v);
+ tn=stn=dn=v=bm=em=0;
+ title=kind=0;
+ an[0]= an[1]=an[1]=0;
+ an_comment=0;
+ partner=0;
+ }
+[ \t\n] ;
+. { fprintf(stderr,"%c: unexpected value in anr.gantt file (near D%d%d%d-V%c)\n",
+ *yytext,tn,stn,dn,v); }
+%%
+
+void prepare0(Tdata* data)
+{
+int tn,stn,v;
+int i0,i1,i;
+ for (tn=0 ; tnls[tn][stn][i][0]); fprintf(stderr,"\n");
+ while (1) {
+ for (i0=0 ; i0ls[tn][stn][i0][0] == 0) break;
+ for (i1=i0+1 ; i1ls[tn][stn][i1][0] != 0) break;
+ if (i1>=D_MAX) break;
+ // shift
+ for (i=0 ; (i1+i)ls[tn][stn][i0+i][v] = data->ls[tn][stn][i1+i][v];
+ data->ls[tn][stn][i1+i][v] = 0;
+ }
+ }
+//fprintf(stderr,"AVANT:t=%d:%d:: ",tn,stn); for (i=0; ils[tn][stn][i][0]); fprintf(stderr,"\n");
+ }
+}
+void prepare1(Tdata* data)
+{
+int tn,dn,v;
+int i0,i1,i;
+ for (tn=0 ; tnls[tn][i][0][0]); fprintf(stderr,"\n");
+ while (1) {
+ for (i0=0 ; i0ls[tn][i0][0][0] == 0) break;
+ for (i1=i0+1 ; i1ls[tn][i1][0][0] != 0) break;
+//fprintf(stderr,"%d %d %d\n",tn,i0,i1);
+ if (i1>=S_MAX) break;
+ // shift
+ for (i=0 ; (i1+i)ls[tn][i0+i][dn][v] = data->ls[tn][i1+i][dn][v];
+ data->ls[tn][i1+i][dn][v] = 0;
+ }
+ }
+//fprintf(stderr,"APRES:t=%d:: ",tn,i0,i1); for (i=0; ils[tn][i][0][0]); fprintf(stderr,"\n");
+ }
+}
+void prepare2(Tdata* data)
+{
+int tn0,tn1,stn,dn,vn;
+int moved=1;
+ while (moved) {
+ moved=0;
+ for (tn0=0 ; tn0ls[tn0][0][0][0] == 0) break;
+ for (tn1=tn0+1 ; tn1ls[tn1][0][0][0] != 0) break;
+ if (tn1==T_MAX) break;
+ for (stn=0 ; stnls[tn0][stn][dn][vn] = data->ls[tn1][stn][dn][vn];
+ data->ls[tn1][stn][dn][vn] = 0;
+ }
+ moved=1;
+ }
+}
+
+void prepare3(Tdata* data)
+{
+int tn,stn,dn,vn;
+ for (tn=0 ; tnls[tn][stn][dn][0];
+ if (p==0) continue;
+ p->nbvers=0 ;
+ for (vn=0 ; vnls[tn][stn][dn][vn]!=0) p->nbvers+=1;
+ p->vers=(Tlivrable**)malloc(sizeof(*p->vers)*(p->nbvers+1));
+ for (vn=0 ; vnnbvers ; vn+=1) {
+ p->vers[vn] = data->ls[tn][stn][dn][vn];
+ data->ls[tn][stn][dn][vn]->nbvers = p->nbvers;
+ }
+ p->vers[vn] = 0;
+ p->height = 1.0*DELIVRABLE_HEIGHT;
+ if (p->nbTitleLines>=1) {
+ double h=0;
+ h += p->vers[p->nbvers-1]->nbTitleLines*DELIVRABLE_TITLEHEIGHT;
+ h += (p->vers[p->nbvers-1]->nbTitleLines-1)*(DELIVRABLE_TITLEHEIGHT/5.);
+ if ( h>p->height) p->height=h;
+ }
+ Tlivrable* lu= p->vers[p->nbvers-1];
+ int i;
+//fprintf(stderr,"--------------------\n");
+ for (i=0 ; inbvers ; i++) {
+ Tlivrable* l= p->vers[i];
+ double bm= l->bm;
+ double em= l->em;
+//fprintf(stderr," %d%d%d-V%c: bm=%2.f em=%2.f --> %2.1f %2.1f %2.1f\n",l->tn,l->stn,l->dn,l->v,bm,em, lu->nbma[0],lu->nbma[1],lu->nbma[2]);
+ if (bm<12 && em>0) {
+ lu->nbma[0] += (em>12?12:em)-bm;
+ bm=12;
+ }
+ if (bm<24 && em>12) {
+ lu->nbma[1] += (em>24?24:em)-bm;
+ bm=24;
+ }
+ if (bm<36 && em>24) {
+ lu->nbma[2] += em-bm;
+ }
+//fprintf(stderr," %d%d%d-V%c: bm=%2.f em=%2.f --> %2.1f %2.1f %2.1f %p\n",l->tn,l->stn,l->dn,l->v,bm,em, lu->nbma[0],lu->nbma[1],lu->nbma[2], lu);
+ }
+ }
+}
+
+double task_livrable_height(int tn, double* delivrable_y)
+{
+int stn,dn,nblivrables=0;
+double height=0;
+ height += TASK_TITLEHEIGHT ;
+ *delivrable_y = height;
+ for (stn=0 ; curr->ls[tn][stn][0][0]!=0 ; stn++)
+ for (dn=0 ; curr->ls[tn][stn][dn][0]!=0 ; dn++) {
+ if ( curr->ls[tn][stn][dn][0]->dn<0 ) continue;
+ nblivrables += 1;
+ height+=curr->ls[tn][stn][dn][0]->height;
+ }
+ height += DELIVRABLE_VSEP/2;
+ height += (nblivrables-1)*DELIVRABLE_VSEP;
+ height += DELIVRABLE_VSEP/2;
+ return height;
+}
+
+void task_box(double pictwidth)
+{
+ int tn;
+ for ( tn=0 ; curr->ls[tn][0][0][0]!=0 ; tn++ ) {
+ const char* color= (tn%2)!=0 ? TASK_BGC1 : TASK_BGC0 ;
+ fprintf(curr->os,
+ "\\put(%.2f,%.2f){\\fcolorbox{black}{%s}{\\makebox(%5.2f,%5.2f){}}}\n",
+ 0.0,curr->ls[tn][0][0][0]->task_y,
+ color,
+ pictwidth,curr->ls[tn][0][0][0]->task_dy
+ );
+ }
+}
+
+void month_grid(double x, double y, double dx, double dy)
+{
+ int i;
+ for (i=0 ; i<=36 ; i+=1,x+=PICT_MONTHWIDTH) {
+ if ( (i%3)!=0 ) continue;
+ fprintf(curr->os,
+ "\\put(%5.1f,%5.1f){\\line(0,1){%5.1f}}\\put(%5.1f,%5.1f){%d}\n",
+ x,y,dy-PICT_MONTHWIDTH-PICT_VSEP,
+ x-2,y+dy-PICT_MONTHHEIGHT,
+ i
+ );
+ }
+}
+
+void print_milestones(double x, double y, double dx, double dy)
+{
+ int i;
+ double tn=.3;
+ //x=x-tn/2;
+ fprintf(curr->os,"\\bgroup\n");
+ fprintf(curr->os,"\\color{red}\n");
+ fprintf(curr->os,"\\linethickness{%.2fmm}\n",tn);
+ for (i=0 ; milestones[i]!=0 ; i+=1) {
+ double xx= x + milestones[i]*PICT_MONTHWIDTH;
+ print_vline(xx,y,dy-PICT_MONTHWIDTH-PICT_VSEP,0);
+ char tmp[100];
+ sprintf(tmp,"M%d",i+1);
+ print_put(xx-2,y-3,tmp);
+ }
+ fprintf(curr->os,"\\egroup\n");
+}
+
+double delivrable(
+ double label_x, double box_x, double title_x,
+ double y,
+ int tn, int stn, int dn)
+{
+ Tlivrable* top=curr->ls[tn][stn][dn][0];
+ Tlivrable* last=curr->ls[tn][stn][dn][top->nbvers-1];
+ char tmp[1000],label[1000],title[1000];
+ double y0;
+ int v;
+ double label_dx = DELIVRABLE_LABELWIDTH ;
+ double label_dy = DELIVRABLE_LABELHEIGHT ;
+ double boxx,box_dx;
+ double box_dy = DELIVRABLE_BOXHEIGHT ;
+ double title_dx = DELIVRABLE_TITLEWIDTH ;
+ double title_dy = DELIVRABLE_TITLEHEIGHT ;
+
+//print_hline(0,y,180,0);
+ gen_label_base(label,top);
+ // y -= DELIVRABLE_HEIGHT;
+ y -= top->height ;
+//print_hline(0,y,180,0);
+ fprintf(curr->os,"%% Delivrable %s (tn=%d stn=%d dn=%d\n",label,tn,stn,dn);
+
+ // print label
+ //y0 = (DELIVRABLE_HEIGHT-DELIVRABLE_LABELHEIGHT)/2;
+ y0 = (top->height-DELIVRABLE_LABELHEIGHT)/2;
+ sprintf(tmp,"\\ganttlabelstyle{%s}",label);
+ print_put(label_x,y+y0,tmp);
+ // print title
+ if (last->nbTitleLines==1) {
+ y0 = (DELIVRABLE_HEIGHT-DELIVRABLE_TITLEHEIGHT)/2;
+ y0 += DELIVRABLE_TITLEHEIGHT/5. ;
+ sprintf(tmp,"\\gantttitlestyle{%s}",last->title);
+ print_put(title_x,y+y0,tmp);
+ } else if (last->nbTitleLines>1) {
+ int i;
+ // y0 = (DELIVRABLE_HEIGHT-DELIVRABLE_TITLEHEIGHT)/2;
+ y0=DELIVRABLE_TITLEHEIGHT/5.;
+ sprintf(tmp,"\\gantttitlestyle{\\shortstack[l]{%s",last->titleLines[0]);
+ for (i=1 ; inbTitleLines ; i+=1) {
+ strcat(tmp,"\\\\");
+ strcat(tmp,last->titleLines[i]);
+ }
+ strcat(tmp,"}}");
+ print_put(title_x,y+y0,tmp);
+ }
+
+ // print box
+ //y0 = (DELIVRABLE_HEIGHT-DELIVRABLE_BOXHEIGHT)/2;
+ y0 = (top->height-DELIVRABLE_BOXHEIGHT)/2;
+ if ( last==top ) {
+ Tlivrable* l=top;
+ boxx = box_x + l->bm*PICT_MONTHWIDTH ;
+ box_dx = (l->em - l->bm) * PICT_MONTHWIDTH;
+ print_box(1,0,boxx,y+y0,box_dx,box_dy,COLOR_BOX_LIGHT,0,0);
+ print_box(0,0,boxx,y+y0,box_dx,box_dy,0,0,0);
+ } else for (v=0 ; vnbvers ; v+=1) {
+ Tlivrable* l=curr->ls[tn][stn][dn][v] ;
+ gen_label_vers(tmp,l);
+ boxx = box_x + l->bm*PICT_MONTHWIDTH ;
+ box_dx = (l->em - l->bm) * PICT_MONTHWIDTH;
+ print_box(1,0,boxx,y+y0,box_dx,box_dy,COLOR_BOX_LIGHT,0,0);
+ print_box(0,tmp,boxx,y+y0,box_dx,box_dy,0,0,0);
+ }
+ y -= DELIVRABLE_VSEP;
+ return y;
+}
+
+void task_delivrable(double label_x, double box_x, double title_x, int tn)
+{
+int stn,dn;
+Tlivrable* task=curr->ls[tn][0][0][0];
+double y = task->task_y+task->task_dy-task->task_y_del;
+ char tmp[1000];
+ sprintf(tmp,"\\textbf{Task-%d \\textit{%s}}",task->tn,task_names[task->tn]);
+ print_put(label_x/2,y+(TASK_TITLEHEIGHT-TASK_TITLEFONTHEIGHT)/2,tmp);
+
+ //y += DELIVRABLE_VSEP/2. ;
+ for (stn=0 ; curr->ls[tn][stn][0][0]!=0 ; stn++)
+ for (dn=0 ; curr->ls[tn][stn][dn][0]!=0 ; dn++) {
+ if (curr->ls[tn][stn][dn][0]->dn >=0)
+ y=delivrable(label_x,box_x,title_x,y,tn,stn,dn);
+ }
+}
+
+void do_gantt(const char* fn, int* tnplus, int* tnmoins)
+{
+ int tn;
+ double pictwidth, pictheight;
+ double gantt_x,gantt_y;
+ double gantt_dx,gantt_dy;
+
+ double label_x,title_x;
+ curr = data_new(tnplus,tnmoins);
+ if ( (curr->os=fopen(fn,"w"))==0 ) {
+ fprintf(stderr,"can not open %s file for writing.\n",fn);
+ fprintf(stderr,"generation of %s graph is skipped.\n",fn);
+ return;
+ }
+ prepare0(curr);
+ prepare1(curr);
+ prepare2(curr);
+ prepare3(curr);
+
+ pictheight=0 ;
+ pictheight += PICT_BOTSEP ;
+ for ( tn=0 ; curr->ls[tn][0][0][0]!=0 ; tn++ );
+ for ( tn=tn-1 ; tn>=0 ; tn-- ) {
+ double offset;
+ curr->ls[tn][0][0][0]->task_y = pictheight;
+ curr->ls[tn][0][0][0]->task_dy = task_livrable_height(tn,&offset);
+ curr->ls[tn][0][0][0]->task_y_del = offset;
+ pictheight += curr->ls[tn][0][0][0]->task_dy;
+ pictheight += TASK_VSEP;
+ }
+ pictheight += PICT_MONTHHEIGHT;
+ pictheight += PICT_TOPSEP ;
+ gantt_y = PICT_BOTSEP ;
+ gantt_dy = pictheight-PICT_TOPSEP-PICT_BOTSEP ;
+
+ pictwidth=0;
+ pictwidth += PICT_LEFTSEP;
+ label_x = pictwidth;
+ pictwidth += DELIVRABLE_LABELWIDTH;
+ pictwidth += PICT_HSEP;
+ gantt_x = pictwidth ;
+ gantt_dx = 36*PICT_MONTHWIDTH ;
+ pictwidth += gantt_dx ;
+ pictwidth += PICT_HSEP;
+ title_x = pictwidth;
+ pictwidth += DELIVRABLE_TITLEWIDTH;
+ pictwidth += PICT_RIGHTSEP;
+
+ fprintf(curr->os,"\\setlength{\\unitlength}{1.0mm}\n");
+ fprintf(curr->os,"\\begin{picture}(%.1f,%.1f)\n",pictwidth,pictheight);
+ //print_hline(0,0,pictwidth,0);
+ //print_hline(0,pictheight,pictwidth,0);
+ task_box(pictwidth);
+ month_grid(gantt_x,gantt_y,gantt_dx,gantt_dy);
+ for ( tn=0 ; curr->ls[tn][0][0][0]!=0 ; tn++ ) {
+ task_delivrable(label_x,gantt_x,title_x,tn);
+ }
+
+ print_milestones(gantt_x,0,gantt_dx,gantt_dy+gantt_y);
+ fprintf(curr->os,"\\end{picture}\n");
+ fclose(curr->os);
+ curr->os=0;
+}
+
+void do_partner_table_full(int partner)
+{
+ struct partner_def* part = partner_table+partner;
+ if ( (curr->os=fopen(part->fnfull,"w"))==0 ) {
+ fprintf(stderr,"can not open %s file for writing.\n",part->fnfull);
+ fprintf(stderr,"generation of %s partner table is skipped.\n",part->fnfull);
+ return;
+ }
+ fprintf(curr->os,"\\begin{tabular}{|c|l||r|r|r||r|}\\hline\n");
+ fprintf(curr->os,
+ "number & \\multicolumn{1}{c||}{title} & \\multicolumn{3}{c||}{years } & total \\\\\\cline{3-5}\n");
+ fprintf(curr->os,
+ " & & \\multicolumn{1}{c|}{1} & \\multicolumn{1}{c|}{2} & "
+ "\\multicolumn{1}{c||}{3} & \\\\\\hline\\hline\n");
+ int tn,stn,dn,v=0;
+ double an1=0,an2=0,an3=0,an=0;
+ double tsk1,tsk2,tsk3,tsk;
+ int newlineadded=1;
+ for (tn=0 ; tnls[tn][0][0][0]==0) break;
+ if (tn!=0 && newlineadded==0 ) {
+ newlineadded = 1;
+ fprintf(curr->os,"\\hline ");
+ }
+ tsk1=tsk2=tsk3=tsk=0;
+ for (stn=0; stnls[tn][stn][dn][v];
+ if (top==0) continue;
+ Tlivrable* last=top->vers[top->nbvers-1];
+ if (last->partner!=partner) continue;
+ double sum1,sum2,sum3,sum=0;
+ sum1 = last->hman[0]; sum +=sum1;
+ sum2 = last->hman[1]; sum +=sum2;
+ sum3 = last->hman[2]; sum +=sum3;
+ char label[1000],title[1000];
+ gen_label_base(label,last);
+ sprintf(title,"\\resstablestyletitle{%s}",last->title);
+ fprintf(curr->os,"%s & %s & %2.1f & %2.1f & %2.1f & %2.1f \\\\\\hline\n",
+ label,title,sum1,sum2,sum3,sum);
+ an1 += sum1 ; tsk1 += sum1 ;
+ an2 += sum2 ; tsk2 += sum2 ;
+ an3 += sum3 ; tsk3 += sum3 ;
+ an += sum ; tsk += sum ;
+ newlineadded=0;
+ if ( sum1==0 && last->nbma[0]!=0)
+ fprintf(stderr,"ERROR: %-10s:%s probleme sur l'an 1 (in table=%2.1f, in gantt=%2.1f\n",
+ part->name,label,sum1,last->nbma[0]);
+ else if (sum1!=0 && last->nbma[0]==0 )
+ fprintf(stderr,"ERROR: %-10s:%s probleme sur l'an 1 (in table=%2.1f, in gantt=%2.1f\n",
+ part->name,label,sum1,last->nbma[0]);
+ else if (sum1!=0 && sum1>last->nbma[0] )
+ fprintf(stderr,"WARNING: %-10s:%s probleme sur l'an 1 (in table=%2.1f, in gantt=%2.1f\n",
+ part->name,label,sum1,last->nbma[0]);
+ if ( sum2==0 && last->nbma[1]!=0)
+ fprintf(stderr,"ERROR: %-10s:%s probleme sur l'an 2 (in table=%2.1f, in gantt=%2.1f\n",
+ part->name,label,sum2,last->nbma[1]);
+ else if ( sum2!=0 && last->nbma[1]==0)
+ fprintf(stderr,"ERROR: %-10s:%s probleme sur l'an 2 (in table=%2.1f, in gantt=%2.1f\n",
+ part->name,label,sum2,last->nbma[1]);
+ else if (sum2!=0 && sum2>last->nbma[1])
+ fprintf(stderr,"WARNING: %-10s:%s probleme sur l'an 2 (in table=%2.1f, in gantt=%2.1f\n",
+ part->name,label,sum2,last->nbma[1]);
+ if ( sum3==0 && last->nbma[2]!=0)
+ fprintf(stderr,"ERROR: %-10s:%s probleme sur l'an 3 (in table=%2.1f, in gantt=%2.1f\n",
+ part->name,label,sum3,last->nbma[2]);
+ else if ( sum3!=0 && last->nbma[2]==0)
+ fprintf(stderr,"ERROR: %-10s:%s probleme sur l'an 3 (in table=%2.1f, in gantt=%2.1f\n",
+ part->name,label,sum3,last->nbma[2]);
+ else if (sum3!=0 && sum3>last->nbma[2])
+ fprintf(stderr,"WARNING: %-10s:%s probleme sur l'an 3 (in table=%2.1f, in gantt=%2.1f\n",
+ part->name,label,sum3,last->nbma[2]);
+ }
+ }
+ if (tsk!=0)
+ fprintf(curr->os,"%s & total Task-%d & %2.1f & %2.1f & %2.1f & %2.1f \\\\\\hline\n",
+ "",curr->ls[tn][0][0][0]->tn,tsk1,tsk2,tsk3,tsk);
+
+ }
+ if ( an!=(an1+an2+an3) ) {
+ fprintf(stderr,"bad computation in %s table.\n",part->fnfull);
+ }
+ fprintf(curr->os,"\\hline\n");
+ fprintf(curr->os,"%s & %s & %2.1f & %2.1f & %2.1f & %2.1f \\\\\\hline\n",
+ "","total",an1,an2,an3,an);
+
+ fprintf(curr->os,"\\end{tabular}\n");
+ fclose(curr->os);
+ curr->os=0;
+}
+
+void do_partner_table_short(int partner)
+{
+ struct partner_def* part = partner_table+partner;
+ if ( (curr->os=fopen(part->fnshort,"w"))==0 ) {
+ fprintf(stderr,"can not open %s file for writing.\n",part->fnshort);
+ fprintf(stderr,"generation of %s partner table is skipped.\n",part->fnshort);
+ return;
+ }
+ fprintf(curr->os,"\\begin{center}\\begin{small}\\begin{tabular}{|c|l||r|r|r||r|}\\hline\n");
+ fprintf(curr->os,
+ " & title & \\multicolumn{3}{c||}{years } & total \\\\\\cline{3-5}\n");
+ fprintf(curr->os,
+ " & & \\multicolumn{1}{c|}{1} & \\multicolumn{1}{c|}{2} & "
+ "\\multicolumn{1}{c||}{3} & \\\\\\hline\\hline\n");
+ int tn,stn,dn,v=0;
+ double an1=0,an2=0,an3=0,an=0;
+ double tsk1,tsk2,tsk3,tsk;
+ int newlineadded=1;
+ for (tn=0 ; tnls[tn][0][0][0]==0) break;
+ tsk1=tsk2=tsk3=tsk=0;
+ for (stn=0; stnls[tn][stn][dn][v];
+ if (top==0) continue;
+ Tlivrable* last=top->vers[top->nbvers-1];
+ if (last->partner!=partner) continue;
+ double sum1,sum2,sum3,sum=0;
+ sum1 = last->hman[0]; sum +=sum1;
+ sum2 = last->hman[1]; sum +=sum2;
+ sum3 = last->hman[2]; sum +=sum3;
+ an1 += sum1 ; tsk1 += sum1 ;
+ an2 += sum2 ; tsk2 += sum2 ;
+ an3 += sum3 ; tsk3 += sum3 ;
+ an += sum ; tsk += sum ;
+ newlineadded=0;
+ char label[1000];
+ gen_label_base(label,last);
+ }
+ }
+ if (tsk!=0)
+ fprintf(curr->os,"Task-%d & %s & %2.1f & %2.1f & %2.1f & %2.1f \\\\\\hline\n",
+ curr->ls[tn][0][0][0]->tn,
+ task_names[curr->ls[tn][0][0][0]->tn],tsk1,tsk2,tsk3,tsk);
+
+ }
+ if ( an!=(an1+an2+an3) ) {
+ fprintf(stderr,"bad computation in %s table.\n",part->fnshort);
+ }
+ fprintf(curr->os,"\\hline\n");
+ fprintf(curr->os," & %s & %2.1f & %2.1f & %2.1f & %2.1f \\\\\\hline\n",
+ "total",an1,an2,an3,an);
+
+ fprintf(curr->os,"\\end{tabular}\\end{small}\\end{center}\n");
+ fclose(curr->os);
+ curr->os=0;
+}
+
+void do_livrable_tables_open(int tablenum, int last)
+{
+ char fn[1024];
+
+ if (curr->os!=0) {
+ fprintf(curr->os,"\\end{tabular}\n");
+ fclose(curr->os);
+ curr->os = 0;
+ }
+
+ if ( last )
+ return;
+
+ sprintf(fn,"table_livrable_%02d.tex",tablenum);
+ if ( (curr->os=fopen(fn,"w"))==0 ) {
+ fprintf(stderr,"FATAL: can not open %s file for writing.\n",fn);
+ exit(1);
+ }
+ fprintf(curr->os,"\\begin{tabular}[t]{|l|c|c|c|p{\\desclen}|}\\hline\n");
+ fprintf(curr->os,"number");
+ fprintf(curr->os," & resp.");
+ fprintf(curr->os," & \\makebox[2mm]{T0+}");
+ fprintf(curr->os," & \\makebox[2mm]{kind}");
+ fprintf(curr->os," & description\\\\\\hline\\hline\n");
+}
+
+void do_livrable_tables(int maxlines)
+{
+ int nblines=maxlines;
+ int nbfile=1;
+ int tn,stn,dn,v;
+ do_livrable_tables_open(nbfile,0); nbfile +=1 ;
+ for (tn=0 ; tnls[tn][0][0][0]==0 ) break;
+ for (stn=0; stnls[tn][stn][0][0]==0 ) break;
+ for (dn=0; dnls[tn][stn][dn][0];
+ if ( top==0 ) break;
+ Tlivrable* last=top->vers[top->nbvers-1];
+ if ( (nblines-top->nbvers) <= 0 ) {
+ do_livrable_tables_open(nbfile,0); nbfile +=1 ;
+ nblines = maxlines;
+ }
+ for (v=0; vls[tn][stn][dn][v];
+ if ( l==0 ) break;
+ if ( l->dn<0 ) continue;
+ char label[1000],resp[100],date[100],kind[100],desc[1000];
+ gen_label_full(label,l);
+ sprintf(resp,"\\S%s",partner_table[l->partner].key);
+ sprintf(date,"\\makebox[2mm][r]{%d}",l->em);
+ sprintf(kind,"\\makebox[1mm]{%s}",l->kind);
+ if ( top->nbvers == 1 )
+ sprintf(desc,"%s \\\\\\hline\n",last->title);
+ else if ( v==(top->nbvers-1) )
+ sprintf(desc,
+ "\\multirow{-%d}{\\desclen}{%s}\\\\\\hline\n",
+ top->nbvers,last->title);
+ //else if ( v==(top->nbvers-1) )
+ // sprintf(desc, "\\\\\\hline\n");
+ else
+ sprintf(desc, "\\\\\\cline{1-4}\n");
+
+ fprintf(curr->os,"%-15s", label);
+ fprintf(curr->os," & %-10s", resp);
+ fprintf(curr->os," & %-30s", date);
+ fprintf(curr->os," & %-30s", kind);
+ fprintf(curr->os," & %s", desc);
+ nblines -= 1;
+ }
+ }}}
+ do_livrable_tables_open(nbfile,1);
+}
+
+int main()
+{
+ int tnplus[10] = { 1, 2, 3, 4, 8, -1 };
+ int tnmoins[10] = { 1, 2, 3, 4, 8, -1 };
+
+ yylex();
+ do_gantt("gantt.tex",0,0);
+ do_gantt("gantt1.tex",tnplus,0);
+ do_gantt("gantt2.tex",0,tnmoins);
+
+ curr = data_new(0,0);
+ prepare0(curr);
+ prepare1(curr);
+ prepare2(curr);
+ prepare3(curr);
+ do_partner_table_full(1); do_partner_table_short(1);
+ do_partner_table_full(2); do_partner_table_short(3);
+ do_partner_table_full(3); do_partner_table_short(3);
+ do_partner_table_full(4); do_partner_table_short(4);
+ do_partner_table_full(5); do_partner_table_short(5);
+ do_partner_table_full(7); do_partner_table_short(7);
+ do_partner_table_full(8); do_partner_table_short(8);
+ do_partner_table_full(9); do_partner_table_short(9);
+ do_partner_table_full(10); do_partner_table_short(10);
+ do_partner_table_full(11); do_partner_table_short(10);
+
+ curr = data_new(0,0);
+ prepare0(curr);
+ prepare1(curr);
+ prepare2(curr);
+ prepare3(curr);
+ do_livrable_tables(70);
+ return 0;
+}
Index: /anr-2010/obsolete/anr.tex
===================================================================
--- /anr-2010/obsolete/anr.tex (revision 274)
+++ /anr-2010/obsolete/anr.tex (revision 274)
@@ -0,0 +1,29 @@
+\documentclass[12pt,a4paper]{article}
+
+\usepackage[french]{babel}
+%\usepackage[utf8x]{inputenc}
+\usepackage{times}
+\usepackage[T1]{fontenc}
+\usepackage{aeguill}
+\usepackage{verbatim}
+\usepackage{algorithm,algorithmic}
+\usepackage{xmpmulti}
+\usepackage{graphicx}
+\usepackage{color}
+
+\definecolor{gris25}{gray}{0.75}
+\definecolor{gris75}{gray}{0.30}
+
+\title{%
+\textbf{COACH:}
+\textbf{C}onception d'\textbf{A}rchitecture par
+\textbf{C}ompilation et synt\textbf{H}ï¿œse
+}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{document}
+\input{body.tex}
+\end{document}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Index: /anr-2010/obsolete/body.tex
===================================================================
--- /anr-2010/obsolete/body.tex (revision 274)
+++ /anr-2010/obsolete/body.tex (revision 274)
@@ -0,0 +1,795 @@
+\section{Project context}
+\hspace{2cm}\begin{scriptsize}\begin{verbatim}
+% 1. CONTEXTE ET POSITIONNEMENT DU PROJET
+% (1 page maximum) Prￜsentation gￜnￜrale du problￜme qu'il est proposￜ de traiter
+% dans le projet et du cadre de travail (recherche fondamentale, industrielle ou
+% dï¿œveloppement expï¿œrimental).
+\end{verbatim}
+\end{scriptsize}
+An embedded system is an application integrated into one or several chips
+in order to accelerate it or to embedd it into a small device such as a personal
+digital assistant (PDA).
+This topic is investigated since 80s using Applications Specific Integrated Circuits (ASIC),
+Digital Signal Processing (DSP) and parallel computing on multiprocessor machines or networks.
+More recently, since end of 90s, other technologies appeared like Very Large Instruction Word (VLIW),
+Application Specific Instruction Processors (ASIP), System on Chip (SoC),
+Multi-Processors SoC (MPSoC).
+\\
+During these last decades embedded system was reserved to major industrial companies targeting high volume market
+due to the design and fabrication costs.
+Nowadays Field Programmable Gate Arrays (FPGA), like Virtex5 from Xilinx and Stratix4 from Altera,
+can implement a SoC with multiple processors and several coprocessors for less than 10K euros
+per item. In addition, High Level Synthesis (HLS) becomes more mature and allows to automate
+design and to drastically decrease its cost in terms of man power. Thus, both FPGA and HLS
+tend to spread over HPC for small companies targeting low volume markets.
+\par
+To get an efficient embedded system, designer has to take into account application characteristics when it
+chooses one of the former technologies.
+This choice is not easy and in most cases designer has to try different technologies to retain the
+most adapted one.
+\\
+The first objective of COACH is to provide an open-source framework to design embedded system
+on FPGA device.
+COACH framework allows designer to explore various software/hardware partitions of the
+target application, to run timing and functional simulations and to generate automatically both
+the software and the synthesizable description of the hardware.
+The main topics of the project are:
+\begin{itemize}
+\item
+Design space exploration: It consists in analysing the application runnig on FPGA, defining the target
+technology (SoC, MPSoC, ASIP, ...) and hardware/software partitioning of tasks depending on
+technology choice. This exploration is driven basically by throughput, latency and power consumption
+criteria.
+\item
+Micro-architectural exploration: When hardware components are required, the HLS tools of the framework
+generate them automatically. At this stage the framework provides various HLS tools allowing the
+micro-architectural space design exploration. The exploration criteria are also throughput, latency
+and power consumption.
+% FIXME
+%CA At this stage, preliminary source-level transformations will be
+%CA required to improve the efficiency of the target component.
+%CA COACH will also provide such facilities, such as automatic parallelization
+%CA and memory optimisation.
+\item
+Performance measurement: For each point of design space exploration, metrics of criteria are available
+such as throughput, latency, power consumption, area, memory allocation and data locality.
+They are evaluated using virtual prototyping, estimation or analysing methodologies.
+\item
+Targeted hardware technology: The COACH description of system is independent of the FPGA family.
+Every point of the design exploration space can be implemented on any FPGA having the required resources.
+Basically, COACH handles both Altera and Xilinx FPGA families.
+\end{itemize}
+As an extension of embedded system design, COACH deals also with High Performance Computing (HPC).
+In HPC, the kind of targeted application is an existing one running on PC. COACH helps designer
+to accelerate it by migrating critical parts into a SoC implemented on a FPGA plugged to the PC bus.
+\par
+COACH is the result of the will of several laboratory to unify their know how and skills in the
+following domains: Operating system and hardware communication (TIMA, SITI), SoC and MPSoC (LIP6 and TIMA),
+ASIP (IRISA) and HLS (LIP6, Lab-STIC and LIP). The project objective is to integrate these various
+domains into a unique free framework (licence ...) masking as much as possible these domains and its
+different tools to the user.
+
+
+\subsection{Economical context and interest}
+\hspace{2cm}\begin{scriptsize}\begin{verbatim}
+% 1.1. CONTEXTE ET ENJEUX ECONOMIQUES ET SOCIETAUX
+% (2 pages maximum)
+% Dï¿œcrire le contexte ï¿œconomique, social, rï¿œglementaire. dans lequel se situe
+% le projet en prï¿œsentant une analyse des enjeux sociaux, ï¿œconomiques, environnementaux,
+% industriels. Donner si possible des arguments chiffrï¿œs, par exemple, pertinence et
+% portￜe du projet par rapport ￜ la demande ￜconomique (analyse du marchￜ, analyse des
+% tendances), analyse de la concurrence, indicateurs de rï¿œduction de coï¿œts, perspectives
+% de marchï¿œs (champs d'application, .). Indicateurs des gains environnementaux, cycle
+% de vie.
+\end{verbatim}
+\end{scriptsize}
+Microelectronic allows to integrate complicated functions into products, to increase their
+commercial attractivity and to improve their competitivity. Multimedia and communication
+sectors have taken advantage from microelectronics facilities thanks to developpment of
+design methodologies and tools for real time embedded systems. Many other sectors could
+benefit from microelectronics if these methologies and tools are adapted to their features.
+The Non Recurring Engineering (NRE) costs involded in designing and manufacturing an ASIC is
+very high. It costs several milliars of euros for IC factory and several millions to fabricate
+a specific circuit for example a conservative estimate for a 65nm ASIC project is 10 million USD.
+Consequently, it is generally unfeasible to design and fabricate ASICs in
+low volumes and ICs are designed to cover a broad applications spectrum at the cost of
+performance degradation.
+\\
+Today, FPGAs become important actors in the computational domain that was originally dominated
+by microprocessors and ASICs. Just like microprocessors FPGA based systems can be reprogrammed
+on a per-application basis. At the same time, FPGAs offer significant performance benefits over
+microprocessors implementation for a number of applications. Although these benefits are still
+generally an order of magnitude less than equivalent ASIC implementations, low costs
+(500 euros to 10K euros), fast time to market and flexibility of FPGAs make them an attractive
+choice for low-to-medium volume applications.
+Since their introduction in the mid eighties, FPGAs evolved from a simple,
+low-capacity gate array technology to devices (Altera STRATIX III, Xilinx Virtex V) that
+provide a mix of coarse-grained data path units, memory blocks, microprocessor cores,
+on chip A/D conversion, and gate counts by millions. This high logic capacity allows to implement
+complex systems like multi-processors platform with application dedicated coprocessors.
+Table~\ref{fpga_market} shows the estimation of FPGA worldwide market in the next years covering
+various application domains. The ``high end'' lines concern only FPGA with high logic capacity able
+to implement complex systems.
+This market is in significant expansion and is estimated to 914\,M\$ in 2012.
+Using FPGA limits the NRE costs to design cost. This boosts the developpment of methodologies
+and tools to automize design and reduce its cost.
+\begin{table}\leavevmode\center
+\begin{tabular}{|l|l|l|l|}\hline
+Segment & 2010 & 2011 & 2012 \\\hline\hline
+Communications & 1,867 & 1,946 & 2,096 \\
+High end & 467 & 511 & 550 \\\hline
+Consumer & 550 & 592 & 672 \\
+High end & 53 & 62 & 75 \\\hline
+Automotive & 243 & 286 & 358 \\
+High end & - & - & - \\\hline
+Industrial & 1,102 & 1,228 & 1,406 \\
+High end & 177 & 188 & 207 \\\hline
+Military/Aereo & 566 & 636 & 717 \\
+High end & 56 & 65 & 82 \\\hline\hline
+Total FPGA/PLD & 4,659 & 5,015 & 5,583 \\
+Total High-End FPGA & 753 & 826 & 914 \\\hline
+\end{tabular}
+\caption{\label{fga_market} Gartner estimation of worldwide FPGA/PLD consumption (Millions \$)}
+\end{table}
+\par
+Today, several companies (atipa, blue-arc, Bull, Chelsio, Convey, CRAY, DataDirect, DELL, hp,
+Wild Systems, IBM, Intel, Microsoft, Myricom, NEC, nvidia etc) are making systems where demand
+for very high performance (HPC) primes over other requirements. They tend to use the highest
+performing devices like Multi-core CPUs, GPUs, large FPGAs, custom ICs and the most innovative
+architectures and algorithms. Companies show up in different "traditional" applications and market
+segments like computing clusters (ad-hoc), servers and storage, networking and Telecom, ASIC
+emulation and prototyping, Mil/aero etc. HPC market size is estimated today by FPGA providers
+to 214\,M\$.
+This market is dominated by Multi-core CPUs and GPUs based solutions and the expansion
+of FPGA-based solutions is limited by the flow automation. Nowadays, there are neither commercial
+nor free tools covering the whole design process.
+For instance, with SOPC Builder from Altera, users can select and parameterize IP components
+from an extensive drop-down list of communication, digital signal processor (DSP), microprocessor
+and bus interface cores, as well as incorporate their own IP. Designers can then generate
+a synthesized netlist, simulation test bench and custom software library that reflect the hardware
+configuration.
+Nevertheless, SOPC Builder does not provide any facilities to synthesize coprocessors\emph{I
+(Steven) disagree : the C2H compiler bundled with SOPCBuilder does a pretty good job at this} and to
+simulate the platform at a high design level (system C).
+In addition, SOPC Builder is proprietary and only works together with Altera's Quartus compilation
+tool to implement designs on Altera devices (Stratix, Arria, Cyclone).
+PICO [CITATION] and CATAPULT [CITATION] allow to synthesize coprocessors from a C++ description.
+Nevertheless, they can only deal with data dominated applications and they do not handle the
+platform level.
+The Xilinx System Generator for DSP [http://www.xilinx.com/tools/sysgen.htm] is a plug-in to
+Simulink that enables designers to develop high-performance DSP systems for Xilinx FPGAs.
+Designers can design and simulate a system using MATLAB and Simulink. The tool will then
+automatically generate synthesizable Hardware Description Language (HDL) code mapped to Xilinx
+pre-optimized algorithms.
+However, this tool targets only DSP based algorithms.
+\\
+Consequently, designers developping an embedded system needs to master for example
+SoCLib for design exploration,
+SOPC Builde at the platform level,
+PICO for synthesizing the data dominated coprocessors
+and Quartus for design implementation.
+This requires an important tools interfacing effort and makes the design process very complex
+and achievable only by designers skilled in many domains.
+COACH project integrates all these tools in the same framework masking them to the user.
+The objective is to allow \textbf{pure software} developpers to realize embedded systems.
+\par
+The combination of the framework dedicated to software developpers and FPGA target, allows to gain
+market share over Multi-core CPUs and GPUs HPC based solutions.
+Moreover, one can expect that small and even very small companies will be able to propose embedded
+system and accelerating solutions for standard software applications with acceptable prices, thanks
+ to the elimination of huge hardware investment in opposite to ASIC based solution.
+\\
+This new market may explose like it was done by micro-computing in eighties. This success were due
+to the low cost of first micro-computers (compared to main frame) and the advent of high level
+programming languages that allow a high number of programmers to launch start-ups in software
+engineering.
+
+\subsection{Project position}
+\hspace{2cm}\begin{scriptsize}\begin{verbatim}
+% 1.2. POSITIONNEMENT DU PROJET
+% (2 pages maximum)
+% Prï¿œciser :
+% - positionnement du projet par rapport au contexte dￜveloppￜ prￜcￜdemment :
+% vis- ￜ-vis des projets et recherches concurrents, complￜmentaires ou antￜrieurs,
+% des brevets et standards.
+% - positionnement du projet par rapport aux axes thￜmatiques de l'appel ￜ projets.
+% - positionnement du projet aux niveaux europï¿œen et international.
+\end{verbatim}
+\end{scriptsize}
+The aim of this project is to propose an open-source framework for architecture synthesis
+targeting mainly field programmable gate array circuits (FPGA).
+\\% LIP6/TIMA
+To evaluate the different architectures, the project uses the prototyping platform
+of the SoCLIB ANR project (2006-2009).
+\\% IRISA
+The project will also borrow from the ROMA ANR project (2007-2009) and the ongoing
+joint INRIA-STMicro Nano2012 project. In particular we will adapt existing pattern
+extraction algorithms and datapath merging techniques to the synthesis of customized
+ASIP processors.
+\\
+\textcolor{gris75}{Steven : Je propose de rajouter un lien avec le projet BioWic~:~on the HPC
+application side, we also hope to benefit from the experience in hardware acceleration of
+bioinformatic algorithms/workfows gathered by the CAIRN group in the context of the ANR
+BioWic project (2009-2011), so as to be able to validate the framework on
+real-life HPC applications.}
+
+\par
+%%% 1 -- POUVEZ VOUS CHACUN AJOUTER SVP (SI POSSIBLE) UNE LIGNE
+%%% 1 -- REFERANT UN PROJET ANR OU EUROPEEN
+%%% 1 -- Projets europï¿œens ou ANR rï¿œutilisï¿œs ou continuï¿œs
+%%% 1 LIP6/TIMA/LAB-STIC OK
+Regarding the expertise in High Level Synthesis (HLS), the project leverages on know-how acquired over 15 years
+with GAUT project developped in Lab-STIC laboratory and UGH project developped in LIP6
+and TIMA laboratories. \\
+Regarding architecture synthesis skills, the project is based on a know-how acquired over 10 years
+with the COSY European project (1998-2000) and the DISYDENT project developped in LIP6. \\
+%%% 1 IRISA OK
+Regarding Application Specific Instruction Processor (ASIP) design, the CAIRN group at INRIA Bretagne
+Atlantique benefits from several years of expertise in the domain of retargetable compiler (Armor/Calife
+since 1996, and the Gecos compilers since 2002).
+
+
+% LIP FIXME:UN:PEU:LONG ET HORS:SUJET
+%CA% The source-level transformations required by the HLS tools will be
+%CA% designed in the {\em polyhedral model}, a general framework
+%CA% initiated by Paul Feautrier 20 years ago. The programs handled in
+%CA% the polyhedral model are such that loop iterators describe a
+%CA% polyhedron (hence the name). This includes most of the kernels used
+%CA% in embedded applications. This property allows to design precise
+%CA% analysis by means of integer programming techniques.
+%CA% %communaute active & internationale
+%CA% %transfert techno (Reservoir)
+%CA% The polyhedral community is very active, and the technological
+%CA% transfer has now started. Reservoir Labs inc., a company based in
+%CA% New-York, is currently integrating the last polyhedral developments
+%CA% in its commercial compiler.
+%CA% %transfert techno (gcc)
+%CA% Also, polyhedra are progressively migrating into the {\sc GNU Gcc}
+%CA% compiler, via {\sc Graphite}, a module initially developed by
+%CA% Sebastian Pop.
+%CA% %outils existants
+%CA% Several tools have been developed in the polyhedral community,
+%CA% such as {\sc Piplib} (parameter integer programming library), and
+%CA% {\sc Polylib}, a library providing set operations on polyhedra. Both
+%CA% tools are almost mandatory in polyhedral tools, and have reached
+%CA% a sufficient level of maturity to be considered as standard.
+%syntol & bee ???
+% FIN
+% and on more than 15 years of experience on parallel hardware generation
+% in the polyedral model in the CAIRN group (MMAlpha software
+% developped in the group since 1996).
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%% 2 -- A COMPLETER (COURT)
+%%% 2 -- For polyedric transformation and memory optimization ... LIP
+%%% 2 -- For ASIP IRISA
+%%% 2 -- For ... CITI
+%%% 2 -- For ... TIMA
+\par
+The SoCLIB ANR platform were developped by 11 laboratories and 6 companies. It allows to
+describe hardware architectures with shared memory space and to deploy software
+applications on them to evaluate their performance.
+The heart of this platform is a library containing simulation models (in SystemC)
+of hardware IP cores such as processors, buses, networks, memories, IO controller.
+The platform provides also embedded operating systems and software/hardware
+communication components useful to implement applications quickly.
+However, the synthesisable description of IPs have to be provided by users. \\
+This project enhances SoCLib by providing synthesisable VHDL of standard IPs.
+In addition, HLS tools such as UGH and GAUT allow to get automatically a synthesisable
+description of an IP (coprocessor) from a sequential algorithm.
+%\par
+%%% 2 IRISA ?
+%%% 2 ASIP tool such as ... IRISA
+%%% 2 ...
+%%% 2 Coach uses pattern extractions from ROMA
+%\par
+%%% 2 LIP ?
+\par
+The different points proposed in this project cover priorities defined by the commission
+experts in the field of Information Technolgies Society (IST) for Embedded
+systems: <>.
+\\
+Our team aims at covering all the steps of the design flow of architecture synthesis.
+Our project overcomes the complexity of using various synthesis tools and description
+languages required today to design architectures.
+
+\section{Scientific and Technical Description}
+\subsection{State of the art}
+\hspace{2cm}\begin{scriptsize}\begin{verbatim}
+% 2. DESCRIPTION SCIENTIFIQUE ET TECHNIQUE
+% 2.1. ï¿œTAT DE L'ART
+% (3 pages maximum)
+% Dï¿œcrire le contexte et les enjeux scientifiques dans lequel se situe le projet
+% en prï¿œsentant un ï¿œtat de l'art national et international dressant l'ï¿œtat des
+% connaissances sur le sujet. Faire apparaï¿œtre d'ï¿œventuels rï¿œsultats prï¿œliminaires.
+% Inclure les rï¿œfï¿œrences bibliographiques nï¿œcessaires en annexe 7.1.
+\end{verbatim}
+\end{scriptsize}
+Our project covers several critical domains in system design in order
+to achieve high performance computing. Starting from a high level description we aim
+at generating automatically both hardware and software components of the system.
+
+\subsubsection{High Performance Computing}
+Accelerating high-performance computing (HPC) applications with field-programmable
+gate arrays (FPGAs) can potentially improve performance.
+However, using FPGAs presents significant challenges [1].
+First, the operating frequency of an FPGA is low compared to a high-end microprocessor.
+Second, based on Amdahl law, HPC/FPGA application performance is unusually sensitive
+to the implementation quality [2].
+Finally, High-performance computing programmers are a highly sophisticated but scarce
+resource. Such programmers are expected to readily use new technology but lack the time
+to learn a completely new skill such as logic design [3].
+\\
+HPC/FPGA hardware is only now emerging and in early commercial stages,
+but these techniques have not yet caught up.
+Thus, much effort is required to develop design tools that translate high level
+language programs to FPGA configurations.
+
+\hspace{2cm}\begin{scriptsize}\begin{verbatim}
+[1] M.B. Gokhale et al., Promises and Pitfalls of Reconfigurable
+Supercomputing, Proc. 2006 Conf. Eng. of Reconfigurable
+Systems and Algorithms, CSREA Press, 2006, pp. 11-20;
+http://nis-www.lanl.gov/~maya/papers/ersa06_gokhale_paper.
+pdf.
+[2] D. Buell, Programming Reconfigurable Computers: Language
+Lessons Learned, keynote address, Reconfigurable Systems
+Summer Institute 2006, 12 July 2006; http://gladiator.
+ncsa.uiuc.edu/PDFs/rssi06/presentations/00_Duncan_Buell.pdf
+[3] T. Van Court et al., Achieving High Performance
+with FPGA-Based Computing, Computer, vol. 40, no. 3,
+pp. 50-57, Mar. 2007, doi:10.1109/MC.2007.79
+\end{verbatim}
+\end{scriptsize}
+
+\subsubsection{System Synthesis}
+Today, several solutions for system design are proposed and commercialized. The most common are
+those provided by Altera and Xilinx to promote their FPGA devices.
+\\
+The Xilinx System Generator for DSP [http://www.xilinx.com/tools/sysgen.htm] is a plug-in to
+Simulink that enables designers to develop high-performance DSP systems for Xilinx FPGAs.
+Designers can design and simulate a system using MATLAB and Simulink. The tool will then
+automatically generate synthesizable Hardware Description Language (HDL) code mapped to Xilinx
+pre-optimized algorithms.
+However, this tool targets only DSP based algorithms, Xilinx FPGAs and cannot handle complete
+SoC. Thus, it is not really a system synthesis tool.
+\\
+In the opposite, SOPC Builder [CITATION] allows to describe a system, to synthesis it,
+to programm it into a target FPGA and to upload a software application.
+% FIXME(C2H from Altera, marche vite mais ressource monstrueuse)
+Nevertheless, SOPC Builder does not provide any facilities to synthesize coprocessors.
+Users have to provide the synthesizable description with the feasible bus interface.
+\\
+In addition, Xilinx System Generator and SOPC are closed world since each one imposes
+their own IPs which are not interchangeable.
+We can conclude that the existing commercial or free tools does not coverthe whole system
+synthesis process in a full automatic way. Moreover, they are bound to a particular device family
+and to IPs library.
+
+\subsubsection{High Level Synthesis}
+High Level Synthesis translates a sequential algorithmic description and a constraints set
+(area, power, frequency, ...) to a micro-architecture at Register Transfer Level (RTL).
+Several academic and commercial tools are today available.
+Most common tools are SPARK [HLS1], GAUT [HLS2], UGH [HLS3] in the academic world
+and catapultC [HLS4], PICO [HLS5] and Cynthesizer [HLS6] in commercial world.
+Despite their maturity, their usage is restrained by:
+\begin{itemize}
+\item They do not respect accurately the frequency constraint when they target an FPGA device.
+Their error is about 10 percent. This is annoying when the generated component is integrated
+in a SoC since it will slow down the hole system.
+\item These tools take into account only one or few constraints simultaneously while realistic
+designs are multi-constrained.
+Moreover, low power consumption constraint is mandatory for embedded systems.
+However, it is not yet well handled by common synthesis tools.
+\item The parallelism is extracted from initial algorithm. To get more parallelism or to reduce
+the amout of required memory, the user must re-write it while there is techniques as polyedric
+transformations to increase the intrinsec parallelism.
+\item Despite they have the same input language (C/C++), they are sensitive to the style in
+which the algorithm is written. Consequently, engineering work is required to swap from
+a tool to another.
+\item The HLS tools are not integrated into an architecture and system exploration tool.
+Thus, a designer who needs to accelerate a software part of the system, must adapt it manually
+to the HLS input dialect and performs engineering work to exploit the synthesis result
+at the system level.
+\end{itemize}
+Regarding these limitations, it is necessary to create a new tool generation reducing the gap
+between the specification of an heterogenous system and its hardware implementation.
+
+\hspace{2cm}\begin{scriptsize}\begin{verbatim}
+[HLS1] SPARK universite de californie San Diego
+[HLS2] GAUT UBS/Lab-STIC
+[HLS3] UGH
+[HLS4] catapultC Mentor
+[HLS5] PICO synfora
+[HLS6] Cynthesizer Forte design system
+\end{verbatim}
+\end{scriptsize}
+
+\subsubsection{Application Specific Instruction Processors}
+
+ASIP (Application-Specific Instruction-Set Processor) are programmable processors in
+which both the instruction and the micro architecture have been tailored to a given
+ application domain (eg. video processing), or to a specific application.
+This specialization usually offers a good compromise between performance (w.r.t a pure software
+implementation on an embeded CPU) and flexibility (w.r.t an application specific
+hardware co-processor).
+In spite of their obvious advantages, using/designing ASIPs remains a difficult
+task, since it involves designing both a micro-architecture and a compiler for this
+architecture. Besides, to our knowledge, there is still no available open-source
+design flow\footnote{There are commercial tools such a } for ASIP design even if such a tool would
+be valuable in the context of a System Level design exploration tool.
+
+In this context, ASIP design based on Instruction Set Extensions (ISEs) has
+received a lot of interest [NIOSII,TENSILICA]%~\cite{NIOS2,ST70},
+as it makes micro architecture synthesis
+more tractable \footnote{ISEs rely on a template micro-architecture in which
+only a small fraction of the architecture has to be specialized}, and help ASIP
+designers to focus on compilers, for which there are still many open problems
+[CODES04,FPGA08].
+This approach however has a strong weakness, since it also significantly reduces
+opportunities for achieving good seedups (most speedup remain between 1.5x and
+2.5x), since ISEs performance is generally tied down by I/O constraints as
+they generally rely on the main CPU register file to access data.
+
+% (
+%automaticcaly extraction ISE candidates for application code \cite{CODES04},
+%performing efficient instruction selection and/or storage resource (register)
+%allocation \cite{FPGA08}).
+
+
+To cope with this issue, recent approaches~[DAC09,DAC08]%\cite{DAC09,DAC08}
+advocate the use of
+micro-architectural ISE models in which the coupling between the processor micro-architecture
+and the ISE component is thightened up so as to allow the ISE to overcome the register
+I/O limitations, however these approaches tackle the problem for a compiler/simulation
+point of view and not address the problem of generating synthesizable representations for
+these models.
+
+We therefore strongly believe that there is a need for an open-framework which
+would allow researchers and system designers to :
+\begin{itemize}
+\item Explore the various level of interactions between the original CPU micro-architecure
+and its extension (for example throught a Domain Specific Language targeted at micro-architecture
+specification and synthesis).
+\item Retarget the compiler instruction-selection (or prototype nex passes) passes so as
+to be able to take advantage of this ISEs.
+\item Provide a complete System-level Integration for using ASIP as SoC building blocks
+(integration with application specific blocks, MPSoc, etc.)
+\end{itemize}
+
+\hspace{2cm}
+\begin{scriptsize}\begin{verbatim}
+
+[CODES08] Theo Kluter, Philip Brisk, Paolo Ienne, and Edoardo Charbon, Speculative DMA for
+Architecturally Visible Storage in Instruction Set Extensions
+
+[DAC09] Theo Kluter, Philip Brisk, Paolo Ienne, Edoardo Charbon, Way Stealing: Cache-assisted
+Automatic Instruction Set Extensions.
+
+[CODES04] Pan Yu, Tulika Mitra, Scalable Custom Instructions Identification for
+Instruction Set Extensible Processors.
+
+[FPGA08] Quang Dinh, Deming Chen, Martin D. F. Wong, Efficient ASIP Design for Configurable
+Processors with Fine-Grained Resource Sharing.
+
+[NIOSII] Nios II Custom Instruction User Guide
+
+\end{verbatim}
+
+\end{scriptsize}
+%, either
+%because the target architecture is proprietary, or because the compiler
+%technology is closed/commercial.
+
+
+
+
+% We propose to explore how to tighten the coupling of the extensions and
+% the underlyoing template micro-architecture.
+% * Thightne Even if such
+% an approach offers less flexiblity and forbids very tight coupling
+% between the extensions and the template micro-architecture, it makes the
+% design of the micro-architecture more tractable and amenable to a fully
+% automated flow.
+% \\
+% \\
+% In the context of the COACH project, we propose to add to the
+% infra-structure a design flow targeted to automatic instruction set
+% extension for the MIPS-based CPU, which will come as a complement or an
+% alternative to the other proposed approaches (hardware accelerator,
+% multi processors).
+%
+
+\subsubsection{Automatic Parallelization}
+\begin{Large}\begin{verbatim}
+-- A COMPLETER LIP
+\end{verbatim}
+\end{Large}
+%CA% Parallel machines are often difficult and painful to program
+%CA% directly, and one would like the compiler to %do the job, that is to
+%CA% turn automatically a sequential program into a parallel form. This
+%CA% transformation is referred as {\em automatic parallelization}, and has
+%CA% been widely addressed since the 70s. Automatic parallelization
+%CA% relies on data dependences, which cannot be computed in general.%, as
+%CA% %one cannot predict at compile time the variable values on a given
+%CA% %execution point.
+%CA% This negative result led researchers to (i) find a
+%CA% program model in which no approximation is needed (ie polyhedral
+%CA% model), (ii) make conservative approximations (iii) remark that
+%CA% variable values are known at runtime, and make the decisions during
+%CA% program execution. The latter approach is obviously not suitable
+%CA% there, as we target hardware generation. We will give there a short
+%CA% history of the approaches that fall in the first category.
+%CA%
+%CA%% In the real world, we deal with a limited amount of processors,
+%CA%% and the communication between processors takes time, and is
+%CA%% critical for performance. %Whenever we have synchronisation-free
+%CA%% parallelism, like for embarrassingly parallel kernels, this is not an
+%CA%% issue. But in case of pipelined parallelism, we need to reduce
+%CA%% communications as much as possible.
+%CA%% So we also need to find parallelism toghether with a proper mapping
+%CA%% of operations and data on physical processors.
+%CA%
+%CA% As programs spend most of there time in loops, the community has
+%CA% focused on loop transformations that reveal parallelism.
+%CA%%unimodulaire
+%CA% The first approaches worked on perfect loop nests, where the tree
+%CA% formed by the nested loops is linear. In this program model, the
+%CA% loops can be seen as a basis that drive the way the iteration
+%CA% domain will be described. Hence, a first idea was to change this
+%CA% basis such that one vector (one loop) at least is parallel. To ease
+%CA% the code generation, the area of defined by the news vectors must
+%CA% be a unit volume. %Otherwise, one would produce an homothetic
+%CA%% expansion of the iteration domain, which will force to put modulos
+%CA%% in the target code.
+%CA% For this reason, these transformations are called {\em unimodular
+%CA% transformations}.
+%CA%%tiling
+%CA%
+%CA% The next approaches include {\em loop tiling}, a simple
+%CA% partitioning of the iteration domain, whose initial purpose is to
+%CA% execute every partition on a different processor. %In the same way,
+%CA% The execution order is modified with a proper unimodular
+%CA% transformation, then the tiles are obtained by cutting the
+%CA% iteration domain with the hyperplanes directed by every vector of
+%CA% the new (unimodular) basis, at regular intervals. When the tiling
+%CA% hyperplanes are properly chosen, we can both improve data-locality
+%CA% on every processor, and reduce the communication between two
+%CA% different tiles (which will be mapped on processors). This last
+%CA% property implying that one tend to find a degree of parallelism as
+%CA% great as possible.
+%CA%
+%CA%%affine scheduling
+%CA% The previous approaches were restricted to kernels with perfect
+%CA% loop nests (linear loop tree), and unimodular transformations. The
+%CA% last generation of approaches broke with these limitations. We now
+%CA% choose a different basis for every assignment, without the
+%CA% unimodularity restriction. A dual way to present the things is the
+%CA% notion of {\em affine schedule}, introduced by Feautrier [part1],
+%CA% that simply assigns an abstract execution date to every assignment
+%CA% execution. As an assignment execution is exactly characterised by
+%CA% the current value of the loops counters (iteration vector), the
+%CA% affine schedule will be defined as an affine form of the iteration
+%CA% vector (hence the 'affine'). The affine property allows to use
+%CA% integer programming techniques to compute the schedule. With this
+%CA% approach, additional techniques are required to allocate the
+%CA% parallel operations and the data to processor in an efficient way
+%CA% [griebl, feautrier].
+%CA%
+%CA%%modularity??
+%CA%%% As loop nests are no longer perfect, we deal with (transformed)
+%CA%%% iteration domains of different dimensions, which can possibly (and
+%CA%%% certainly) overlap. At this point, a new code generation technique
+%CA%%% was needed. The first attempt is due to Chamsky et al. [??], and
+%CA%%% was improved by Quillere et al. [QRW]. The code is now implemented
+%CA%%% in an efficient tool [cloog], that gave a new life to polyhedral
+%CA%%% techniques.
+%CA%
+%CA%%pluto's tiling
+%CA% The tiling techniques were extended to non-perfect loop nest with
+%CA% {\em affine partitioning}. Affine partitioning is to affine
+%CA% scheduling what (original) tiling was to unimodular
+%CA% transformations. An affine partitioning assigns to every assignment
+%CA% its coordinates in the basis defined by the normals to the tiling
+%CA% hyperplanes. Recently, a way to compute efficient hyperplanes were
+%CA% found [uday], with a good data locality, and communications
+%CA% confined in a small neighborhood around every processor.
+%CA%
+%CA%\subsubsection{Source-level Memory Optimisation}
+%CA% The HLS process allows to customise memory, which impacts on final
+%CA% circuit size and power consumption. Though most HLS tools already
+%CA% try to optimise memory usage, it is better to provide an independent
+%CA% source-level pass, that could be reused for different tools and in
+%CA% other contexts.
+%CA%
+%CA% There exists many approaches to evaluate and reduce the memory
+%CA% requirement of a program. The first approaches are concerned with
+%CA% {\em memory size estimation}, which can be defined as the maximum
+%CA% number of memory cells used at the same time [clauss,zhao]. These
+%CA% approaches provide an estimation as a symbolic expression of program
+%CA% parameters, which can be used further to guide loop optimisations.
+%CA% However, no explicit way to reduce the memory size is given. {\em
+%CA% Intra-array reuse} approaches brake with this limitation, and
+%CA% collapse the array cells which are not alive at the same time. The
+%CA% collapse is done by means of a data layout transformation, specified
+%CA% with a linear (modular) mapping. The first approaches were
+%CA% developed at IMEC [balasa,catthoor], and basically try to linearize
+%CA% the arrays and fold them using a modulo operator. Then, Lefebvre et
+%CA% al. propose a solution to fold independently the array dimensions
+%CA% [lefebvre]. Finally, Darte et al. provide a general formalisation of
+%CA% the problem, together with a solution that subsumes the previous
+%CA% approaches [darte]. A first implementation was made with the tool
+%CA% {\sc Bee}, but there are still many limitations.
+%CA%
+%CA% \begin{itemize}
+%CA% \item The tool is restricted to regular programs, whereas more
+%CA% general programs could be handled with a conservative array liveness
+%CA% analysis.
+%CA%
+%CA% \item Programs depending on parameters (inputs) are not handled,
+%CA% which forbids to handle, for example, the body of tiled loops.
+%CA%
+%CA% \item The new array layout can brake spatial locality, and then impact
+%CA% performance and power consumption. One would like to get a mapping
+%CA% that improve or, at least, preserve the spatial locality of the
+%CA% program.
+%CA%
+%CA% \item Finally, the final memory compaction strongly depends on the
+%CA% program schedule, and is naturally hindered by the
+%CA% parallelism. Consequently, there is a trade-off to find with
+%CA% automatic parallelization. An ideal solution would be to reduce
+%CA% memory usage, while preserving parallelism.
+%CA% \end{itemize}
+
+\subsubsection{Interfaces}
+\begin{Large}\begin{verbatim}
+-- A COMPLETER INSA Etat de l'art
+\end{verbatim}
+\end{Large}
+%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsection{Objectives and innovation aspects}
+\hspace{2cm}\begin{scriptsize}\begin{verbatim}
+% 2.2. OBJECTIFS ET CARACTERE AMBITIEUX/NOVATEUR DU PROJET
+% (2 pages maximum)
+% Dï¿œcrire les objectifs scientifiques/techniques du projet.
+% Prￜsenter l'avancￜe scientifique attendue. Prￜciser l'originalitￜ et le caractￜre
+% ambitieux du projet.
+% Dￜtailler les verrous scientifiques et techniques ￜ lever par la rￜalisation du projet.
+% Dￜcrire ￜventuellement le ou les produits finaux dￜveloppￜs ￜ l'issue du projet
+% montrant le caractï¿œre innovant du projet.
+% Prï¿œsenter les rï¿œsultats escomptï¿œs en proposant si possible des critï¿œres de rï¿œussite
+% et d'ï¿œvaluation adaptï¿œs au type de projet, permettant d'ï¿œvaluer les rï¿œsultats en
+% fin de projet.
+% Le cas ￜchￜant (programmes exigeant la pluridisciplinaritￜ), dￜmontrer l'articulation
+% entre les disciplines scientifiques.
+\end{verbatim}
+\end{scriptsize}
+
+% les objectifs scientifiques/techniques du projet.
+The objectives of COACH project are to develop a complete framework to
+HPC (accelerating solutions for existing software applications)
+and embedded applications (implementing an application on a low power standalone device).
+The design steps are presented figure 1.
+\begin{figure}[hbtp]\leavevmode\center
+ \includegraphics[width=.8\linewidth]{flow}
+ \caption{\label{coach-flow} COACH flow.}
+\end{figure}
+\begin{description}
+\item[HPC setup] Here the user splits the application into 2 parts: the host application
+which remains on PC and the SoC application which migrates on SoC.
+The framework provides a simulation model allowing to evaluate the partitioning.
+\item[SoC design] In this phase,
+The user can obtain simulators at different abstraction levels of the SoC by giving to COACH framework
+a SoC description.
+This description consists of a process network corresponding to the SoC application,
+an OS, an instance of a generic hardware platform
+and a mapping of processes on the platform components. The supported mapping are
+software (the process runs on a SoC processor),
+XXXpeci (the process runs on a SoC processor enhanced with dedicated instructions),
+and hardware (the process runs into a coprocessor generated by HLS and plugged on the SoC bus).
+\item[Application compilation] Once SoC description is validated, COACH generates automatically
+an FPGA bitstream containing the hardware platform with SoC application software and
+an executable containing the host application. The user can launch the application by
+loading the bitstream on FPGA and running the executable on PC.
+\end{description}
+
+% l'avancee scientifique attendue. Preciser l'originalite et le caractere
+% ambitieux du projet.
+The main scientific contribution of the project is to unify various synthesis techniques
+(same input and output formats) allowing the user to swap without engineering effort
+from one to an other and even to chain them, for example, to run polyedric transformation
+before synthesis.
+Another advantage of this framework is to provide different abstraction levels from
+a single description.
+Finally, this description is device family independent and its hardware implementation
+is automatically generated.
+
+% Detailler les verrous scientifiques et techniques a lever par la realisation du projet.
+System design is a very complicated task and in this project we try to simplify it
+as much as possible. For this purpose we have to deal with the following scientific
+and technological barriers.
+\begin{itemize}
+\item The main problem in HPC is the communication between the PC and the SoC.
+This problem has 2 aspects. The first one is the efficiency. The second is to
+eliminate enginnering effort to implement it at different abstract levels.
+\item COACH design flow has a top-down approach. In the such case,
+the required performance of a coprocessor (run frequency, maximum cycles for
+a given computation, power consumption, etc) are imposed by the other system
+components. The challenge is to allow user to control accurately the synthesis
+process. For instance, the run frequency must not be a result of the RTL synthesis
+but a strict synthesis constraint.
+\item HLS tools are sensitive to the style in which the algorithm is written.
+In addition, they are are not integrated into an architecture and system
+exploration tool.
+Consequently, engineering work is required to swap from a tool to another,
+to integrate the resulting simulation model to an architectural exploration tool
+and to synthesize the generated RTL description.
+%CA Additionnal preprocessing, source-level transformations, are thus
+%CA required to improve the process.
+%CA Particularly, this includes parallelism exposure and efficient memory mapping.
+\item Most HLS tools translate a sequential algorithm into a coprocessor
+containing a single data-path and finite state machine (FSM). In this way,
+only the fine grained parallelism is exploited (ILP parallelism).
+The challenge is to identify the coarse grained parallelism and to generate,
+from a sequential algorithm, coprocessor containing multiple communicating
+tasks (data-paths and FSMs).
+\end{itemize}
+
+%Presenter les resultats escomptes en proposant si possible des criteres de reussite
+%et d'evaluation adaptes au type de projet, permettant d'evaluer les resultats en
+%fin de projet.
+The main result is the framework. It is composed concretely of:
+2 HPC communication shemes with their implementation,
+5 HLS tools (control dominated HLS, data dominated HLS, Coarse grained HLS,
+Memory optimisation HLS and ASIP),
+3 systemC based virtual prototyping environment extended with synthesizable
+RTL IP cores (generic, ALTERA/NIOS/AVALON, XILINX/MICROBLAZE/OPB),
+one design space exploration tool,
+one operating system (OS).
+\\
+The framework fonctionality will be demonstrated with XXX-EXAMPLE1, XXX-EXAMPLE2
+and XXX-EXAMPLE3 on 4 archictures (generic/XILINX, generic/ALTERA,
+proprietary/XILINX, proprietary/ALTERA).
+
+%% \section{}
+%% %3. PROGRAMME SCIENTIFIQUE ET TECHNIQUE, ORGANISATION DU PROJET
+%% \subsection{}
+%% %3.1. PROGRAMME SCIENTIFIQUE ET STRUCTURATION DU PROJET
+%% %(2 pages maximum)
+%% %Prï¿œsentez le programme scientifique et justifiez la dï¿œcomposition en tï¿œches du
+%% %programme de travail en cohï¿œrence avec les objectifs poursuivis.
+%% %Utilisez un diagramme pour prï¿œsenter les liens entre les diffï¿œrentes tï¿œches
+%% %(organigramme technique)
+%% %Les tￜches reprￜsentent les grandes phases du projet. Elles sont en nombre limitￜ.
+%% %N'oubliez pas les activitￜs et actions correspondant ￜ la dissￜmination et ￜ la
+%% %valorisation.
+%%
+%% %METTRE UNE FIGURE ICI DECRIVANT LES TACHES ET LEURS INTERACTION (AVEC LE FLOT
+%% %EN FILIGRANE ? )
+%% \subsection{}
+%% %3.2. MANAGEMENT DU PROJET
+%% %(2 pages maximum)
+%% %Prï¿œciser les aspects organisationnels du projet et les modalitï¿œs de coordination
+%% %(si possible individualisation d'une tï¿œche coordination : cf. tï¿œche 0 du document
+%% %de soumission A).
+%% \subsection{}
+%% %3.3. DESCRIPTION DES TRAVAUX PAR TACHE
+%% %(idï¿œalement 1 ou 2 pages par tï¿œche)
+%% %Pour chaque tï¿œche, dï¿œcrire :
+%% %- les objectifs de la tï¿œche et ï¿œventuels indicateurs de succï¿œs,
+%% %- le responsable de la tￜche et les partenaires impliquￜs (possibilitￜ de
+%% %l'indiquer sous forme graphique),
+%% %- le programme dￜtaillￜ des travaux par tￜche,
+%% %- les livrables de la tï¿œche,
+%% %- les contributions des partenaires (le " qui fait quoi "),
+%% %- la description des mï¿œthodes et des choix techniques et de la maniï¿œre dont
+%% %les solutions seront apportï¿œes,
+%% %- les risques de la tï¿œche et les solutions de repli envisagï¿œes.
+
+
+
+
+
+
Index: /anr-2010/obsolete/coach_irisa.bib
===================================================================
--- /anr-2010/obsolete/coach_irisa.bib (revision 274)
+++ /anr-2010/obsolete/coach_irisa.bib (revision 274)
@@ -0,0 +1,33 @@
+@InProceedings{KluterCodes08,
+ author = {{Theo Kluter and Philip Brisk and Paolo Ienne and and Edoardo Charbon}},
+ title = {{Speculative DMA for Architecturally Visible Storage in Instruction Set Extensions}},
+ booktitle = {ISSS/CODES},
+ year = {2008},
+}
+
+@InProceedings{KluterDAC09,
+ author = {{Theo Kluter and Philip Brisk and Paolo Ienne and and Edoardo Charbon}},
+ title = {{Way Stealing : Cache-assisted Automatic Instruction Set Extensions}},
+ booktitle = {Design Automation Conference (DAC)},
+ year = {2009},
+}
+
+@InProceedings{YuCodes04,
+ author = {{Pan Yu and Tulika Mitra}},
+ title = {{Scalable Custom Instructions Identification for Instruction Set Extensible Processors}},
+ booktitle = {ISSS/CODES},
+ year = {2004},
+}
+
+@InProceedings{Dinh08,
+ author = {{Quang Dinh and Deming Chen and Martin D.~F.~Wong}},
+ title = {{Efficient ASIP Design for Configurable Processors with Fine-Grained Resource Sharing}},
+ booktitle = {ACM Internatibnal Conference Field Programmable Gate Arrays (FPGA)},
+ year = {2008},
+}
+
+@Misc{NIOS2UG,
+ title = {{Nios II Custom Instruction User Guide, Altera Corp.}},
+ year = {2008},
+
+}
Index: /anr-2010/obsolete/dependence-dev.fig
===================================================================
--- /anr-2010/obsolete/dependence-dev.fig (revision 274)
+++ /anr-2010/obsolete/dependence-dev.fig (revision 274)
@@ -0,0 +1,63 @@
+#FIG 3.2 Produced by xfig version 3.2.5-alpha5
+Landscape
+Center
+Metric
+Letter
+100.00
+Single
+-2
+1200 2
+6 4635 -1575 7560 -1170
+4 1 0 50 -1 2 14 0.0000 4 165 120 4725 -1170 0\001
+4 1 0 50 -1 2 14 0.0000 4 165 120 5175 -1170 6\001
+4 1 0 50 -1 2 14 0.0000 4 165 240 5625 -1170 12\001
+4 1 0 50 -1 2 14 0.0000 4 165 240 6075 -1170 18\001
+4 1 0 50 -1 2 14 0.0000 4 165 240 6525 -1170 24\001
+4 1 0 50 -1 2 14 0.0000 4 165 240 6975 -1170 30\001
+4 1 0 50 -1 2 14 0.0000 4 165 240 7425 -1170 36\001
+4 1 0 50 -1 2 14 0.0000 4 165 675 6075 -1395 month\001
+-6
+2 1 1 1 0 7 50 -1 -1 4.000 0 0 7 0 0 2
+ 4725 -1080 4725 360
+2 1 1 1 0 7 50 -1 -1 4.000 0 0 7 0 0 2
+ 5175 -1080 5175 360
+2 1 1 1 0 7 50 -1 -1 4.000 0 0 7 0 0 2
+ 5625 -1080 5625 360
+2 1 1 1 0 7 50 -1 -1 4.000 0 0 7 0 0 2
+ 6075 -1080 6075 360
+2 1 1 1 0 7 50 -1 -1 4.000 0 0 7 0 0 2
+ 6525 -1080 6525 360
+2 1 1 1 0 7 50 -1 -1 4.000 0 0 7 0 0 2
+ 6975 -1080 6975 360
+2 1 1 1 0 7 50 -1 -1 4.000 0 0 7 0 0 2
+ 7425 -1080 7425 360
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 1 2
+ 0 0 1.00 60.00 120.00
+ 0 0 1.00 60.00 120.00
+ 4725 -900 6525 -900
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 1 2
+ 0 0 1.00 60.00 120.00
+ 0 0 1.00 60.00 120.00
+ 5220 -675 7425 -675
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 1 2
+ 0 0 1.00 60.00 120.00
+ 0 0 1.00 60.00 120.00
+ 5220 -450 7380 -450
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 1 2
+ 0 0 1.00 60.00 120.00
+ 0 0 1.00 60.00 120.00
+ 5220 -225 7380 -225
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 1 2
+ 0 0 1.00 60.00 120.00
+ 0 0 1.00 60.00 120.00
+ 4725 0 7425 0
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 1 2
+ 0 0 1.00 60.00 120.00
+ 0 0 1.00 60.00 120.00
+ 5220 225 7425 225
+4 0 0 50 -1 2 14 0.0000 4 165 630 3960 -855 task 1\001
+4 0 0 50 -1 2 14 0.0000 4 165 630 3960 -630 task 2\001
+4 0 0 50 -1 2 14 0.0000 4 165 630 3960 -405 task 3\001
+4 0 0 50 -1 2 14 0.0000 4 165 630 3960 -180 task 4\001
+4 0 0 50 -1 2 14 0.0000 4 165 630 3960 45 task 5\001
+4 0 0 50 -1 2 14 0.0000 4 165 630 3960 270 task 6\001
Index: /anr-2010/obsolete/dependence-task-v.fig
===================================================================
--- /anr-2010/obsolete/dependence-task-v.fig (revision 274)
+++ /anr-2010/obsolete/dependence-task-v.fig (revision 274)
@@ -0,0 +1,72 @@
+#FIG 3.2 Produced by xfig version 3.2.5
+Landscape
+Center
+Metric
+Letter
+100.00
+Single
+-2
+1200 2
+6 2970 2070 3600 2520
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2970 2070 3600 2070 3600 2520 2970 2520 2970 2070
+4 1 0 50 -1 18 16 0.0000 4 195 315 3285 2385 T3\001
+-6
+6 4050 2070 4680 2520
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4050 2070 4680 2070 4680 2520 4050 2520 4050 2070
+4 1 0 50 -1 18 16 0.0000 4 195 315 4365 2385 T4\001
+-6
+6 3510 1170 4140 1620
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 3510 1170 4140 1170 4140 1620 3510 1620 3510 1170
+4 1 0 50 -1 18 16 0.0000 4 195 315 3825 1485 T2\001
+-6
+6 3510 270 4140 720
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 3510 270 4140 270 4140 720 3510 720 3510 270
+4 1 0 50 -1 18 16 0.0000 4 195 315 3825 585 T5\001
+-6
+6 3510 -900 4140 -450
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 3510 -900 4140 -900 4140 -450 3510 -450 3510 -900
+4 1 0 50 -1 18 16 0.0000 4 195 315 3825 -585 T1\001
+-6
+6 3510 -2025 4140 -1575
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 3510 -2025 4140 -2025 4140 -1575 3510 -1575 3510 -2025
+4 1 0 50 -1 18 16 0.0000 4 195 315 3825 -1710 T6\001
+-6
+6 3510 3600 4140 4050
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 3510 3600 4140 3600 4140 4050 3510 4050 3510 3600
+4 1 0 50 -1 18 16 0.0000 4 195 315 3825 3915 T7\001
+-6
+2 2 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 5
+ 2700 0 4950 0 4950 2700 2700 2700 2700 0
+2 2 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 5
+ 2475 -1125 5175 -1125 5175 2925 2475 2925 2475 -1125
+2 2 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 5
+ 2250 -2250 5400 -2250 5400 3150 2250 3150 2250 -2250
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
+ 0 0 1.00 60.00 120.00
+ 3825 -1575 3825 -1125
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
+ 0 0 1.00 60.00 120.00
+ 3825 3150 3825 3600
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
+ 0 0 1.00 60.00 120.00
+ 3870 1620 4365 2070
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
+ 0 0 1.00 60.00 120.00
+ 3870 1620 3285 2070
+2 1 0 3 0 7 50 -1 -1 8.000 0 0 -1 1 0 10
+ 0 0 1.00 60.00 120.00
+ 3825 720 3825 765 3825 855 3825 900 3825 945 3825 990
+ 3825 1035 3825 1080 3825 1125 3825 1170
+2 1 0 3 0 7 50 -1 -1 8.000 0 0 -1 1 0 2
+ 0 0 1.00 60.00 120.00
+ 3831 -450 3831 0
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2025 -2475 5625 -2475 5625 4275 2025 4275 2025 -2475
+4 0 0 50 -1 18 16 0.0000 4 195 315 5175 4050 T0\001
Index: /anr-2010/obsolete/dependence-test.fig
===================================================================
--- /anr-2010/obsolete/dependence-test.fig (revision 274)
+++ /anr-2010/obsolete/dependence-test.fig (revision 274)
@@ -0,0 +1,71 @@
+#FIG 3.2 Produced by xfig version 3.2.5-alpha5
+Landscape
+Center
+Metric
+Letter
+100.00
+Single
+-2
+1200 2
+6 4635 -1575 7560 -1170
+4 1 0 50 -1 2 14 0.0000 4 165 120 4725 -1170 0\001
+4 1 0 50 -1 2 14 0.0000 4 165 120 5175 -1170 6\001
+4 1 0 50 -1 2 14 0.0000 4 165 240 5625 -1170 12\001
+4 1 0 50 -1 2 14 0.0000 4 165 240 6075 -1170 18\001
+4 1 0 50 -1 2 14 0.0000 4 165 240 6525 -1170 24\001
+4 1 0 50 -1 2 14 0.0000 4 165 240 6975 -1170 30\001
+4 1 0 50 -1 2 14 0.0000 4 165 240 7425 -1170 36\001
+4 1 0 50 -1 2 14 0.0000 4 165 675 6075 -1395 month\001
+-6
+2 1 1 1 0 7 50 -1 -1 4.000 0 0 7 0 0 2
+ 4725 -1080 4725 360
+2 1 1 1 0 7 50 -1 -1 4.000 0 0 7 0 0 2
+ 5175 -1080 5175 360
+2 1 1 1 0 7 50 -1 -1 4.000 0 0 7 0 0 2
+ 5625 -1080 5625 360
+2 1 1 1 0 7 50 -1 -1 4.000 0 0 7 0 0 2
+ 6075 -1080 6075 360
+2 1 1 1 0 7 50 -1 -1 4.000 0 0 7 0 0 2
+ 6525 -1080 6525 360
+2 1 1 1 0 7 50 -1 -1 4.000 0 0 7 0 0 2
+ 6975 -1080 6975 360
+2 1 1 1 0 7 50 -1 -1 4.000 0 0 7 0 0 2
+ 7425 -1080 7425 360
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 1 2
+ 0 0 1.00 60.00 120.00
+ 0 0 1.00 60.00 120.00
+ 4725 -900 6525 -900
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 1 2
+ 0 0 1.00 60.00 120.00
+ 0 0 1.00 60.00 120.00
+ 5625 -450 7380 -450
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 1 2
+ 0 0 1.00 60.00 120.00
+ 0 0 1.00 60.00 120.00
+ 5625 -225 7380 -225
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 1 2
+ 0 0 1.00 60.00 120.00
+ 0 0 1.00 60.00 120.00
+ 6075 225 7425 225
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 1 2
+ 0 0 1.00 60.00 120.00
+ 0 0 1.00 60.00 120.00
+ 5220 -765 7425 -765
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 1 2
+ 0 0 1.00 60.00 120.00
+ 0 0 1.00 60.00 120.00
+ 6075 -630 7425 -630
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 1 2
+ 0 0 1.00 60.00 120.00
+ 0 0 1.00 60.00 120.00
+ 4725 -90 7425 -90
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 1 2
+ 0 0 1.00 60.00 120.00
+ 0 0 1.00 60.00 120.00
+ 6075 45 7425 45
+4 0 0 50 -1 2 14 0.0000 4 165 630 3960 -855 task 1\001
+4 0 0 50 -1 2 14 0.0000 4 165 630 3960 -630 task 2\001
+4 0 0 50 -1 2 14 0.0000 4 165 630 3960 -405 task 3\001
+4 0 0 50 -1 2 14 0.0000 4 165 630 3960 -180 task 4\001
+4 0 0 50 -1 2 14 0.0000 4 165 630 3960 45 task 5\001
+4 0 0 50 -1 2 14 0.0000 4 165 630 3960 270 task 6\001
Index: /anr-2010/obsolete/wp-IRISA.tex
===================================================================
--- /anr-2010/obsolete/wp-IRISA.tex (revision 274)
+++ /anr-2010/obsolete/wp-IRISA.tex (revision 274)
@@ -0,0 +1,79 @@
+\documentclass[11pt,a4paper]{article}
+
+\usepackage[french]{babel}
+\usepackage[utf8x]{inputenc}
+\usepackage{times}
+\usepackage[T1]{fontenc}
+\usepackage{aeguill}
+\usepackage{verbatim}
+\usepackage{algorithm,algorithmic}
+\usepackage{xmpmulti}
+\usepackage{graphicx}
+\usepackage{color}
+
+\definecolor{gris25}{gray}{0.75}
+\definecolor{gris75}{gray}{0.30}
+
+
+\begin{document}
+
+\section {IRISA-WP}
+
+\subsection{Work Package 1 : Un compilateur reciblable pour MIPS étendu}
+
+Délivrable : software
+
+Implémentation d'un back-end de compilation ciblant une version étendue du processeurs MIPS, et
+opérant à partir de la représentation intermédiaire commune définie en \ref{?} et issue de GCC.
+Ce \emph{back-end} intÚgrera en particulier des passes d'extraction de motifs de calculs
+(sous-graphes), ainsi une passe de sélection d'intructions basée sur des techniques de couvertures
+de graphes, permettant d'exploiter au mieux les motifs d'instruction ``spécialisés'' spécifiés
+par l'utilisateur et/ou extraits à partir de l'application.
+\textcolor{gris75}{Ici, il faut voir sir la RI prposée ne permettrait pas de regénérer un code
+C dans lequel l'utilisation d'instruction spécialisée se fait au travers de directives de type
+\texttt{asm\{ \ldots \}} . une telle approche offrirait une flexibilité accrue, sans
+impacter la qualité/performance des résultats obtenus.}
+
+\subsection{Work Package 2 : Définition d'un modÚle simplifié de micro-architecture MIPS extensible}
+
+Délivrable : software
+
+Définition d'un modÚle extensible de micro-architecture basée sur un processeur de type MIPS
+pipeliné à 5 étage (incluant cache de données et instruction), offrant à l'utilisateur
+la possibilité de définir ses propres extensions architecturales, au travers d'un Domain
+Specific Language (on exploitera les technologies d'IDM XText-EMF).
+
+On mettra également en {\oe}uvre un outil de génératiion de description matérielle synthétisable
+(VHDL) de la micro-architecture à partir de ce modÚle, en utilisant des techonologies d'Ingénierie
+dirigée par les modÚles (EMF-XPAND)
+
+Deux version de cet outil sont envisagées, dans la premiÚre (qui est l'object de ce WP), on
+restreindra les possibilités de communication entre le processeur et ses extension à des communictaion passant par la file de
+regsitre du processeur (en permettant éventuellement un plus grand nombre d'accÚs en
+lecture.écriture par cycle).
+
+\subsection{Work Package 3 : Définition d'un modÚle complexe de micro-architecture MIPS extensible}
+
+Délivrable : rapport/software ?
+
+Dans la seconde version (plus orientée exploratoire) on souhaite pouvoir lever la limitaion portant
+sur les communications et permettre un couplage plus fin entre les extensions et le coeur de la
+micro-rachgitcture, par exemple, en proposant un accÚs direct au cache de données et/ou en donnant
+la possibiliteé aux extensions de réutiliser les opérateurs (par exemple le multiplieur
+$32 \times 32$ \, bits) mis en oeuvre dans le chemin de donnée natif du processeur.
+
+Ici on pourrait également envisager des connections directes avec d'autres composants au travers de
+structures similaire aux \emph{FSL} disponibles sur les processeurs softcore Microblaze de la
+société Xilinx.
+
+\subsection{Work Package 4 : Définition d'un modÚle complexe de micro-architecture MIPS extensible}
+
+Délivrable : rapport
+
+Le dernier \emph{package} a également un caractÚre exploratoire, et portera sur l'intégration de ce
+type d'extension architecturales au sein d'un compilateur. En particulier, il s'agira d'étudier
+comment il est possible d'intégrer ces instructions complexes dans la passe de selection de code,
+tout en s'assurant que leur contraintes d'utilisation soient respectées.
+
+
+\end{document}
Index: /anr-2010/section-1.tex
===================================================================
--- /anr-2010/section-1.tex (revision 274)
+++ /anr-2010/section-1.tex (revision 274)
@@ -0,0 +1,165 @@
+% les objectifs globaux,
+The market of digital systems is about 4,600 M\$ today and is estimated to
+5,600 M\$ in 2012. However the ever growing applications complexity involves
+integration of heterogeneous technologies and requires the design of
+complex Multi-Processors System on Chip (MPSoC).
+\\
+During the last decade, the design of ASICs (Application Specific
+Integrated Circuits) appeared to be more and more reserved to high volume markets, because
+the design and fabrication costs of such components exploded, due to increasing NRE (Non
+Recurring-Engineering) costs.
+Fortunately, FPGA (Field Programmable Gate Array) components, such as the
+Virtex5 family from \xilinx or the Stratix4 family from \altera, can nowadays
+implement a complete MPSoC with multiple processors and several dedicated
+coprocessors for a few Keuros per device. Many applications are initially captured
+algorithmically in High-Level Languages (HLLs) such as C/C++. This has led to growing interest
+in tools that can provide an implementation path directly from HLLs to hardware.
+Thus, Electronic System Level (ESL) design methodologies (Virtual Prototyping,
+Co-design, High-Level Synthesis...) are now mature and allow the automation of
+a system-level design flow. Unfortunately, ESL tool development to date has primarily focused
+on the design of hard-wired devices i.e. ASICs and ASSPs (Application Specific Standard Product).
+However, the increasing sophistication of FPGAs has accelerated the need for FPGA-based ESL design
+methodologies. ESL methodologies hold the promise of streamlining the design approach by accepting
+designs written in C/C++ language and implementing the function straight into FPGA.
+We believe that coupling FPGA technologies and ESL methodologies
+will allow both SMEs (Small and Medium Enterprise) and
+major companies to design innovative devices and to enter new, low and
+medium volume markets.
+\parlf
+The objective of COACH is to provide an integrated design flow, based on the
+SoCLib infrastructure~\cite{soclib}, and optimized for the design of
+multi-processors digital systems targeting FPGA devices.
+Such digital systems are generally integrated
+into one or several chips, and there are two types of applications:
+They can be embedded (autonomous) applications
+such as personal digital assistants (PDA), ambiant computing components,
+or wireless sensor networks (WSN).
+They can also be extension boards connected to a PC to accelerate a specific computation,
+as in High-Performance Computing (HPC) or High-Speed Signal Processing (HSSP).
+\parlf
+%verrous scientifiques et techniques
+The COACH environment will integrate several hardware and software technologies:
+\begin{description}
+\item[Design Space Exploration:]
+
+ The COACH environment will allow to describe an application as a process
+ network i.e. a set of tasks communicating through FIFO channels.
+ COACH will allow to map the application on a shared-memory, MPSoC architecture.
+ It will permit to easily explore the design space to help the system designer
+ to define the proper hardware/software partitioning of the application.
+ For each point in the design space, metrics such as throughput, latency, power
+ consumption, silicon area, memory allocation and data locality will be provided.
+ These criteria will be evaluated by using the SoCLib virtual prototyping infrastructure
+ and high-level estimation methodologies.
+
+\item[Hardware Accelerators Synthesis (HAS):]
+ COACH will allow the automatic generation of hardware accelerators when required.
+ Hence, High-Level Synthesis (HLS) tools, Application Specific Instruction Processor
+ (ASIP) design environment and source-level transformation tools (loop transformations
+ and memory optimisation) will be provided.
+ This will allow further exploration of the micro-architectural design space.
+ HLS tools are sensitive to the coding style of the input specification and the domain
+ they target (control vs. data dominated).
+ The HLS tools of COACH will support a common language and coding style to avoid
+ re-engineering by the designer.
+\item[Platform based design:]
+ COACH will handle both \altera and \xilinx FPGA devices.
+ COACH will define architectural templates that can be customized by adding
+ dedicated coprocessors and ASIPs and by fixing template parameters such as
+ the number of embedded processors, the number of sizes of embedded memory banks
+ or the embedded the operating system.
+ However, the specification of the application will be independant of both the
+ architectural template and the target FPGA device.
+ Basically, the following three architectural templates will be provided:
+ \begin{enumerate}
+ \item A Neutral architectural template based on the SoCLib IP core library and the
+ VCI/OCP communication infrastructure.
+ \item An \altera architectural template based on the \altera IP core library, the
+ AVALON system bus and the NIOS processor.
+ \item A \xilinx architectural template based on the Xilinx IP core library, the PLB
+ system bus and the Microblaze processor.
+ \end{enumerate}
+\item[Hardware/Software communication middleware:]
+ COACH will implement an homogeneous HW/SW communication infrastructure and
+ communication APIs (Application Programming Interface), that will be used for
+ communications between software tasks running on embedded processors and
+ dedicated hardware coprocessors.
+\end{description}
+The COACH design flow will be dedicated to system designers, and will as
+much as possible hide the hardware characteristics to the end-user.
+%From the end user point of view, the specification of the application will be
+%independant from both the architectural template and from the selected FPGA
+%family.
+\parlf
+% le programme de travail
+%The COACH project targets fundamental issues related to design methodologies for
+%digital systems by providing estimation, exploration and design tools targeting both
+%performance and power optimization at all the abstraction levels of the flow (system,
+%architecture, algorithm and logic).
+To reach this ambitious goal, the project will rely on the experience and the
+complementariness of partners in the following domains:
+Operating system and communication middleware (\tima, \upmc),
+MPSoC architectures (\tima, \ubs, \upmc),
+ASIP architectures (\irisa),
+High Level Synthesis (\tima, \ubs, \upmc), and compilation (\lip).
+\\
+The COACH project does not start from scratch.
+It stronly relies on the SoCLib virtual prototyping platform~\cite{soclib} for prototyping, (DSX, component library), operating systems (MUTEKH, DNA/OS).
+It also leverages on several existing technologies:
+on the GAUT~\cite{gaut08} and UGH~\cite{ugh08} tools for HLS,
+on the ROMA~\cite{roma} project for ASIP,
+on the SYNTOL~\cite{syntol} and BEE~\cite{bee} tools for source-level analysis and transformations
+and on the \xilinx and \altera IP core libraries.
+Finally it will use the \xilinx and \altera logic and physical synthesis tools to generate the FPGA configuration
+bitstreams.
+\parlf
+The COACH proposal has been prepared during one year by a technical working group
+involving the 5 academic partners (one monthly meeting from january 2009 to february
+2010). The objective was to analyse the issues of integrating
+and enhancing the existing tools and tecnnologies into a unique framework.
+Most of the general software architecture of the proposed design flow (including the
+exchange format specification) has been define by this working group.
+Because the COACH project leanes on the ANR SoCLib platform, it may be described as an
+extension of the SoCLib platform.
+%The main development steps of the COACH project are:
+%\begin{enumerate}
+% \item Definition of the end user inputs:
+% The coarse grain parallelism of the application will be described as a communicating
+% task graph, each task being described in C language.
+% Similarly the architectural templates with their parameters and the design constraints
+% will be specified.
+% \item Definition of an internal format for representing task.
+% \item Development of the GCC pluggin for generating the internal format of a
+% C task.
+% \item Adaptation of the existing HAS tools (BEE, SYNTOL, UGH, GAUT) to read and write
+% the internal format. This will allow to swap from one tool to another one, and to
+% chain them if necessary.
+% \item Modification of the DSX tool (Design Space eXplorer) of the SocLib
+% platform to generate the bitstream for the various FPGA families and architectural
+% templates.
+% \item Development of new tools such as ASIP compiler, HPC design environment and
+% dynamic reconfiguration of FPGA devices.
+%\end{enumerate}
+\parlf
+Two major FPGA companies are involved in the project: \xilinx will contribute
+as a contractual partner providing documentation and manpower; \altera will contribute as
+a supporter (see letter page \pageref{supp:1})
+providing documentation and development boards. These two companies are strongly motivated
+to help the COACH project to generate efficient bitsreams for both FPGA families.
+The role of the industrial partners \bull, \thales, \navtel and \zied is to provide
+real use cases to benchmark the COACH design environment and to analyze the designer productivity
+improvements.
+\parlf
+Following the general policy of the SoCLib platform, the COACH project will be an open
+infrastructure, available in the framework of the SoCLib server.
+The architectural templates, and the COACH software tools will be distributed under the
+GPL license. The VHDL synthesizable models for the neutral architectural template (SoCLib
+IP core library) will be freely available for non commercial use. For industrial exploitation
+the technology providers are ready to propose commercial licenses, directly to the end user,
+or through a third party.
+\parlf
+Finally, the COACH project is already supported by a large number of PMEs, as demonstrated by the
+"letters of interest" (see Annex B), that have collected during the preparation of the project :
+ADACSYS, MDS, INPIXAL, CAMKA System, ATEME, ALSIM, SILICOMP-AQL,
+ABOUND Logic, EADS-ASTRIUM.
+
Index: /anr-2010/section-2.1.tex
===================================================================
--- /anr-2010/section-2.1.tex (revision 274)
+++ /anr-2010/section-2.1.tex (revision 274)
@@ -0,0 +1,129 @@
+\begin{table}\leavevmode\center
+\begin{small}\begin{tabular}{|l|l|l|l|}\hline
+Segment & 2010 & 2011 & 2012 \\\hline\hline
+Communications & 1,867 & 1,946 & 2,096 \\
+High end & 467 & 511 & 550 \\\hline
+Consumer & 550 & 592 & 672 \\
+High end & 53 & 62 & 75 \\\hline
+Automotive & 243 & 286 & 358 \\
+High end & - & - & - \\\hline
+Industrial & 1,102 & 1,228 & 1,406 \\
+High end & 177 & 188 & 207 \\\hline
+Military/Aereo & 566 & 636 & 717 \\
+High end & 56 & 65 & 82 \\\hline\hline
+Total FPGA/PLD & 4,659 & 5,015 & 5,583 \\
+Total High-End FPGA & 753 & 826 & 914 \\\hline
+\end{tabular}\end{small}
+\caption{\label{fpga_market} Gartner estimation of worldwide FPGA/PLD consumption (Millions \$)}
+\end{table}
+%
+Microelectronic components allow the integration of complex functions into products, increases
+commercial attractivity of these products and improves their competitivity.
+Multimedia and tele-communication sectors have taken advantage from microelectronics facilities
+thanks to the developpment of design methodologies and tools for embedded systems.
+Unfortunately, the Non Recurring Engineering (NRE) costs involded in the design
+and manufacturing ASICs is very high.
+An IC foundry costs several billions of euros and the fabrication of a specific circuit
+costs several millions. For example a conservative estimate for a 65nm ASIC project is 10
+million USD.
+Consequently, it is more and more unaffordable to design and fabricate ASICs for low and medium
+volume markets.
+\parlf
+Today, FPGAs become important actors in the computational domain that was originally dominated
+by microprocessors and ASICs. Just like microprocessors, FPGA based systems can be reprogrammed
+on a per-application basis. For many applications, FPGAs offer significant performance benefits over
+microprocessors implementation. There is still a performance degradation of one order
+of magnitude versus an equivalent ASIC implementations, but low cost
+(500 euros to 10K euros), fast time-to-market and flexibility of FPGAs make them an attractive
+choice for low-to-medium volume applications.
+Since their introduction in the mid eighties, FPGAs evolved from a simple,
+low-capacity gate array to devices (\altera STRATIX III, \xilinx Virtex V) that
+provide a mix of coarse-grained data path units, memory blocks, microprocessor cores,
+on chip A/D conversion, and gate counts by millions. This high logic capacity allows to implement
+complex systems like multi-processors platform with application dedicated coprocessors.
+Table~\ref{fpga_market} shows the estimation of the FPGA worldwide market in the next years in
+various application domains. The ``high end'' lines concern only FPGA with high logic
+capacity for complex system implementations.
+This market is in significant expansion and is estimated to 914\,M\$ in 2012.
+%The HPC market size is estimated today by FPGA providers at 214\,M\$.
+%Using FPGA limits the NRE costs to the design cost.
+%This boosts the developpment of automatic design tools and methodologies.
+%
+\parlf
+Today, several companies (Atipa, blue-arc, Bull, Chelsio, Convey, CRAY, DataDirect, DELL, hp,
+Wild Systems, IBM, Intel, Microsoft, Myricom, NEC, nvidia etc) are making systems where demand
+for very high performance (HPC) primes over other requirements. They tend to use the highest
+performing devices like Multi-core CPUs, GPUs, large FPGAs, custom ICs and the most innovative
+architectures and algorithms. These companies show up in different "traditional" applications and market
+segments like computing clusters (ad-hoc), servers and storage, networking and Telecom, ASIC
+emulation and prototyping, military/aereo etc. The HPC market size is estimated today by FPGA providers
+at 214\,M\$.
+This market is dominated by Multi-core CPUs and GPUs based solutions and the expansion
+of FPGA-based solutions is limited by the lack of design automation.
+\\
+\\
+Nowadays, there are no commercial or academic tools covering the whole design flow
+from the system level specification to the bitstream generation neither for embedded system design
+nor for HPC.
+
+%PC => IA et Alain
+%Le paragraphe ci dessous n'a rien a faire dans la partie Economic et societal issue
+%Je le mets donc en commentaire
+
+%By using SOPC Builder~\cite{spoc-builder} from \altera, designers can select and
+%parameterize components from an extensive drop-down list of IP cores (I/O core, DSP,
+%processor, bus core, ...) as well as incorporate their own IP.
+%Designers can then generate a synthesized netlist, simulation test bench and custom
+%software library that reflect the hardware configuration.
+%Nevertheless, SOPC Builder does not provide any facilities to synthesize coprocessors and to
+%simulate the platform at a high design level (systemC).
+%In addition, SOPC Builder is proprietary and only works together with \altera's Quartus compilation
+%tool to implement designs on \altera devices (Stratix, Arria, Cyclone).
+%PICO~\cite{pico} and CATAPULT-C~\cite{catapult-c} allow to synthesize
+%coprocessors from a C++ description.
+%Nevertheless, they can only deal with data dominated applications and they do not handle
+%the platform level.
+%Similarly, the System Generator for DSP~\cite{system-generateur-for-dsp} is a plug-in to
+%Simulink that enables designers to develop high-performance DSP systems for \xilinx FPGAs.
+%Designers can design and simulate a system using MATLAB and Simulink. The tool will then
+%automatically generate synthesizable Hardware Description Language (HDL) code mapped to
+%\xilinx pre-optimized macro-cells.
+%However, this tool targets only DSP based algorithms.
+%\\
+%Consequently, a designer developping an embedded system needs to master four different
+%design environments:
+%\begin{enumerate}
+% \item a virtual prototyping environment such as SoCLib for system level exploration,
+% \item an architecture compiler (such as SOPC Builder from \altera, or System generator
+% from \xilinx) to define the hardware architecture,
+% \item one or several HLS tools (such as PICO~\cite{pico} or CATAPULT-C~\cite{catapult-c}) for
+% coprocessor synthesis,
+% \item and finally backend synthesis tools (such as Quartus or Synopsys) for the bit-stream generation.
+%\end{enumerate}
+%Furthermore, mixing these tools requires an important interfacing effort and this makes
+%the design process very complex and achievable only by designers skilled in many domains.
+
+\begin{center}\begin{minipage}{.9\linewidth}\textit{
+The aim of the COACH project is to integrate all these design steps into a single design framework
+and to allow \textbf{pure software} developpers to design embedded systems.
+}\end{minipage}\end{center}
+
+%PC => IA et Alain
+% le paragraphe suivant est coupé collé de la section suivante 2.2
+
+
+\parlf
+The COACH project proposes an open-source framework for mapping multi-tasks software applications
+on Field Programmable Gate Array circuits (FPGA).
+It aims to propose solutions to the societal/economical challenges by
+providing SMEs novel design capabilities enabling them to increase their
+design productivity with design exploration and synthesis methods that are placed on top
+of the state-of-the-art methods.
+We believe that the combination of a design environment dedicated to software developpers
+and FPGA targets,
+will allow small and even very small companies to propose embedded system and accelerating solutions
+for standard software applications with attractive and competitive prices.
+This new market may explode in the same way as the micro-computer market in the eighties,
+whose success was due to the low cost of the first micro-processors (compared to main frames)
+and the advent of high level programming languages which allowed a high number of programmers
+to launch start-ups in software engineering.
Index: /anr-2010/section-2.2.tex
===================================================================
--- /anr-2010/section-2.2.tex (revision 274)
+++ /anr-2010/section-2.2.tex (revision 274)
@@ -0,0 +1,221 @@
+% Relevance of the proposal
+%The COACH proposal addresses directly the \emph{Embedded Systems} item of
+%the ARPEGE program.
+
+%PC => IA et ALain
+%J'aui déplacé le pargraphe ci dessous en conclusion de la section précédente 2.1
+
+%It aims to propose solutions to the societal/economical challenges by
+%providing SMEs novel design capabilities enabling them to increase their
+%design productivity with design exploration and synthesis methods that are placed on top
+%of the state-of-the-art methods.
+%This project proposes an open-source framework for mapping multi-tasks software applications
+%on Field Programmable Gate Array circuits (FPGA).
+%%%
+\parlf
+COACH will contribute to build an open design and run-time
+environment, including communication middleware and tools to support
+developers in the production of embedded software, through all phases of the software lifecycle,
+from requirements analysis downto deployment and maintenance.
+More specifically, COACH focuses on:
+\begin{itemize}
+\item High level methods and concepts (esp. requirements and architectural level) for system
+design, development and integration, addressing complexity aspects and modularity.
+\item Open and modular design environments, enabling flexibility and extensibility by
+means of new or sector-specific tools and ensuring consistency and traceability along the
+development lifecycle.
+\item Light/agile methodologies and adaptive workflow providing a dynamic and adaptive
+environment, suitable for co-operative and distributed development.
+\end{itemize}
+COACH outcome will contribute to strengthen Europe's competitive position by developing
+technologies and methodologies for product design, focusing (in compliance with the
+%scope of the above program) on technologies, engineering methodologies, novel tools,
+%methods which facilitate resource use efficiency. The approaches and tools to be developed
+%in COACH will enable new and emerging information technologies for the development,
+%methods which facilitate resource use efficiency. The COACH approaches and tools
+scope of the above program) on technologies, engineering methodologies, novel tools
+which facilitate resource use efficiency. The COACH approaches and tools
+will enable new and emerging information technologies for the development,
+manufacturing and integration of devices and related software into end-products.
+%%%
+\parlf\noindent
+The COACH project will benefit from a number of previous recent projects:
+\begin{description}
+ \item[SOCLIB]
+ The SoCLib ANR platform (2007-2009) is an open infrastructure developped by
+ 10 academic laboratories (TIMA, LIP6, Lab-STICC, IRISA, ENST, CEA-LIST, CEA-LETI, CITI, INRIA-Futurs, LIS) and 6
+ industrial companies (Thales Communications, Thomson R\&D, STMicroelectronics, Silicomp, MDS, TurboConcept).
+ It supports system level virtual prototyping of shared memory, multi-processors
+ architectures, and provides tools to map multi-tasks software application on these
+ architectures, for reliable performance evaluation.
+ The core of this platform is a library of SystemC simulation models for
+ general purpose IP cores such as processors, buses, networks, memories, IO controller.
+ The platform provides also embedded operating systems and software/hardware
+ communication middleware.
+ The synthesisable VHDL models of IPs are not part of the SoCLib platform, and
+ COACH will enhance SoCLib by providing the synthesisable VHDL models required
+ for FPGA synthesis.
+ \item[ROMA] The ROMA ANR project \cite{roma}
+ involving IRISA (CAIRN team), LIRMM, CEA List, THOMSON France R\&D,
+ proposes to develop a reconfigurable processor, exhibiting high
+ silicon density and power efficiency, able to adapt its computing
+ structure to computation patterns that can be speed-up and/or
+ power efficient. %The ROMA project study a pipeline of
+ %evolved low-power coarse grain reconfigurable operators to avoid
+ %traditional overhead, in reconfigurable devices, related to the
+ %interconnection network.
+ The project will borrow from the ROMA
+ ANR project and the ongoing joint INRIA-STMicro
+ Nano2012 project to adapt existing pattern extraction algorithms
+ and datapath merging techniques to ASIP synthesis.
+% and datapath merging techniques to the synthesis of customized
+% ASIP processors.
+ \item[TSAR]
+ The TSAR MEDEA+ project (2008-2010) involving BULL, THALES and \upmc targets the design of a
+% The TSAR MEDEA+ project (2008-2010) targets the design of a
+ scalable, coherent shared memory, multi-cores processor architecture, and uses the SoCLib
+ plaform for virtual prototyping. COACH will benefit from the synthesizable VHDL
+ models developped in the framework of TSAR (MIPS32 processor core, and RING interconnect).
+ \item[BioWic]
+ On the HPC application side, we also hope to benefit from the experience in
+ hardware acceleration of bioinformatic algorithms/workfows gathered by the
+ CAIRN group in the context of the ANR BioWic project (2009-2011), so as to
+ be able to validate the framework on real-life HPC applications.
+\end{description}
+%%%
+\parlf\noindent
+The laboratories involved in the COACH project have a well estabished expertise
+%in the following domains:
+in the domains:
+\begin{itemize}
+ \item
+ In the field of High Level Synthesis (HLS), the project
+ leverages on know-how acquired over the last 15 years with the GAUT~\cite{gaut08} project
+ developped by the \ubs laboratory, and with the UGH~\cite{ugh08} project developped
+ by the \upmc and \tima laboratories.
+ \item
+ Regarding system level architecture, the project is based on the know-how
+ acquired by \upmc and \tima in the framework of various projects
+ in the field of communication architectures for shared memory multi-processors systems
+ (COSY~\cite{cosy}, DISYDENT~\cite{disydent05} or DSPIN~\cite{dspin08} of MEDEA-MESA).
+ As an example, the DSPIN project is now used in the TSAR project.
+ \item
+ Regarding Application Specific Instruction Processor (ASIP) design, the
+ CAIRN group at INRIA Rennes -- Bretagne Atlantique benefits from several years of
+ expertise in the domain of retargetable compiler
+ (Armor/Calife~\cite{CODES99} since 1996, and the Gecos
+ compilers~\cite{ASAP05} since 2002).
+\item
+ In the field of compilers, the \lip Compsys group was founded in 2002
+ by several senior researchers with experience in
+ high performance computing and automatic parallelization. They have been
+ among the initiators of the polyhedral model, a theory which serve to
+ unify many parallelism detection and exploitation techniques for regular
+ programs. It is expected that the techniques developped by \lip for
+ parallelism detection, scheduling \cite{Feau:92aa,Feau:92bb},
+ process construction \cite{Feau:96} and memory management \cite{bee}
+ will be very useful as a front-end for HLS tools.
+\end{itemize}
+%%%
+\parlf\noindent
+The COACH project answers to several of the challenges found in different axis of the
+call for proposals.%Keywords of the call are indicated below in italic writing.
+\begin{description}
+\item[Axis 1] \textit{Architectures des syst\`{e}mes embarqu\'{e}s} \\
+COACH will address new embedded systems architectures by allowing the design of
+Multi-Core Systems-on-Chip (possibly heterogeneous) on FPGA according to the design
+constraints and objectives (real-time, low-power). It will permit designing complex SoC
+based on IP cores (memory, peripherals...),
+running Embedded Software, as well as an Operating System with associated middleware and
+API and using hardware accelerator automatically generated. It will also permit to use
+efficiently different dynamic system management techniques and re-configuration mechanisms.
+\textbf{Thereby COACH well corresponds to axis 1}.
+%
+\item[Axis 2] \textit{Infrastructures pour l'Internet, le calcul intensif ou les services} \\
+COACH will address High-Performance Computing (HPC) by helping designers to accelerate an
+application running on a PC.
+By providing tools that translate high level language programs to FPGA
+configurations, COACH will allow to easily migrate critical parts into an FPGA plugged to the
+PC bus (through a communication link like PCI/X).
+Moreover, Dynamic Partial Reconfiguration will be used for improving HPC performance
+as well as reducing the required area.
+\textbf{Thereby COACH partially corresponds to axis 2}.
+%
+% IA2PC: comme ce sont des axes tertiaire, il faut faire + court que primaire et
+% IA2PC: secondaire.
+%VERS 3
+%\item[Axis 3] \textit{Robotique et contr\^{o}le/commande} \\
+%Manufacturing technology employs more and more SoC.
+%COACH will permit to design such complex digital systems.
+%\textbf{Thereby COACH indirectly answers to axis 3 too}.
+
+
+%\item[Axis 3 \& 5] \textit{Robotique et contr\^{o}le/commande} and \textit{S\'{e}curit\'{e} et suret\'{e}} \\
+%VERS 1
+%Future control applications employ more and more SoC.
+%Application domains for such systems are for example the automotive domain, as well as the
+%aerospace and avionics domains.
+%In all cases, high performance and real time requirements are combined with
+%requirements to low power, low temperature, high dependability, and low cost.\\
+%Similary manufacturing, security and safety technologies require also more and more
+%computation power.
+%VERS 2 pour gagner de la place
+%Manufacturing, controling, security and safety technologies employ more and more SoC.
+%COACH will permit to design such complex digital systems.
+%\textbf{Thereby COACH indirectly answers to axis 3 and 5 too}.
+
+%\end{description}
+
+\item [Axis 3] \textit {Robotique et contr\^{o}le/commande}:
+
+COACH will address robotic and control applications by
+allowing to design complex systems based on MPSoC architecture.
+Like in the consumer electronics domain, future control applications
+will employ more and more SoC for safety and security applications.
+Application domains for such systems are for example automotive
+or avionics domains (e.g. collision-detection, intelligent navigation...).
+Manufacturing technology will also increasingly need high-end vision analysis and high-speed
+robot control.
+\textbf{Thereby COACH indirectly answers to axis 3}.
+
+\item [Axis 5] \textit {S\'{e}curit\'{e} et suret\'{e}}:
+
+The results of the COACH project will help users to build cryptographic secure systems implemented in
+hardware or both in software/hardware in an effective way, substantially enhancing the
+process productivity of the cryptographic algorithms hardware synthesis, improving the
+quality and reducing the design time and the cost of synthesised cryptographic devices.
+\textbf{Thereby COACH indirectly answers to axis 5}.
+
+\end{description}
+
+% IA2PC: 1) je ne vois pas trop ce que ca fait la.
+% IA2PC: 2) c'est deja dans le 2.1 pour le small business.
+% IA2PC: 3) Pour le large business, on avait mis ca dans la premiere version et je pense
+% IA2PC toujours que le large business est encore vise par COACH.
+% IA2PC Alain a enleve toute reference sur ce large business. Sa raison est +
+% IA2PC politico/stylistique: en parlant des 2 on n'est pas tres clair et on brouille
+% IA2PC le message. Je partage assez son avis, la version actuelle est + claire que
+% IA2PC celle d'avant. De plus on ne dit jamais que l'on ne vise pas les grosses
+% IA2PC boites.
+% IA2PC
+% IA2PC Bref je serai assez pour enlever ce paragraphe, et ne pas faire reference au large
+% IA2PC business meme dans les section precedente. Par contre d'essayer de recaser le reste dans
+% IA2PC les sections precedentes.
+%
+% VERS 2 pour gagner de la place je l'enleve
+
+%PC2IA ok pas de probleme
+
+% COACH technologies can be used in both large and small business, as they will permit users to design
+% embedded systems which meet a wide range of requirements: from low cost and low power consuming
+% devices to very high speed devices, based on parallel computing. For enterprises that will use embedded
+% systems designed via the approaches and tools targeted by COACH, there is the potential for greater
+% efficiency, improved business processes and models. The net results: lower costs, faster response times,
+% better service, and higher revenue.
+%\parlf
+Finally, it is worth to note that this project covers priorities defined by the commission
+experts in the field of Information Technolgies Society (IST) for Embedded
+Systems: \textit{ $<<$Concepts, methods and tools for designing systems dealing with systems complexity
+and allowing to apply efficiently applications and various products on embedded platforms,
+considering resources constraints (delays, power, memory, etc.), security and quality
+services$>>$}.
Index: /anr-2010/section-2.tex
===================================================================
--- /anr-2010/section-2.tex (revision 274)
+++ /anr-2010/section-2.tex (revision 274)
@@ -0,0 +1,113 @@
+Embedded systems (SoC and MPSoC) became an inevitable evolution in the microelectronic industry.
+Due to the exploding fabrication costs, the ASIC technology (Application Specific Integrated Circuit)
+is not an option for SMEs (Small and Medium Enterprises).
+Fortunately, the new FPGA (Field Programmable Gate Array) components,
+such as the Virtex5 family from \xilinx, or the Stratix4 family from \altera can implement a complete
+multi-processor architecture on a single device.
+But the design of embedded system is a long and complex task that requires expertise in software,
+software/hardware partionning, operating system, hardware design, VHDL/Verilog modeling.
+Only very few SMEs have these multiple expertises and are present on the embedded system market.
+\begin{center}\begin{minipage}{.8\linewidth}\textit{
+The major objective of COACH is to provide to SMEs an open-source framework to design
+embedded systems on FPGA devices by system designers.
+}\end{minipage}\end{center}
+%Current design methodologies provide quite low-level abstraction capabilities, and
+%there is an urgent need to leverage system level exploration through the use of a high-level
+%specification of the application and design space exploration tools.
+%The first system oriented approaches are appearing, among which those
+%based on C/C++ and SystemC are the most popular, but few of them are specifically targetting FPGAs.
+%%%
+\parlf
+The COACH project will leverage on the expertise gained in the field of virtual prototyping
+with the SoCLib platform, to propose a new design flow based on a small number of architectural templates.
+An architectural template is a generic, parameterized architecture, relying on a predefined library
+of IP cores.
+Besides using a specific collection of general purpose IP cores (such as processors cores,
+embedded memory controllers, system bus controllers, I/O and peripheral controllers), each architectural
+template can be enriched by dedicated hardware coprocessors, obtained by high level synthesis (HLS) tools.
+During this project, the COACH partners will develop three different architectural templates:
+\begin{enumerate}
+\item An \altera architectural template based on the \altera IP core library, the AVALON system bus and the NIOS processor.
+\item A \xilinx architectural template based on the \xilinx IP core library, the PLB system bus and the Microblaze processor.
+\item A Neutral architectural template based on the SoCLib IP core library and the VCI/OCP
+ communication infrastructure.
+\end{enumerate}
+The proposed design flow starts from a high level description of the application, specified as a set of
+parallel tasks written in C, without any assumption on the hardware or software implementation
+of these tasks. It lets the system
+designer in charge of expressing the coarse grain parallelism of the application, gives the designer
+the possibility to explore various mapping of the application on the selected template architecture,
+and offers a high predictability of results with respect to cost and performance objectives.
+\\
+When this interactive, system level, design space exploration is completed (converging to
+a specific mapping on a specific version of the selected architectural template), the rest of the flow
+is fully automated: The synthesisable VHDL models for the various hardware components, as well as the binary
+code for the software running on the embedded processors, and the bit-stream to program the the target FPGA
+will be automatically generated by the COACH tools.
+%
+\parlf
+The strength of the COACH approach is the strong integration of the high-level synthesis tools
+in a platform based design flow supporting virtual prototyping and design space exploration.
+Most building blocks already exist (resulting from previous projects): the GAUT
+or UGH synthesis tools, the MUTEKH or DNA embedded operating systems, the ASIP technology,
+the DSX exploration tool, the MWMR hardware/software communication middleware, the BEE parallelisation tool,
+as well as the SoCLib library of systemC simulation models. They must now be enhanced and integrated in
+a consistent design flow.
+%The five academic laboratories worked very closely during more than one year (one monthly meeting
+%in Paris from january 2009 to february 2010, to analyse the issues of interfacing and integrating
+%those various technologies, and to define the detailed architecture of the proposed design flow.
+%%%
+\parlf
+In HPC (High Performance Computing), the targeted application is an existing application
+running on a PC.
+The COACH framework helps designer to accelerate it by migrating critical parts into a
+SoC embedded into an FPGA device plugged to the PC PCI/X bus.
+\begin{center}\begin{minipage}{.8\linewidth}\textit{
+The second objective of COACH is to extend the framework to HPC.
+}\end{minipage}\end{center}
+This will allow SMEs to enter HPC market for the applications that are
+unadapted to the current GPU based solutions.
+%%%
+\parlf
+In summary, the COACH project is clearly oriented toward industry, even if most technology building blocks
+have been previously developed by academic laboratories.
+
+
+%Finally, the key points of the proposed design flow are :
+%\begin{itemize}
+%\item
+%\textbf{System level exploration}: The application coarse grain parallelism
+%is explicitely described as a Tasks and Communication Graph (TCG).
+%A template architecture is selected, and the performances are evaluated
+%on various variant of this architecture using the SoCLib virtual protyping
+%environment. This result in a specific hardware/software partitioning.
+%This system level exploration is fully controlled by the system designer, and is driven
+%by cost, throughput, latency and power consumption criteria.
+%
+%\item
+%\textbf{High Level Synthesis}: When dedicated hardware coprocessors have been
+%identified as mandatory, they will be generated by the high level synthesis (HLS) tools.
+%The COACH framework will integrate various HLS tools, supporting the micro-architectural space
+%design exploration. Here again, the exploration criteria are cost, throughput, latency
+%and power consumption.
+%At this stage, preliminary source-level transformations and optimisations by front-end
+%tools will be required to improve the efficiency of the back-end HLS tools.
+%
+%\item
+%\textbf{Early performance evaluation}: For each point in the design space,
+%figures of merit must be available such as throughput, latency, power
+%consumption, area, memory allocation and data locality. They are evaluated
+%by reliable estimators obtained by running the actual multi-task software
+%application on the virtual prototype.
+%
+%\item
+%\textbf{Independance from the Target FPGA}: The COACH description of the system
+%(both hardware and software) should be independent of the FPGA family.
+%Every point of the design space can be implemented on any FPGA component,
+%as long as it contains the hardware ressources required by the selected architectural template.
+%Basically, COACH will support both \altera and \xilinx FPGA families.
+%\end{itemize}
+%
+
+
+
Index: /anr-2010/section-3.1.tex
===================================================================
--- /anr-2010/section-3.1.tex (revision 274)
+++ /anr-2010/section-3.1.tex (revision 274)
@@ -0,0 +1,230 @@
+% vim:set spell:
+% vim:spell spelllang=en:
+
+Our project covers several critical domains in system design in order
+to achieve high performance computing. Starting from a high level description we aim
+at generating automatically both hardware and software components of the system.
+
+\subsubsection{High Performance Computing}
+% Un marché bouffé par les archi GPGPU tel que le FERMI de NvidiaCUDA programming language
+The High-Performance Computing (HPC) world is composed of three main families of architectures:
+many-core, GPGPU (General Purpose computation on Graphics Unit Processing) and FPGA.
+The first two families are dominating the market by taking benefit
+of the strength and influence of mass-market leaders (Intel, Nvidia).
+%such as Intel for many-core CPU and Nvidia for GPGPU.
+In this market, FPGA architectures are emerging and very promising.
+By adapting architecture to the software, % (the opposite is done in the others families)
+FPGAs architectures enable better performance
+(typically between x10 and x100 accelerations)
+while using smaller size and less energy (and heat).
+However, using FPGAs presents significant challenges~\cite{hpc06a}.
+First, the operating frequency of an FPGA is low compared to a high-end microprocessor.
+Second, based on Amdahl law, HPC/FPGA application performance is unusually sensitive
+to the implementation quality~\cite{hpc06b}.
+% Thus, the performance strongly relies on the detected parallelism.
+% (pour résumer les 2 derniers points)
+Finally, efficient design methodology are required in order to
+hide FPGA complexity and the underlying implantation subtleties to HPC users,
+so that they do not have to change their habits and can have equivalent design productivity
+than in others families~\cite{hpc07a}.
+
+%état de l'art FPGA
+HPC/FPGA hardware is only now emerging and in early commercial stages,
+but these techniques have not yet caught up.
+Industrial (Mitrionics~\cite{hpc08}, Gidel~\cite{hpc09}, Convey Computer~\cite{hpc10}) and academic (CHREC)
+researches on HPC-FPGA are mainly conducted in the USA.
+None of the approaches developed in these researches are fulfilling entirely the
+challenges described above. For example, Convey Computer proposes application-specific instruction set extension of x86 cores in FPGA accelerator,
+but extension generation is not automated and requires hardware design skills.
+Mitrionics has an elegant solution based on a compute engine specifically
+developed for high-performance execution in FPGAs. Unfortunately, the design flow
+is based on a new programming language (mitrionC) implying important designer efforts and poor portability.
+% tool relying on operator libraries (XtremeData),
+% Parle t-on de l'OPenFPGA consortium, dont le but est : "to accelerate the incorporation of reconfigurable computing technology in high-performance and enterprise applications" ?
+
+Thus, much effort is required to develop design tools that translate high level
+language programs to FPGA configurations.
+Moreover, as already remarked in~\cite{hpc11}, Dynamic Partial Reconfiguration~\cite{hpc12}
+(DPR, which enables changing a part of the FPGA, while the rest is still working)
+appears very interesting for improving HPC performance as well as reducing required area.
+
+\subsubsection{System Synthesis}
+Today, several solutions for system design are proposed and commercialized.
+The existing commercial or free tools do not
+cover the whole system synthesis process in a full automatic way. Moreover,
+they are bound to a particular device family and to IPs library.
+The most commonly used are provided by \altera and \xilinx to promote their
+FPGA devices. These representative tools used to synthesize SoC on FPGA
+are introduced below.
+\\
+The \xilinx System Generator for DSP~\cite{system-generateur-for-dsp} is a
+plug-in to Simulink that enables designers to develop high-performance DSP
+systems for \xilinx FPGAs.
+Designers can design and simulate a system using MATLAB and Simulink. The
+tool will then automatically generate synthesizable Hardware Description
+Language (HDL) code mapped to \xilinx pre-optimized algorithms.
+However, this tool targets only DSP based algorithms, \xilinx FPGAs and
+cannot handle a complete SoC. Thus, it is not really a system synthesis tool.
+\\
+In the opposite, SOPC Builder~\cite{spoc-builder} from \altera and \xilinx
+Platform Studio XPS from \xilinx allows to describe a system, to synthesis it,
+to program it into a target FPGA and to upload a software application.
+Both SOPC Builder and XPS, allow designers to select and parameterize components from
+an extensive drop-down list of IP cores (I/O core, DSP, processor, bus core, ...)
+as well as incorporate their own IP. Nevertheless, all the previously introduced tools
+do not provide any facilities to synthesize coprocessors and to simulate the platform
+at a high level (SystemC).
+System designer must provide the synthesizable description of its own IP-cores with
+the feasible bus interface. Design Space Exploration is thus limited
+and SystemC simulation is not possible neither at transactional nor at cycle
+accurate level.
+\\
+In addition, \xilinx System Generator, XPS and SOPC Builder are closed world
+since each one imposes their own IPs which are not interchangeable.
+Designers can then only generate a synthesized netlist, VHDL/Verilog simulation test
+bench and custom software library that reflect the hardware configuration.
+
+Consequently, a designer developing an embedded system needs to master four different
+design environments:
+\begin{enumerate}
+ \item a virtual prototyping environment (in SystemC) for system level exploration,
+ \item an architecture compiler to define the hardware architecture (Verilog/VHDL),
+ \item one or several third-party HLS tools for coprocessor synthesis (C to RTL),
+ \item and finally back-end synthesis tools for the bit-stream generation (RTL to bitstream).
+\end{enumerate}
+Furthermore, mixing these tools requires an important interfacing effort and this makes
+the design process very complex and achievable only by designers skilled in many domains.
+
+\subsubsection{High Level Synthesis}
+High Level Synthesis translates a sequential algorithmic description and a
+set of constraints (area, power, frequency, ...) to a micro-architecture at
+Register Transfer Level (RTL).
+Several academic and commercial tools are today available. The most common
+tools are SPARK~\cite{spark04}, GAUT~\cite{gaut08}, UGH~\cite{ugh08} in the
+academic world and CATAPULTC~\cite{catapult-c}, PICO~\cite{pico} and
+CYNTHETIZER~\cite{cynthetizer} in the commercial world. Despite their
+maturity, their usage is restrained by \cite{IEEEDT} \cite{CATRENE} \cite{HLSBOOK}:
+\begin{itemize}
+\item HLS tools are not integrated into an architecture and system exploration tool.
+Thus, a designer who needs to accelerate a software part of the system, must adapt it manually
+to the HLS input dialect and perform engineering work to exploit the synthesis result
+at the system level,
+\item Current HLS tools can not target control AND data oriented applications,
+\item HLS tools take into account mainly a unique constraint while realistic design
+is multi-constrained.
+Low power consumption constraint which is mandatory for embedded systems is not yet
+well handled or not handled at all by the HLS tools already available,
+\item The parallelism is extracted from initial specification.
+To get more parallelism or to reduce the amount of required memory in the SoC, the user
+must re-write the algorithmic specification while there is techniques such as polyedric
+transformations to increase the intrinsic parallelism,
+\item While they support limited loop transformations like loop unrolling and loop
+pipelining, current HLS tools do not provide support for design space exploration neither
+through automatic loop transformations nor through memory mapping,
+\item Despite having the same input language (C/C++), they are sensitive to the style in
+which the algorithm dis written. Consequently, engineering work is required to swap from
+a tool to another,
+\item They do not respect accurately the frequency constraint when they target an FPGA device.
+Their error is about 10 percent. This is annoying when the generated component is integrated
+in a SoC since it will slow down the whole system.
+\end{itemize}
+Regarding these limitations, it is necessary to create a new tool generation reducing the gap
+between the specification of an heterogeneous system and its hardware implementation \cite{HLSBOOK} \cite{IEEEDT}.
+
+\subsubsection{Application Specific Instruction Processors}
+
+ASIP (Application-Specific Instruction-Set Processor) are programmable
+processors in which both the instruction and the micro architecture have
+been tailored to a given application domain or to a
+specific application. This specialization usually offers a good compromise
+between performance (w.r.t a pure software implementation on an embedded
+CPU) and flexibility (w.r.t an application specific hardware co-processor).
+In spite of their obvious advantages, using/designing ASIPs remains a
+difficult task, since it involves designing both a micro-architecture and a
+compiler for this architecture. Besides, to our knowledge, there is still
+no available open-source design flow for ASIP design even if such a tool
+ would be valuable in the
+context of a System Level design exploration tool.
+\par
+In this context, ASIP design based on Instruction Set Extensions (ISEs) has
+received a lot of interest~\cite{NIOS2}, as it makes micro architecture synthesis
+more tractable \footnote{ISEs rely on a template micro-architecture in which
+only a small fraction of the architecture has to be specialized}, and help ASIP
+designers to focus on compilers, for which there are still many open
+problems\cite{ARC08}.
+This approach however has a severe weakness, since it also significantly reduces
+opportunities for achieving good speedups (most speedups remain between 1.5x and
+2.5x), since ISEs performance is generally tied down by I/O constraints as
+they generally rely on the main CPU register file to access data.
+
+% (
+%automaticcaly extraction ISE candidates for application code \cite{CODES04},
+%performing efficient instruction selection and/or storage resource (register)
+%allocation \cite{FPGA08}).
+To cope with this issue, recent approaches~\cite{DAC09,CODES08,TVLSI06} advocate the use of
+micro-architectural ISE models in which the coupling between the processor micro-architecture
+and the ISE component is tightened up so as to allow the ISE to overcome the register
+I/O limitations. However these approaches generally tackle the problem from a compiler/simulation
+point of view and do not address the problem of generating synthesizable representations for
+these models.
+
+We therefore strongly believe that there is a need for an open-framework which
+would allow researchers and system designers to :
+\begin{itemize}
+\item Explore the various level of interactions between the original CPU micro-architecture
+and its extension (for example through a Domain Specific Language targeted at micro-architecture
+specification and synthesis).
+\item Retarget the compiler instruction-selection pass
+(or prototype new passes) so as to be able to take advantage of this ISEs.
+\item Provide a complete System-level Integration for using ASIP as SoC building blocks
+(integration with application specific blocks, MPSoc, etc.)
+\end{itemize}
+
+\subsubsection{Automatic Parallelization}
+
+The problem of compiling sequential programs for parallel computers
+has been studied since the advent of the first parallel architectures
+in the 1970s. The basic approach consists in applying program transformations
+which exhibit or increase the potential parallelism, while guaranteeing
+the preservation of the program semantics. Most of these transformations
+just reorder the operations of the program; some of them modify its
+data structures. Dependences (exact or conservative) are checked to guarantee
+the legality of the transformation.
+
+This has lead to the invention of many loop transformations (loop fusion,
+loop splitting, loop skewing, loop interchange, loop unrolling, ...)
+which interact in a complicated way. More recently, it has been noticed
+that all of these are just changes of basis in the iteration domain of
+the program. This has lead to the introduction of the polyhedral model
+\cite{FP:96,DRV:2000}, in which the combination of two transformations is
+simply a matrix product.
+
+Since hardware is inherently parallel, finding parallelism in sequential
+programs in an important prerequisite for HLS. The large FPGA chips of
+today can accomodate much more parallelism than is available in basic blocks.
+The polyhedral model is the ideal tool for finding more parallelism in
+loops.
+
+As a side effect, it has been observed that the polyhedral model is a useful
+tool for many other optimization, like memory reduction and locality
+improvement. Another point is
+that the polyhedral domain \emph{stricto sensu} applies only to
+very regular programs. Its extension to more general programs is
+an active research subject.
+
+%\subsubsection{High Performance Computing}
+%Accelerating high-performance computing (HPC) applications with field-programmable
+%gate arrays (FPGAs) can potentially improve performance.
+%However, using FPGAs presents significant challenges~\cite{hpc06a}.
+%First, the operating frequency of an FPGA is low compared to a high-end microprocessor.
+%Second, based on Amdahl law, HPC/FPGA application performance is unusually sensitive
+%to the implementation quality~\cite{hpc06b}.
+%Finally, High-performance computing programmers are a highly sophisticated but scarce
+%resource. Such programmers are expected to readily use new technology but lack the time
+%to learn a completely new skill such as logic design~\cite{hpc07a} .
+%\\
+%HPC/FPGA hardware is only now emerging and in early commercial stages,
+%but these techniques have not yet caught up.
+%Thus, much effort is required to develop design tools that translate high level
+%language programs to FPGA configurations.
+
Index: /anr-2010/section-3.2.tex
===================================================================
--- /anr-2010/section-3.2.tex (revision 274)
+++ /anr-2010/section-3.2.tex (revision 274)
@@ -0,0 +1,96 @@
+% les objectifs scientifiques/techniques du projet.
+The design steps are presented figure~\ref{coach-flow}.
+\begin{figure}[hbtp]\leavevmode\center
+ \includegraphics[width=.8\linewidth]{flow}
+ \caption{\label{coach-flow} COACH design flow}
+\end{figure}
+\begin{description}
+\item[HPC setup:] During this step, the user splits the application into 2 parts: the host application
+which remains on the PC and the SoC application which is mapped on the FPGA.
+COACH will provide a complete simulation model of the whole system (PC+communication+FPGA-SoC)
+which will allow performance evaluation.
+\item[SoC design:] In this phase,
+COACH will allow the user to obtain virtual prototypes for the SoC at different abstraction levels.
+The user input will consist of a process network describing the coarse grain parallelism
+of the application, an instance of a generic hardware platform
+and a mapping of processes on the platform components.
+COACH will offer different targets to map the processes:
+software (the process runs as a software task on a SoC processor),
+ASIP (the process runs as a software task on a SoC processor enhanced with dedicated instructions),
+and hardware (the process is implemented as a synthesized hardware coprocessor).
+\item[Application compilation:] Once the SoC architecture is validated through performances
+analysis, COACH will generate automatically an executable containing the host application and
+the FPGA bitstream. This bitstream contains
+both the hardware architecture and the SoC application software.
+The user will be able to launch the application by
+loading the bitstream on an FPGA and running the executable on PC.
+\end{description}
+
+% l'avancee scientifique attendue. Preciser l'originalite et le caractere
+% ambitieux du projet.
+%FIXME == {NON ceci n'est pas une contribution scientifique. A re-ecrire}
+
+%The main scientific contribution of the project is to unify various synthesis techniques
+%(same input and output formats) allowing the user to swap without engineering effort
+%from one to another and even to chain them. For instance, it will be possible to run loop transformations before synthesis.
+%Another advantage of this framework is to provide different abstraction levels from
+%a single description.
+%Finally, this description is device family independent and its hardware implementation
+%is automatically generated.
+
+% Detailler les verrous scientifiques et techniques a lever par la realisation du projet.
+Hardware/Software co-design is a very complex task. To simplify it, COACH will address the
+following scientific and technological barriers:
+\begin{description}
+\item[\textit{Design Space Exploration by Virtual Prototyping}]:
+ The COACH environment will allow to easily map a parallel application (formally described as
+ an abstract network of process and communication channels)
+ COACH will permit the system designer to explore the design space, and to define the best
+ hardware/software partitioning of the application.
+\item[\textit{Integration of system level modeling and HLS tools}]:
+ COACH will support the automated generation of hardware accelerators when required
+ by using High-Level Synthesis (HLS) tools. These HLS tools will be
+ fully integrated into a complete system-level design environment.
+ Moreover, COACH will support both data and control dominated applications,
+ and the HLS tools of COACH will support a common language and coding style
+ to avoid re-engineering by the designer.
+ COACH will provide a tool which will automatically explore the micro-architectural
+ design space of coprocessor.
+\item[\textit{High-level code transformation}]:
+ COACH will allow to optimize the memory usage, to enhance the parallelism through
+ loop transformations and parallelization. The challenge is to identify the coarse
+ grained parallelism and to generate,
+ from a sequential algorithm, application containing multiple communicating
+ tasks. COACH will adapt techniques which were developed in the 1990 for
+ the construction of distributed programs. However, in the context of HLS, there are
+ several original problems to be solved, related to the FIFO communication channels and with
+ memory optimization.
+ COACH will support code transformation by providing a source to source C2C tool.
+\item[\textit{Unified Hardware/Software communication middleware}]:
+ COACH will rely on he SoCLib experience to implement an unified hardware/software communication
+ infrastructure and communication APIs (Application Programming Interface), to support
+ communications between software tasks running on embedded processors and dedicated
+ hardware coprocessors. The main issue here is to support easy migration
+ from a software implementation to an hardware implementation.
+\item[\textit{Processor customization}]:
+ ASIP (Application Specific Instruction Processor) design will be addressed by the COACH project.
+ COACH will allow system designers to explore the various level of interactions between
+ the original CPU micro-architecture and its extension. It will also allow to retarget
+ the compiler instruction-selection pass. Finally, COACH will integrate ASIP synthesis
+ in a complete System-level design framework.
+\end{description}
+
+%Presenter les resultats escomptes en proposant si possible des criteres de reussite
+%et d'evaluation adaptes au type de projet, permettant d'evaluer les resultats en
+%fin de projet.
+The main result is the framework. It is composed concretely of:
+a communication middleware for HPC,
+5 HAS tools (control dominated HLS, data dominated HLS, Coarse grained HLS,
+Memory optimisation HLS and ASIP),
+3 architectural templates that are synthesizable and that can be prototyped,
+one design space exploration tool,
+2 operating systems (DNA/OS and MUTEKH).
+\\
+The framework fonctionality will be demonstrated with the demonstrators
+(see task-7 page~\pageref{task-7}) and the tutorial example (see task-8
+page~\ref{subtask-tutorial}).
Index: /anr-2010/section-4.1.tex
===================================================================
--- /anr-2010/section-4.1.tex (revision 274)
+++ /anr-2010/section-4.1.tex (revision 274)
@@ -0,0 +1,133 @@
+\begin{figure}\leavevmode\center
+\includegraphics[width=.8\linewidth]{architecture-csg}
+\caption{\label{archi-csg} Software architecture for digital system generation}
+%\end{figure}\begin{figure}\leavevmode\center
+\mbox{}\vspace*{1ex}\\
+\includegraphics[width=1.0\linewidth]{architecture-hls}
+\caption{\label{archi-hls} Software architecture of hardware accellerator synthesis}
+%\end{figure}\begin{figure}\leavevmode\center
+\mbox{}\vspace*{1ex}\\
+\includegraphics[width=.8\linewidth]{architecture-hpc}
+\caption{\label{archi-hpc} Software architecture of HPC}
+\end{figure}
+%FIXME: la figure ne montre que l'aspect simulation. Intégrer la partie génération (PC API, PCIX, FPGA-IP, bridge vers VCI, SoC API) serait un plus, non ?
+%
+Figures~\ref{archi-csg}, \ref{archi-hls} and \ref{archi-hpc}
+summarize the software architecture of the COACH framework we will develop.
+In figures, the dotted boxes are the softwares or formats that COACH
+has to provide and to support.
+\parlf
+For the system generation presented in figure~\ref{archi-csg}, the conductor
+is the tool \verb!CSG! (COACH System Generator). Its inputs are a process
+network describing the target application and the synthesis parameters.
+The main parameters are the target hardware architectural template
+with its instantiation parameters, the hardware/software mapping of the
+tasks, the FPGA device and design constraints.
+\verb+CSG+ thus requires an architectural template library, an operating system
+library, two system hardware component (CPU, memories, BUS...) libraries
+(one for synthesis, one for simulation).
+For generating the coprocessor of a task mapped as hardware, \verb+CSG+
+controls the HAS tools described below.
+From these inputs \verb!CSG! can generate the entire system (both software and
+hardware) either as a SystemC simulator (cycla accurate and/or TLM) to prototype and explore quickly the
+design space or as a bitstream\footnote{COACH generates synthesizable VHDL, and
+launch the \xilinx or \altera RTL synthesis tools.} directly downloadable on the
+FPGA device\footnote{Additional partial bitstreams are generated in case of
+ dynamic partial reconfiguration}.
+\parlf
+The software architecture for HAS is presented in figure~\ref{archi-hls}.
+The input is a single task of the process network. The HAS tools do not work
+directly on the C++ task description but on an internal format called
+\xcoach generated by a plugin into the GNU C compiler (GCC).
+This will allow on the one hand to insure that all the tools will
+accept the same C++ description and on the other hand make possible
+their chaining. The front-end tools read a \xcoach description and generate
+a new \xcoach description that exibits more parallelism or implement
+specific instructions for ASIP. The back-end tools read an \xcoach
+description and generate an \xcoachplus description. This is an \xcoach
+description annotated with hardware information (scheduling, binding) required by
+the VHDL and systemC drivers.
+Furthermore, the back-end tools uses a macro-cell library (functional and memory
+unit).
+\parlf
+In addition to digital system design, HPC requires a supplementary
+partitioning step presented in figure~\ref{archi-hpc}. The designer
+splits the initial application (tag 1) in two parts: one still on the PC and the
+other running in a FPGA plugged on the PCI/X PC bus. The two parts exchange data
+through communication primitives (tag 2) implemented in a library.
+To evaluate the relevance of the partitioning, the designer can build a
+simulator. Once the partitioning is validated, the design of the FPGA part
+is done through \verb!CSG! (figure~\ref{archi-csg}).
+\parlf
+The project is split into 8 tasks numbered from 1 to 8. They are described
+in short below and in detail in section \ref{task-description}.
+\begin{description}
+\item[Task-1: \textit{Project management}]
+ This task relates to the monitoring of the COACH project.
+\item[Task-2: \textit{\Backbone}] This task tackles the fundamental points of the
+ project such as the defintion of the COACH inputs and outputs,
+ the internal formats (i.e. \xcoach and \xcoachplus) and their associated tools,
+ the architectural templates and the design flow.
+\item[Task-3: \textit{System generation}] This task addresses the prototyping and
+ the generation of digital system. Apart from HAS that belongs to task 3
+ and 4, its components are those presented figure~\ref{archi-csg}
+ (e.g. \verb!CSG!, operating systems).
+\item[Task-4: \textit{HAS front-end}] This task mainly focusses on four functionalities:
+ optimization of the memory usage, parallelism enhancement through loop
+ transformations, coarse grain parallelization and ASIP generation.
+\item[Task-5: \textit{HAS back-end}] This task groups two functionalities:
+ High-Level Synthesis of data dominated description and HLS of control
+ dominated description.
+ This task contains also the development of a frequency adaptator
+ that will allow the coprocessors to respect the processor and the bus
+ frequency.
+\item[Task-6: \textit{PC/FPGA communication middleware}]
+ This task pools the features dedicated to HPC. These are mainly the
+ validation of the partitioning (see figure~\ref{archi-hpc}), the sytem drivers for
+ both PC and FPGA-SoC sides, the hardware communication components and
+ the support for dynamic partial reconfiguration.
+\item[Task-7: \textit{Industrial demonstrators}]
+ This task groups the demonstrators of the COACH project.
+ Most of them are industrial applications that will be developped within
+ the COACH framework.
+ Others consist in integrating the COACH framework as a driver of
+ industrial proprietary design tools.
+\item[Task 8: \textit{Dissemination}]
+ This task concerns the diffusion of the project results.
+ It mainly consists of the production of 4 COACH releases (\verb!T0+12!, \verb!T0+18!,
+ \verb!T0+24! and \verb!T0+36!), the publication of a tutorial and user manuals on a WEB site, the publication
+ of research papers in international journals and conferences and the organization of workshops and tutorials in
+ international conferences.
+\end{description}
+%
+\begin{figure}\leavevmode\center
+%\includegraphics[width=.4\linewidth]{dependence-task}
+\includegraphics[width=0.70\linewidth]{dependence-task-h}
+\caption{\label{dependence-task}Task dependencies}
+\end{figure}
+Figure~\ref{dependence-task} presents the tasks dependencies.
+"$T_N \longrightarrow T_M$" means that $T_N$ impacts the $T_M$.
+The more bold the arrow, the more important is the impact.
+The graph shows:
+\begin{itemize}
+\item Even though $T4$ and $T5$ functionalities are complementary,
+their developments are independent (thanks to the \xcoach internal format).
+\item $T3$ slightly depends on $T4$ and $T5$. Indeed, $T3$ may work
+without $T4$ and $T5$ if targeted digital systems do not include hardware
+accelerators.
+\item $T3$ strongly impacts $T6$ but $T3$ does not depend at all on
+$T6$. Hence demonstrators ($T7$) of embedded system would not be impacted if
+$T6$ would fail.
+\item $T2$ drives all the tasks ($T3$, $T4$, $T5$, $T6$) and is at the heart of
+the COACH project.
+\item The demonstrators developped in $T7$, of course strongly depend on the achievements
+of the previous tasks ($T2$, $T3$, $T4$, $T5$, $T6$).
+\item $T8$ and $T1$ depend on and impact all the other tasks.
+\end{itemize}
+This organisation offers enough robustness to insure the success of the
+project except for the specification task $T2$.
+The only critical task in this chart is $T2$. \label{xcoach-problem}
+However, the partners met
+12 times (a one-day meeting per month) during the last year: 10 meetings to exchange and work on scientific
+and technical aspects and 2 meetings to prepare the project proposal. This gives us a high degree of confidence
+that $T2$ will be completed in time.
Index: /anr-2010/section-4.2.tex
===================================================================
--- /anr-2010/section-4.2.tex (revision 274)
+++ /anr-2010/section-4.2.tex (revision 274)
@@ -0,0 +1,67 @@
+\begin{description}
+\item[Project management structure]
+Each task is assigned to a Task Leader.
+The Task Leaders assist the project leader in the technical organization, effort
+management, of the co-operation and the reporting of the progress.
+A steering committee is composed by task leaders and the project leader.
+The steering committee has a monthly conference call and is in charge of conflict
+management if necessary.
+Each task leader has to report on the main high-lights, major
+opportunities and problems according to the work-plan.
+The redaction of the 6-month reports is the responsability of the steering committee.
+Therefore, each Partner has the responsibility to monthly inform the task Leaders of the
+current development of the \ST he has in charge.
+COACH will be organized in 8 tasks whose interactions are presented in
+Figure~\ref{dependence-task}.
+
+\item[Scientific and Technical Reports]
+For every yearly review, a written progress report for each deliverable has to be
+provided by the task leader to the coordinator for integration in the contractual reports.
+
+\item[Management of knowledge, Intellectual Property Right (IPR) and Results Exploitation]
+The partners will have to work under eventual NDA constraints.
+Prior Intellectual Property remains property of the concerned partners.
+The exploitation of the results obtained in the project and by each partner involved in the consortium will
+follow the rules written in the articles of the Consortium Agreement accepted and signed by
+each partner at most 6 months after the project kick-off.
+To manage the exploitation and dissemination plan within the project, six
+monthly meetings will analyze the intentions from the consortium (patent, publication...).
+
+\item[Management Tools]
+In order to permit a good management, before the kick-off meeting,
+each partner will have to identify (name, address, phone, fax and e-mail):
+\begin{itemize}
+ \item the financial and administrative contact person,
+ \item the scientific and technical contact person,
+ \item all participants to the project.
+\end{itemize}
+A complete and detailed list will be communicated to each partner and to
+the public Authority. The partners will construct mailing lists for
+day-to-day communication.
+
+The first task will be the redaction of a Consortium Agreement,
+dealing mainly with all aspects of the relations
+between partners, including legal aspects, property rights and further
+exploitation of the results. This document will be submitted to the
+partner's financial and legal departments, and will define the management
+rules (decision level, reporting systems, red flag cases).
+A first draft of this document will be submitted to each partner
+during the kick-off meeting.
+
+\item[Project follow-ups]
+The basic communication between single project partners will be carried out by means of an Information System (web site), which will be developed and introduced at the very beginning of the project implementation.
+All scientific and administrative data related to the project will be collected and
+treated within a specific e-management plate-form accessible directly by the project web
+site by an individual login and pass-word.
+The web site will have a few levels of accessibility starting with completely free access,
+open to broad public up to internal materials available only for members of the consortium
+for the e-management area.
+This communication tools will permit to perform all the reports and to follow as well as
+possible all the tasks.
+
+\item[Project monitoring]
+For this project format and size, a 12 months review by ANR, based on a yearly progress
+report incorporating milestones reports and deliverables, seems optimum.
+The internal consortium meetings will be every six months, including a kick-off meeting at the
+start of the project, in our eyes the most important of all, as it phases the partners for the start of the project.
+\end{description}
Index: /anr-2010/section-4.4.tex
===================================================================
--- /anr-2010/section-4.4.tex (revision 274)
+++ /anr-2010/section-4.4.tex (revision 274)
@@ -0,0 +1,107 @@
+\definecolor{gtcBoxHeavy}{rgb}{0.10,0.10,0.90}
+\definecolor{gtcBoxLight}{rgb}{0.9,0.90,0.99}
+\definecolor{gtcTaskBG0} {rgb}{0.99,0.90,0.7}
+\definecolor{gtcTaskBG1} {rgb}{0.90,0.99,0.7}
+\definecolor{gtcMilestone}{rgb}{0.9,0.4,0.4}
+\immediate\write\ganttdata{ML=6 ML=12 ML=18 ML=24}
+\def\ganttlabelstyle#1{\begin{small}#1\end{small}}
+\def\gantttitlestyle#1{\begin{scriptsize}\textit{#1}\end{scriptsize}}
+
+%\begin{figure}\leavevmode\center
+%\hspace*{-.6cm}
+%\input{gantt.tex}
+%\caption{\label{gantt}Gantt diagram of deliverables}
+%\end{figure}
+
+\begin{figure}\leavevmode\center
+\hspace*{-.4cm}%\vspace{-1.5cm}
+\input{gantt1.tex}
+\caption{\label{gantt1}Gantt diagram of deliverables (task-1 to task-4 and task-8)}
+\end{figure}
+
+\begin{figure}\leavevmode\center
+\hspace*{-.4cm}%\vspace{-1.5cm}
+\input{gantt2.tex}
+\caption{\label{gantt2}Gantt diagram of deliverables (task-5, task-6 and task-7)}
+\end{figure}
+
+The figures~\ref{gantt1}~\&~\ref{gantt2} present the Gantt diagram of the project.
+Before the final release (T0+36), there are 4 milestones (red lines on the figures) at
+$T0+6$, $T0+12$, $T0+18$ and $T0+24$ that are rendez-vous points of the precedent
+deliverables.
+\begin{description}
+\item[Milestone 1 ($T0+6$)] Specification of COACH inputs, of the \xcoach format and of
+ the demonstatrors as a reference software.
+\item[Milestone 2 ($T0+12$)] The first COACH release. At this step the demonstrators are
+ written in the COACH input format. This COACH release allows to prototype and to generate the FPGA-SoC.
+ The main restrictions are:
+ 1) Only the neutral architectural template is supported,
+ 2) HAS is not available (but prototyping with virtual coprocessors is available),
+ 3) Enhanced communication schemes are not available.
+ 4) ASIP compilation flow is not available.
+\item[Milestone 3 ($T0+18$)] The second COACH release. At this step most of the COACH
+ features are availables. A preliminary version of the ASIP synthesis flow is supported, for a
+ simple extensible MIPS model. The main restriction is that COACH can not yet
+ generate FPGA-SoC for \altera and \xilinx architectural templates.
+ The others restriction is that the HAS tools are not yet fully operational.
+\item[Milestone 4 ($T0+24$)] The pre-release of the COACH project. The full design flow is
+ supported.
+ The main restriction are:
+ 1) The backend HAS tools have not been yet enhanced,
+ 2) Dynamic partial reconfiguration is not supported,
+ 3) NIOS processor instruction set extension is supported, but only for user specified patterns.
+\item[Final Release ($T0+36$)]
+
+\end{description}
+This organisation allows the project to globally progress step by step mixing development
+and demonstrator deliverables.
+Hence, demonstrator feed-back will arrive early and so the risk to point out incompatibility
+at the integration phase is significantly reduced.
+\par
+The risks that have been identified at the beginning of the project are the following:
+\begin{description}
+\item[\xcoach format (\novers{\specXcoachDoc}, \novers{\specXcoachToCA})]
+ Partners have to agree on a convenient exchange format for all tools involved.
+ Because all the HAS tools rely on it, the \xcoach format specification is a
+ crucial step. There are no work-around but as mentionned in
+ section~\ref{xcoach-problem} (page~\pageref{xcoach-problem}) the five academic partners have worked on it
+ for a full year and a preliminary document already exists.
+%\item[\xcoachplus format (\novers{\specXcoachDoc},
+% \novers{\specXcoachToSystemC}, \novers{\specXcoachToVhdl})]
+% Its aim is the generation of the coprocessors (hardware \& prototyping model).
+% By centralizing the coprocessor generation, it guarantees their functioning
+% independently of the used HAS tools.
+% Our experience with UGH and GAUT give us confidence in the succes of this
+% task.
+\item[Virtual prototyping of \altera \& \xilinx architectural templates ({\csgAlteraSystemC},
+ {\csgXilinxSystemC})]
+ The SoCLib component library contains several SystemC models used for the virtual
+ prototyping of the \altera and \xilinx architectural templates (NIOS and Microblaze processor cores).
+ Nevertheless, at this time we do not know how many IP cores SystemC simulation models have to be developped.
+ If the workload of this simulation model development is too important, virtual prototyping
+ of those architectural templates will not be directly supported.
+ The three architectural templates being quite similar, the virtual
+ prototyping will use the neutral architectural template.
+\item[VCI/AVALON \& VCI/PLB bridges (\novers{\hpcAvalonBridge}, \novers{\hpcPlbBridge})]
+ If one of these tasks is impossible or too important or leads to inefficiency,
+ it will be abandoned.
+ In this case, the neutral architectural template will not be available for HPC and
+ a SystemC VCI model corresponding to the PCI/X IP will be developped to allow
+ virtual prototyping.
+\end{description}
+\parlf
+Finally the list of all the deliverables is presented on figure~\ref{all-delivrables}.
+\begin{figure}\leavevmode\center
+{
+\fontsize{7pt}{9pt}\selectfont
+\settowidth\desclen{XILINX RTL optimisation (5)}
+\def\Sformat#1{\textsc{#1}}
+%\hspace*{-2.5mm}
+\begin{minipage}{1.0\linewidth}
+\input{table_livrable_01.tex}
+\hfill\hspace*{1mm}\hfill
+\input{table_livrable_02.tex}
+\end{minipage}
+}
+\caption{\label{all-delivrables}All the deliverables}
+\end{figure}
Index: /anr-2010/section-5.tex
===================================================================
--- /anr-2010/section-5.tex (revision 274)
+++ /anr-2010/section-5.tex (revision 274)
@@ -0,0 +1,152 @@
+\subsection{Dissemination}
+
+The COACH project will bring new scientific results in various fields, such as high level synthesis,
+hardware/software codesign, virtual prototyping, hardware oriented compilation techniques,
+automatic parallelisation, etc. These results will be published in relevant International
+Conferences, namely DATE, DAC, or ICCAD.
+
+More generally, the COACH infrastructure and the design flow supported by the COACH
+tools and libraries will be promoted by proposing tutorials on FPGA oriented system level synthesis
+in various worshops and conferences (DATE, DAC, CODES+ISSS...).
+
+Several COACH partners being members of the HiPEAC European Network of Excellence
+(High Performance and Embedded Architecture and Compilation), courses will be proposed for the
+HiPEAC summer school on Advanced Computer Architecture and Compilation for Embedded Systems.
+
+Following the general policy of the SoCLib platform, the COACH project will be an
+open infrastructure, and the COACH tools and libraries will be available in the framework
+of the SoCLib WEB server. This server will be maintened by the UPMC/LIP6 laboratory.
+
+\subsection{Exploitation of results}
+
+The main goal of the COACH project is to help SMEs (Small and Medium Enterprises)
+to enter the world of MPSoC technologies. For small companies, the cost is a primary concern.
+Moreover, these companies have not always in-home expertise in hardware design and VHDL modelling.
+As the fabrication costs of an ASIC is generally too high for SMEs, the COACH project focus
+on FPGA technologies. Regarding the design tools, the cost of advanced ESL (Electronic System Design)
+tools is an issue, and the COACH project will follow the same general policy as the SoCLib platform :
+
+\begin{itemize}
+\item
+All software tools supporting the COACH design flow will be available as free software.
+All academic partners contributing to the COACH project agreed to distribute the ESL software
+tools under the same GPL license as the SoCLib tools.
+\item
+The SystemC simulation models for the hardware components
+used by the SoCLib architectural template will be distributed as free software
+under a non-contaminant LGPL license.
+\item
+The synthesizable VHDL models supporting the neutral architectural template
+(corresponding to the SocLib IP cores library), will have two modes of dissemination.
+A typical MPSoC contains not only dedicated, synthesized coprocessors. It contains
+also general purpose, reusable components, such as processor cores, memory controllers
+optimised cache controllers, peripheral controllers, or bus controllers.
+For non commercial use (i.e. research or education in an academic context,
+or feasbility study in an industrial context), the synthesizable VHDL models will be freely available.
+For commercial use, commercial licenses will be negociated between the owners and the customers.
+\item
+The proprietary \altera, \xilinx and \zied IP core libraries are commercial products
+that are not involved by the free software policy, but these libraries will be supported by the
+synthesis tools developped in the COACH project.
+\end{itemize}
+
+This general approach is supported by a large number (\letterOfInterestNb) of SMEs, as
+demonstrated by the "letters of interest" that have been collected during the preparation
+of the project and presented in annexe~\ref{lettre-soutien}.
+
+\subsection{Indusrial Interest in COACH}
+
+\subsubsection*{Partner: \textit{\bull}}
+The team of \bull participating to the COACH project is from the Server Development
+Department who is in charge of developing hardware for open servers (e.g. NovaScale) and
+HPC solutions. The main expectation from COACH is to derive a new component (fine-grain
+FPGA parallelism) to add to existing Bull HPC solutions.
+
+\subsubsection*{Partner: \textit{\xilinx}}
+Computing power potential of our FPGA architectures
+growing very quickly on one side, and complexity of designs implemented
+using our FPGAs dramatically increasing on the other side, it is very
+interesting for us to get high level design methodologies progressing
+quickly and targetting our FPGAs in the most possible efficient way.
+\parlf
+\xilinx goal is to get COACH to generate bitstream optimized as much as possible for
+\xilinx FPGAs in order to both, validate the methodology on our FPGA families, and ease
+future work of our customers.
+
+\subsubsection*{Partner: \textit{\thales}}
+\noindent
+\thales has two main reasons to use the COACH platform:
+\begin{itemize}
+ \item The huge increase of the complexity of the systems in particular by their
+ heterogeneity, raises the issues of design cost and time in the same proportion. The
+ divisions need a design tool which supports the implementation of the applications from
+ algorithm description to the executable code on platforms composed of several general
+ purpose processors and dedicated IPs.
+ \item The applications are more and more complex and adaptable to the environment which
+ leads to a mixture of control aspects and data stream computing aspects. A new approach
+ is necessary to be able to describe this type of application and manage the high level
+ synthesis of system embedding control and data flow aspects.
+\end{itemize}
+\parlf
+TRT (Thales Research and Technology) has the mission to assess and de-risk the emerging
+technologies in its domains of expertise. Specifically in COACH, the studied technology is
+a method and associated tools to make the bridge between application capture at system
+level and the implementation on heterogeneous distributed computing architectures. The
+main stake for Thales behind this is the future design process that will be applied to its
+system teams in the future for the computation-intensive sensor applications. In a context
+of very instable market of tools for parallel programming, it is important to experiment
+and demonstrate the candidate technologies.
+\\
+In its role of internal dissemination, TRT will make the demonstration of the full design
+flow within Thales, and will keep available a platform to later evaluate additional
+applications coming from the Business Units.
+\\
+The COACH platform will be used in the new \thales products in which the algorithms are more
+and more dependent of the environment and have to permanently adapt their behavior in
+varying environments. The target markets are the critical infrastructures security and
+border monitoring.
+
+\subsubsection*{Partner: \textit{\zied}}
+
+\zied is developing a new architecture for embedded system. Our interest in using COACH
+are:
+\begin{itemize}
+ \item firstly, to validate our new architecture by emulating it with COACH.
+ \item Secondly, to use this emulator and the COACH potential to quickly setup
+ demonstrator to our customer.
+\end{itemize}
+
+\subsubsection*{Partner: \textit{\navtel}}
+\navtel has a platform for high performence computation based on ARM processor and FPGAs
+that embedde coprocessors. Currently, the coprocessors are handmade and their designs
+constitute an important part of our product cost. We have try free HLS tools to diminish
+them but the quality of the generated designs was not sufficient to be useable.
+So our interest in COACH is mainly the HLS tools.
+
+\subsubsection*{Industrial supports}
+The following SMEs demonstrate interest to the COACH project (see the "letters of
+interest" in annexe~\ref{lettre-soutien}) and will follow the COACH evolution and will
+evaluate it:
+\letterOfInterest{ALTERA Corporation}{lettres/Altera1.pdf},
+\letterOfInterestPlus{lettres/Altera2.pdf}
+\letterOfInterest{ADACSYS}{lettres/Coach_ADACSYS_lettre_interet},
+\letterOfInterest{MAGILLEM Design Services}{lettres/Coach_lettre_interet_MDS},
+\letterOfInterest{INPIXAL}{lettres/inpixal.jpg},
+\letterOfInterest{CAMKA System}{lettres/CAMKA-System.pdf},
+\letterOfInterest{ATEME}{lettres/ATEME.pdf},
+\letterOfInterest{ALSIM Simulateur}{lettres/Alsim.pdf},
+\letterOfInterest{SILICOMP-AQL}{lettres/itlabs.pdf},
+\letterOfInterest{ABOUND Logic}{lettres/abound.pdf},
+\letterOfInterest{EADS-ASTRIUM}{lettres/Astrium1.pdf}.
+\letterOfInterestPlus{lettres/Astrium2.pdf}
+
+\letterOfInterestClose
+
+\subsection{Management of Intellectual Property}
+A global consortium agreement will be defined during the first six monts of the project.
+As already stated, the COACH project has been prepared during one year by a monthly meeting
+involving the five academic partners. The general free software policy described in the
+previous section has been agreed by academic partners and has been
+approved by all industrial participants. This free software policy will
+simplify the definition of the consortium agreement.
+
Index: /anr-2010/section-6.1.tex
===================================================================
--- /anr-2010/section-6.1.tex (revision 274)
+++ /anr-2010/section-6.1.tex (revision 274)
@@ -0,0 +1,298 @@
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsubsection{\inria/CAIRN}
+
+INRIA, the French national institute for research in computer science
+and control, operating under the dual authority of the Ministry of
+Research and the Ministry of Industry, is dedicated to fundamental and
+applied research in information and communication science and
+technology (ICST). The Institute also plays a major role in technology
+transfer by fostering training through research, diffusion of
+scientific and technical information, development, as well as
+providing expert advice and participating in international programs.
+\parlf
+By playing a leading role in the scientific community in the field and
+being in close contact with industry, INRIA is a major participant in
+the development of ICST in France. Throughout its eight research
+centres in Rocquencourt, Rennes, Sophia Antipolis, Grenoble, Nancy,
+Bordeaux, Lille and Saclay, INRIA has a workforce of 3 800, 2 800 of
+whom are scientists from INRIA and INRIA's partner organizations such
+as CNRS (the French National Center for Scientific Research),
+universities and leading engineering schools. They work in 168 joint
+research project-teams. Many INRIA researchers are also professors and
+approximately 1 000 doctoral students work on theses as part of INRIA
+research project-teams.
+%\parlf
+%INRIA develops many partnerships with industry and fosters technology
+%transfer and company foundation in the field of ICST - some ninety
+%companies have been founded with the support of INRIA-Transfert, a
+%subsidiary of INRIA, specialized in guiding, evaluating, qualifying,
+%and financing innovative high-tech IT start-up companies. INRIA is
+%involved in standardization committees such as the IETF, ISO and the
+%W3C of which INRIA was the European host from 1995 to 2002.
+%\parlf
+%INRIA maintains important international relations and exchanges. In
+%Europe, INRIA is a member of ERCIM which brings together research
+%institutes from 19 European countries. INRIA is a partner in about 120
+%FP6 actions and 40 FP7 actions, mainly in the ICST field. INRIA also
+%collaborates with numerous scientific and academic institutions abroad
+%(joint laboratories such as LIAMA, associated research teams, training
+%and internship programs).
+
+The CAIRN group of INRIA Rennes -- Bretagne Atlantique study reconfigurable
+system-on-chip, i.e. hardware systems whose configuration may change before or even during
+execution. To this end, CAIRN has 13 permanent researchers and a variable number of PhD
+students, post-docs and engineers.
+CAIRN intends to approach reconfigurable architectures from three
+angles: the invention of new reconfigurable platforms, the development
+of associated transformation, compilation and synthesis tools, and the
+exploration of the interaction between algorithms and architectures.
+CAIRN is a joint team with CNRS, University of Rennes 1 and ENS Cachan.
+
+\subsubsection{\lip/Compsys}
+The Compsys group of Ecole Normale Sup\'erieure de Lyon is a project-team
+of INRIA Rh\^one-Alpes and a part of Laboratoire de l'Informatique du
+Parall\'elisme (LIP), UMR 5668 of CNRS. It has four permanent researchers
+and a variable number of PhD students and post-docs. Its field of
+expertise is compilation for embedded system, optimizing compilers
+and automatic parallelization. Its members were among the initiators
+of the polyhedral model for automatic parallelization and program
+optimization generally. It has authored or contributed to
+several well known libraries for linear programming, polyhedra manipulation
+and optimization in general. It has strong industrial cooperations, notably
+with ST Microelectronics and \thales.
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsubsection{\tima}
+The TIMA laboratory ("Techniques of Informatics and Microelectronics
+for integrated systems Architecture") is a public research laboratory
+sponsored by Centre National de la Recherche Scientifique (CNRS, UMR5159),
+Grenoble Institute of Technology (Grenoble-INP) and Universit\'{e} Joseph Fourier
+(UJF).
+The research topics cover the specification, design, verification, test,
+CAD tools and design methods for integrated systems, from analog and
+digital components on one end of the spectrum, to multiprocessor
+Systems-on-Chip together with their basic operating system on the other end.
+\parlf
+Currently, the lab employs 124 persons among which 60 PhD candidates, and runs
+32 ongoing French/European funded projects.
+Since its creation in 1984, TIMA funded 7 startups, patented 36 inventions
+and had 243 PhD thesis defended.
+\parlf
+The System Level Synthesis Group (25 people including PhDs) is
+involved in several FP6, FP7, CATRENE and ANR projects.
+Its field of expertise is in CAD and architecture for Multiprocessor
+SoC and Hardware/Software interface.
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsubsection{\ubs}
+
+The Lab-STICC (Laboratoire des Sciences et Techniques de l'Information,
+de la Communication, et de la Connaissance), is a French CNRS laboratory
+(UMR 3192) that groups 4 research centers in the west and south
+Brittany: the Universit\'e de Bretagne-Sud (UBS), the Universit\'e de
+Bretagne Occidentale (UBO), and Telecom Bretagne (ENSTB).
+The Lab-STICC is composed of three departments: Microwave and equipments (MOM),
+Digital communications, Architectures and circuits (CACS) and Knowledge,
+information and decision (CID). The Lab-STICC represents a staff of 279
+peoples, including 115 researchers and 113 PhD students.
+The scientific production during the last 4 years represents 20
+books, 200 journal publications, 500 conference publications, 22
+patents, 69 PhDs diploma.
+\parlf
+The UBS/Lab-STICC laboratory is involved in several national research
+projects (e.g. RNTL : SystemC'Mantic, EPICURE - RNRT : MILPAT, ALIPTA,
+A3S - ANR : MoPCoM, SoCLib, Famous, RaaR, AFANA, Open-PEOPLE, ICTER ...),
+CMCU project (COSIP) and regional projects (e.g. ITR projects PALMYRE
+...). It is also involved in European Project (e.g. ITEA/SPICES,
+IST/AETHER ...). These projects are conducted through tight cooperation
+with national and international companies and organizations (e.g. France
+Telecom CNET, MATRA, CEA, ASTRIUM, \thales Com., \thales Avionics, AIRBUS,
+BarCo, STMicroelectronics, Alcatel-Lucent ...). Results of those or former
+projects are for example the high-level synthesis tool GAUT, the UHLS
+syntax and semantics-oriented editor, the DSP power estimation tool
+Soft-explorer or the co-design framework Design Trotter.
+\parlf
+The CACS department of the Lab-STICC (also referred as UBS/Lab-STICC),
+located in Lorient, is involved in COACH.
+The UBS/Lab-STICC is working on the design of complex electronic systems
+and circuits, especially but not exclusively focussing on real-time
+embedded systems, power and energy consumption optimization, high-level
+synthesis and IP design, digital communications, hardware/software
+co-design and ESL methodologies. The application targeted by the
+UBS/Lab-STICC are mainly from telecommunication and multimedia domains
+which enclose signal, image, video, vision, and communication processing.
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsubsection{\upmc}
+
+University Pierre et Marie Curie (UPMC) is the largest university in France (7400
+employees,38000 students).
+The Laboratoire d'Informatique de Paris 6 (LIP6) is the computer science laboratory of
+UPMC, hosting more than 400 researchers, under the umbrella of the CNRS (Centre National
+de la Recherche Scientifique).
+The \og System on Chip \fg Department of LIP6 consists of 80 people, including 40 PHD
+students.
+The research focuses on CAD tools and methods for VLSI and System on Chip design.
+\\
+The annual budget is about 3 M{\texteuro}, and 1.5 M{\texteuro} are from research contracts.
+The SoC department has been involved in several european projects :IDPS, EVEREST, OMI-HIC,
+OMI-MACRAME, OMI-ARCHES, EUROPRO, COSY, Medea SMT, Medea MESA, Medea+ BDREAMS, Medea+
+TSAR.
+\parlf
+The public domain VLSI CAD system ALLIANCE, developped at UPMC is installed in more than
+200 universities worldwide.
+The LIP6 is in charge of the technical coordination of the SoCLib national project, and is
+hosting the SoCLib WEB server.
+The SoCLib DSX component was designed and developped in our laboratory.
+It allows design space exploration and will the base of the $CSG$ COACH tools.
+Moreover, the LIP6 developped during the last 10 years the UGH tool for high level
+synthesis of control-dominated coprocessors.
+This tool will be modified to be integrated in the COACH design flow.
+\parlf
+Even if the preferred dissemination policy for the COACH design flow will be the free
+software policy, (following the SoCLib model), the SoC department is ready to support
+start-ups : Six startup companies (including \zied) have been created by former
+researchers from the SoC department of LIP6 between 1997 and 2002.
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsubsection{\xilinx}
+
+\xilinx is the world leader in the domain of programmable logic circuits (FPGA).
+\xilinx develops on one hand several FPGA architectures (CoolRunner, Spartan and Virtex
+families) and on the other hand a software solution allowing exploiting the
+characteristics of these FPGA.
+\parlf
+The tools proposed allow the designer to describe his architecture from a modeling
+language (VHDL/Verilog) to an optimized architecture implemented to the selected
+technology.
+The team located at Grenoble is responsible of the logic synthesis tool development (XST)
+of the software solution, which aggregates all the steps allowing proceeding from a HDL
+model to a technological netlist:
+\begin{itemize}
+ \item Compilation of HDL code and model generation at Register Transfer Level (RTL).
+ \item RTL model optimizations.
+ \item Inference and generation of optimized macro blocks (Finite states machine, counter).
+ \item Boolean equations generation for random logic.
+ \item Logical, mapping and timing optimizations.
+\end{itemize}
+\parlf
+The architectures developed by \xilinx offer a collection of technological primitives
+(variable complexity) from simple Boolean generators (LUT) to complex DSP blocks or memory
+and even configurable processor cores (Pico and MicroBlaze families).
+This kind of architecture allows, therefore, the designer to validate different
+hardware/software possibilities in a High Level Synthesis (HLS) framework.
+\parlf
+The classical optimization techniques focus, mainly, on the frequency aspects and on
+available resources use.
+The optimizations, taking into account the consumption criteria, become critical due to
+the fact of the increase of the architecture complexity and due to the use of FPGA
+component for low power applications.
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsubsection{\bull}
+
+\bull designs and develops servers and software for an open environment, integrating the
+most advanced technologies. It brings to its customers its expertise and know-how to help
+them in the transformation of their information systems and to optimize their IT
+infrastructure and their applications.
+\parlf
+\bull is particularly present in the public sector, banking, finance, telecommunication
+and industry sectors. Capitalizing on its wide experience, the Group has a thorough
+understanding of the business and specific processes of these sectors, thus enabling it to
+efficiently advise and to accompany its customers. Its distribution network spreads to
+over 100 countries worldwide.
+\parlf
+The team participating to the COACH project is from the Server Development Department
+based in Les Clayes-sous-Bois, France. The SD Department is in charge of developing
+hardware for open servers (e.g. NovaScale) and HPC solutions. Its main activities range
+from architecture specification, ASIC design/verification/prototyping to board design and
+include also specific EDA development to complement standard tools.
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsubsection{\thales}
+
+\thales is a world leader for mission critical information systems, with activities in 3
+core businesses: aerospace (with all major aircraft manufacturers as customers), defence,
+and security (including ground transportation solutions). It employs 68000 people
+worldwide, and is present in 50 countries. \thales Research \& Technology operates at the
+corporate level as the technical community network architect, in charge of developing
+upstream and \thales-wide R \& T activities, with vision and visibility. In support of
+\thales applications, TRT's mission is also to anticipate and speed up technology transfer
+from research to development in Divisions by developing collaborations in R\&T. \thales is
+international, but Europe-centered. Research \& Development activities are disseminated,
+and corporate Research and Technology is concentrated in Centres in France, the United
+Kingdom and the Netherlands. A key mission of our R\&T centres is to have a bi-directional
+transfer, or "impedance matching" function between the scientific research network and the
+corresponding businesses. The TRT's Information Science and Technology Group is able to
+develop innovative solutions along the information chain exploiting sensors data, through
+expertise in: computational architectures in embedded systems, typically suitable for
+autonomous system environments, mathematics and technologies for decision involving
+information fusion and cognitive processing, and cooperative technologies including man
+system interaction.
+\parlf
+The Embedded System Laboratory (ESL) of TRT involved in the COACH project is part of the
+Information Science and Technology Group. Like other labs of TRT, ESL is in charge of
+making the link between the needs from \thales business units and the emerging
+technologies, in particular through assessment and de-risking studies. It has a long
+experience on parallel architectures design, in particular on SIMD architectures used for
+image processing and signal processing applications and on reconfigurable architectures.
+ESL is also strongly involved in studies on programming tools for these types of
+architectures and has developed the SpearDE tool used in this project. The laboratory had
+coordinated the FP6 IST MORPHEUS project on reconfigurable technology, being highly
+involved in the associated programming toolset. The team is also involved in the FP6 IST
+FET AETHER project on self-adaptability technologies and coordinates national projects on
+MPSoC architecture and tools like the Ter\verb+@+ops project (P\^{o}le de
+Comp\'{e}titivit\'{e} System\verb+@+tic) dedicated to the design of a MPSoC for intensive
+computing embedded systems.
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsubsection{\zied}
+
+\zied is an innovative start-up specialized in the conception of configurable circuits
+and the development of CAD tools. \zied provides a complete front-to-back-end generator
+of "hardware" reprogrammable IP cores that can be embedded in ASIC and ASSP SoC designs.
+\zied solution is based on a patented FPGA architecture delivering an unprecedented
+level of logic density. This high capacity is accessible using a traditional RTL flow from
+Verilog/VHDL synthesis all the way to bitstream generation.
+\parlf
+\zied is a spin-off from LIP6 (Laboratoire Informatique Paris 6) and was awarded at the
+French National Competition for Business Startup and Innovative Technology in 2007 and
+2009 in "emergence" and "creation" categories respectively.
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsubsection{\navtel}
+
+\navtel was created in 1994 to develop flexible systems based on FPGAs and currently
+focuses on intelligent signal mining for knowlege based signal processing systems.
+The company main activity covers the following domains: satellite communication,
+aeronautics, imaging and security.
+\navtel dedicates about 70\% of its activity to client projects in satellite, aeronautical
+and imaging systems and 30\% to its own research programmes in collaboration with French
+and international partners.
+\parlf
+The multi disciplinary technical team comprises 6 engineers for signal processing and
+hardware development and one technician.
+\parlf
+\navtel has its own Ph.D program which includes in the past (classification technology
+and MIMO for FPGA implementation) and currently the preparation of a project for remote
+sensing with signal intelligence for satellite application. The company participates in
+national and European level projects contributing to a strategic alliance between academic
+and industrial partners.\\
+The current research covers particle filter applications for communication and RADAR,
+Cognitive Radio, Satellite communication, embedded super computing and focuses on low
+power algorithms for implementation in FPGA and soft computing.
+\parlf
+For manufacturing and industrialization, \navtel works with ISO certified partners.
+The company clients include the CNES, Thal\`{e}s Alenia Space, Thal\`{e}s Communication, EADS,
+Eutelsat, AIRBUS, Schlumberger. \navtel participates from the R\&D phase up to the
+system delivery.
+\begin{description}
+\item[Recognitions:]\mbox{}
+\begin{itemize}
+ \item HEC Challenge+ program for innovative projects (promotion 9)
+ \item Innovation and technology development \og Troph\'{e}es R\'{e}gion Centre \fg
+ \item Recognition by the French Senate for company creation during the
+ \og Semaine de l'entrepreneur \fg 2005.
+\end{itemize}
+\end{description}
Index: /anr-2010/section-6.2.tex
===================================================================
--- /anr-2010/section-6.2.tex (revision 274)
+++ /anr-2010/section-6.2.tex (revision 274)
@@ -0,0 +1,32 @@
+The Coach project will be coordinated by the Professor Alain Greiner from
+Université Pierre et Marie Curie.
+Alain Greiner is the initiator and the main architect of the SoCLib project.
+This ANR plat-form for virtual prototyping of MPSoCs involved 6 industrial companies
+(including ST Microelectronics and Thales) and ten academic laboratories
+(5 of them are involved in the Coach project).
+The SoCLib project was managed by Thales, but the technical coordination has been done
+by Alain Greiner, that has a good experience in coordinating large technical projects
+in both industrial and academic contexts:
+
+\begin {itemize}
+\item
+He received the "Docteur es Sciences" degree from University Denis DIDEROT
+in 1982 after working six years at Commissariat a l' Energie Atomique.
+\item
+From 1986 to 1990, he worked for the french BULL company, as team leader,
+in charge of designing the Basic Processing Unit for the BULL
+DPS7000 computer, the most powerfull mainframe from the family.
+\item
+In 1990, Alain Greiner joined UPMC, as Professor and became the head of the
+MASI laboratory in 1994.
+\item
+From 1990 to 2000, he was the leader of the the ALLIANCE project: This GPL based
+cooperative project developped a public domain VLSI/CAD system that has been used
+in more than 200 universities worlwide, for education and research.
+This project obtained the Seymour Cray award in 1994.
+\item
+From 2000 to 2009, he was the head of the Hardware Department
+of the LIP6 laboratory, and associate-director of the LIP6 laboratory.
+\end {itemize}
+
+
Index: /anr-2010/section-7.tex
===================================================================
--- /anr-2010/section-7.tex (revision 274)
+++ /anr-2010/section-7.tex (revision 274)
@@ -0,0 +1,309 @@
+\def\resstablestyletitle#1{\begin{small}{\textit{#1}}\end{small}}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsection{Partner 1: \irisa}
+
+\begin{description}
+\item [Equipment]
+ No specific equipment acquisition.
+\item [Personnel costs] The faculty members involved in the project
+ are François Charot (INRIA researcher), Steven Derrien (associate
+ professor), Christophe Wolinski (professor) and Charles Wagner
+ (research engineer). The non-permanent personal required is a PhD
+ student that will mainly work on ASIP generation. We are looking for
+ a profile with strong informatic skills and good knowledge in
+ computer architecture.
+ \parlf
+ The table below summarizes the manpower in \hommemois by tasks for both permanent and
+ non-permanent personnels. The detail by deliverables is given in
+ figure~\ref{table-livrables-1}.
+ The non-permanent personnels costs represent {48\%} of the personnal
+ costs. The requested funding for non permanent personnels is 100\% of
+ the total ANR requested funding.
+ \begin{center}\input{table_inria_cairn_short.tex}\end{center}
+\item [Subcontracting]
+ No subcontracting costs.
+\item [Travel]
+ The travel costs are associated to project meeting as well as participation to
+ conferences. The travel costs are estimated to {7,5\%} of the total
+ requested ANR funding.
+\item [Expenses for inward billing]
+ The costs justified by internal invoicing procedures are evaluated to 4\% of the total
+ requested ANR funding.
+\end{description}
+
+
+\subsection{Partner 2: \lip}
+
+\begin{description}
+\item [Equipment]
+ No specific equipment acquisition. The costs for depreciation of
+ workstations is evaluated to 4\% of the total requested ANR funding.
+\item [Personnel costs]
+ The faculty members involved in the project are an emeritus
+ professor at ENS Lyon (Paul Feautrier) and a research associate
+ (CR2) at INRIA Rh\^one-Alpes (Christophe Alias). The non-permanent
+ personel required is a PhD student that will work on network process
+ generation from polyhedral loops, then on extensions to
+ non-polyhedral loops. We are looking for a student with both
+ theoretical and practical skills, that will be able to get a
+ sufficient understanding of the polyhedral techniques and to produce
+ a working implementation.
+ \parlf
+ The table below summarizes the \hommemois by
+ deliverables and tasks for both permanent and non-permanent
+ personnels. The non-permanent personnels costs represent 26\% of
+ the personnal costs. The requested funding for non
+ permanent personnels is 100\% of the total ANR requested funding.
+ \begin{center}\input{table_inria_compsys_full.tex}\end{center}
+\item [Subcontracting]
+ No subcontracting costs.
+\item [Travel]
+ The travel costs are associated to project meeting as well as
+ participation to conferences. The travel costs are estimated to 20\%
+ of the total requested ANR funding.
+\item [Expenses for inward billing]
+ The costs justified by internal invoicing procedures are evaluated
+ to 4\% of the total requested ANR funding.
+\end{description}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsection{Partner 3: \tima}
+
+\begin{description}
+\item [Equipment]
+ No specific equipment acquisition.
+\item [Personnel costs]
+ The permanent personnels involved in the project are professor and assistant professor
+ (Fr\'ed\'eric P\'etrot and Olivier Muller).
+ The non permanent personnels are Phd students and post-doc researchers.
+ Related costs are estimated in \hommemois.
+ One phd student (Adrien Prost-Boucle), funded by the french ministry of research, will
+ be working on the project.
+ One 100\% funded phd student will be hired in september 2010. A post-doc researcher will
+ be hired at the end of 2011 for one year and an half.
+ The PhD student will mainly work on the evolution of UGH HLS tool. Thus, we are looking
+ for a profile with strong informatic skills and good knowledge in computer architecture.
+ The post-doc will mainly work on dynamic reconfiguration and HPC. The required profile
+ will be more oriented on computer architecture and advanced digital design.
+ \parlf
+ The table below sumarizes the man power in \hommemois by tasks for both permanent and
+ non-permanent personnels. The detail by deliverables is given in
+ figure~\ref{table-livrables-1}.
+ The requested funding for personnels represent 50\% of the total personnal costs.
+ The requested funding for non permanent personnels is 85\% of the total ANR requested
+ funding.
+ \begin{center}\input{table_tima_short.tex}\end{center}
+\item [Subcontracting]
+ No subcontracting costs.
+\item [Travel]
+ The travel costs are associated to project meeting as well as participation to
+ conferences. The travel costs are estimated to 11\% of the total requested ANR funding.
+\item [Expenses for inward billing]
+ The costs justified by internal invoicing procedures are evaluated to 4\% of the total
+ requested ANR funding.
+\end{description}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsection{Partner 4: \ubs}
+
+\begin {description}
+\item [Equipment]
+ In order to validate the design flow project, the Lab-STICC laboratory will buy FPGA
+ developpement boards. The cost for these FPGA boards is estimated to 3\% of the total
+ ANR funding.
+\item [Personnel costs]
+ The faculty members involved in the project are associate professors (Philippe COUSSY,
+ Cyrille CHAVET) or research engineers (Dominique HELLER). All non-permanent personnel
+ costs are estimated in \hommemois for senior researchers (post-doc or research
+ engineers).
+ \parlf
+ The table below sumarizes the man power in \hommemois by tasks for both permanent and
+ non-permanent personnels. The detail by deliverables is given in
+ figure~\ref{table-livrables-2}.
+ The non-permanent personnels costs represent 50\% of the personnal costs.
+ The requested funding for non permanent personnels is about 83\% of the total ANR
+ requested funding.
+ \begin{center}\input{table_ubs_short.tex}\end{center}
+\item [Subcontracting]
+ No subcontracting costs.
+\item [Travel]
+ The travel costs are associated to management and meeting as well as participation to
+ conferences. The travel costs are estimated to 10\% of the total requested ANR funding.
+\item [Expenses for inward billing]
+ The costs justified by internal invoicing procedures are evaluated to 4\% of the total
+ requested ANR funding.
+\end {description}
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsection{Partner 5: \upmc}
+
+\begin{description}
+\item[Equipment]
+ No specific equipment acquisition is required for this project.
+ The costs for depreciation of workstations and pre-existing FPGA boards are evaluated
+ to 7\% of the total requested ANR funding.
+\item[Personnel costs]
+ The permanent personnels involved in the project are professors or assistant
+ processors (Alain Greiner and Ivan Aug\'e).
+ All non permanent personnel costs are estimated in \hommemois for senior researchers
+ (post-doc or research engineers).
+ The table below sumarizes the man power by tasks in \hommemois for both permanent and
+ non-permanent personnels.
+ The detail by deliverables is given in figure~\ref{table-livrables-2}.
+ The non-permanent personnels costs represent 50\% of the personnal costs.
+ The requested funding for non permanent personnels is 79\% of the total ANR
+ requested funding.
+ \begin{center}\input{table_upmc_short.tex}\end{center}
+\item[Subcontracting]
+ No subcontracting costs.
+\item[Travel]
+ The travel costs are associated to management and coordination meeting as
+ well as participation to conferences. The travel costs are estimated
+ to 10\% of the total requested ANR funding.
+\item[Expenses for inward billing]
+ The costs justified by internal invoicing procedures are evaluated to 4\%
+ of the total requested ANR funding.
+\end{description}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsection{Partner 6: \xilinx}
+
+\begin{description}
+\item[Equipment]
+ No specific equipment acquisition is required for this project.
+\item[Personnel costs]
+ \xilinx employees involved in the project are permanent Software Engineers.
+ The man power detail in \hommemois by deliverables is given in
+ figure~\ref{table-livrables-1} and a sumary by task in the following table.
+ \begin{center}\input{table_xilinx_short.tex}\end{center}
+\item[Subcontracting]
+ No subcontracting costs.
+\item[Travel]
+ The travel costs are associated to project meeting as well as participation to
+ conferences. The travel costs are estimated to 2\% of the total requested ANR funding.
+\item[Expenses for inward billing] none
+\item[Other working costs] none
+\end{description}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsection{Partner 7: \bull}
+
+\begin{description}
+\item[Equipment]
+ Acquisition of a FPGA development board will represent the main equipment cost for
+ Bull in COACH. It is estimated at about 5\% (tbc) of the total funding.
+\item[Personnel costs]
+ A permanent engineer will be assigned full time to the project for a duration of 20
+ months as shown in the table below that gives the man power in \hommemois:
+ \begin{center}\input{table_bull_full.tex}\end{center}
+\item[Subcontracting]
+ No subcontracting costs.
+\item[Travel]
+ Application of a standard 10\% of the total funding to travel costs.
+\item[Expenses for inward billing]
+ Costs justified by inward billing are estimated to about 5\% of the total funding.
+\item[Other working costs] none
+\end{description}
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsection{Partner 8: \thales}
+
+\begin{description}
+\item[Equipment]
+ In order to validate the design flow,TRT will buy FPGA developpement boards. The cost
+ for these FPGA boards is estimated to 10 k\euro (6\% of the total ANR funding).
+\item[Personnel costs]
+ The effort to adapt SPEAR DE to generate the input files to COACH framework is
+ estimated to 13 \hommemois.
+ The effort to describe and develop the application is estimated to 14 \hommemois.
+ Finally we need one \hommemois for the partiticipation to the global specification in task 2.
+ This is sumarized in the table below:
+ \begin{center}\input{table_thales_full.tex}\end{center}
+\item[Subcontracting]
+ No subcontracting costs.
+\item[Travel]
+ The travel costs are associated to meeting, plenaries as well as participation to
+ conferences. The travel costs are estimated to 10 k\euro. The travel costs are estimated to
+ 5\% of the total requested ANR funding.
+\item[Expenses for inward billing] none
+\item[Other working costs] none
+\end{description}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsection{Partner 9: \zied}
+
+\begin{description}
+\item[Equipment]
+ No equipement costs.
+\item[Personnel costs]
+ The effort to define SoC architecture and adapt eFPGA interface to generate is
+ estimated to 9.6 \hommemois.
+ The effort to develop demonstrator and to extract eFPGA timining characteristics is
+ estimated to 4.8 \hommemois.
+ Finally we need one 3.6 man.month for the evaluation of the FLEXRAS solution.
+ The table below summarizes the these manpower costs in \hommemois for the deliverables
+ and by tasks.
+ \begin{center}\input{table_zied_full.tex}\end{center}
+\item[Subcontracting]
+ No subcontracting costs.
+\item[Travel]
+ No travel costs.
+\item[Expenses for inward billing] none
+\item[Other working costs] none
+\end{description}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsection{Partner 10: \navtel}
+
+\begin{description}
+\item[Equipment]
+ Navtel will use FPGA board with ARM processors for the validation.
+ The costs for depreciation of the board and the instrument of test
+ are evaluated to 7\% of the total requested ANR funding.
+\item[Personnel costs]
+ A permanent engineer will be assigned on average 1/3 time for
+ all the duration of the project.
+ The table below shows the estimated manpower cost in \hommemois for the deliverables
+ and by tasks.
+ \begin{center}\input{table_navtel_full.tex}\end{center}
+\item[Subcontracting]
+ No subcontracting costs.
+\item[Travel]
+ The travel costs are associated to meeting, plenaries as well as participation to
+ conferences. The travel costs are estimated to 3 k\euro.
+\item[Expenses for inward billing] none
+\item[Other working costs] none
+\end{description}
+%
+\begin{landscape}
+\begin{figure}
+\begin{small}
+\settowidth\desclen{XILINX RTL optimisation (5)}
+\def\resstablestyletitle#1{\parbox{\desclen}{\textit{#1}}}
+\begin{minipage}[b]{.47\linewidth}\center
+\input{table_inria_cairn_full.tex}\vspace{.5ex}\\ \irisa \vspace{2.5ex}\\
+\input{table_xilinx_full.tex}\vspace{.5ex}\\ \xilinx\\
+\end{minipage}\hfill\begin{minipage}[b]{.47\linewidth}\center
+\input{table_tima_full.tex}\vspace{.5ex} \\ \tima
+\end{minipage}
+\end{small}
+\caption{\label{table-livrables-1} Man power in \hommemois for the deliverables (1)}
+\end{figure}
+%
+\begin{figure}
+\begin{small}
+\settowidth\desclen{XILINX RTL optimisation (5)}
+\def\resstablestyletitle#1{\parbox{\desclen}{\textit{#1}}}
+\begin{minipage}[b]{.47\linewidth}\center
+\input{table_ubs_full.tex}\vspace{.5ex}\\ \ubs \vspace{2.5ex}\\
+%\input{table_thales_full.tex}\vspace{.5ex}\\ \thales \\
+\end{minipage}\hfill\begin{minipage}[b]{.47\linewidth}\center
+\input{table_upmc_full.tex}\vspace{.5ex} \\ \upmc
+\end{minipage}
+\end{small}
+\caption{\label{table-livrables-2} Man power in \hommemois for the deliverables (2)}
+\end{figure}
+\end{landscape}
Index: /anr-2010/table_lip_full.tex.sav
===================================================================
--- /anr-2010/table_lip_full.tex.sav (revision 274)
+++ /anr-2010/table_lip_full.tex.sav (revision 274)
@@ -0,0 +1,11 @@
+\begin{tabular}{|c|p{3.5cm}||r|r|r||r|}\hline
+number & \multicolumn{1}{c||}{title} & \multicolumn{3}{c||}{years } & total \\\cline{3-5}
+ & & \multicolumn{1}{c|}{1} & \multicolumn{1}{c|}{2} & \multicolumn{1}{c||}{3} & \\\hline\hline
+D230 & \resstablestyletitle{Specification of {\tt xcoach} format} & 7.0 & 3.0 & 0.0 & 10.0 \\\hline
+ & total Task-2 & 7.0 & 3.0 & 0.0 & 10.0 \\\hline
+\hline D430 & \resstablestyletitle{Process generation method} & 5.0 & 0.0 & 5.0 & 10.0 \\\hline
+D431 & \resstablestyletitle{Process and FIFO construction} & 20.0 & 20.0 & 20.0 & 60.0 \\\hline
+ & total Task-4 & 25.0 & 20.0 & 25.0 & 70.0\\\hline
+\hline
+ & total & 32.0 & 23.0 & 25.0 & 80.0 \\\hline
+\end{tabular}
Index: /anr-2010/table_lip_short.tex.sav
===================================================================
--- /anr-2010/table_lip_short.tex.sav (revision 274)
+++ /anr-2010/table_lip_short.tex.sav (revision 274)
@@ -0,0 +1,8 @@
+\begin{center}\begin{small}\begin{tabular}{|c|l||r|r|r||r|}\hline
+ & title & \multicolumn{3}{c||}{years } & total \\\cline{3-5}
+ & & \multicolumn{1}{c|}{1} & \multicolumn{1}{c|}{2} & \multicolumn{1}{c||}{3} & \\\hline\hline
+Task-2 & Backbone infrastructure & 7.0 & 3.0 & 0.0 & 10.0 \\\hline
+Task-4 & HAS front-end & 25.0 & 20.0 & 25.0 & 70.0 \\\hline
+\hline
+ & total & 32.0 & 23.0 & 25.0 & 80.0 \\\hline
+\end{tabular}\end{small}\end{center}
Index: /anr-2010/task-0.tex
===================================================================
--- /anr-2010/task-0.tex (revision 274)
+++ /anr-2010/task-0.tex (revision 274)
@@ -0,0 +1,57 @@
+\begin{taskinfo}
+\let\UPMC\leader
+\let\ALL\enable
+\end{taskinfo}
+%
+\begin{objectif}
+This task relates to the monitoring of the COACH project. Its main objectives are:
+\begin{itemize}
+\item To ensure the appropriate progress of the project,
+\item To coordinate the scientific and technical cooperation between the partners,
+\item To manage and monitor the scientific and technical work and progress in the tasks,
+\item To verify the conformance to agreed budget and time scales,
+\item To prepare periodic progress reports in order to control the overall progress of the
+ project,
+\item To organize the project meetings,
+\item To set up a shared development infrastructure as a version control system and
+ development WEB site.
+\end{itemize}
+\end{objectif}
+%
+\begin{workpackage}
+ \subtask This \ST consists in writing and ratifying the consortium agreement.
+ \begin{livrable}
+ \CoutHorsD{0}{36}{\Subs}{project management}{1:1:1}
+ \itemL{0}{6}{d}{\Supmc}{Consortium agreement}{1:0:0}
+ A document describing the consortium agreement, signed by all the partners.
+ \end{livrable}
+ \subtask This \ST concerns the global management of the deliverables and of the global
+ organization of the project at all the levels.
+ \begin{livrable}
+ \itemL{0}{36}{d}{\Supmc}{Global management}{1:1:1}
+ Global management of the project at all the
+ levels: progress monitoring, record keeping, meeting organization, review
+ organization, the writing of the review reports.
+ \end{livrable}
+ \subtask This \ST consists in managing the project at the partner level.
+ It includes mainly the progress monitoring, the record keeping the participation to the
+ project meetings and the communication with the project leader and the other partners.
+ \begin{livrable}
+ \itemL{0}{36}{}{\Supmc}{\upmc management}{1:1:1} Project management at the partner level.
+ \CoutHorsD{0}{36}{\Stima}{project management}{1:1:1}
+ \end{livrable}
+ \subtask This \ST consists firstly in the building, and next in the administration and the
+ maintenance of the development and dissemination infrastructure. It is also in charge of
+ the COACH releases distribution.
+ \begin{livrable}
+ \itemV{0}{6}{x}{\Supmc}{Infrastructure development setup}
+ Setup of the development infrastructure
+ (version control system configuration, wiki).
+ \itemL{7}{36}{x}{\Supmc}{Infrastructure development}{1:.5:.5}
+ Standard management of a development
+ infrastructure (adding \& suppressing account, retrieving forgotten passwords,
+ creation and closing development branch, ...)
+ \CoutHorsD{0}{36}{\Slip}{project management}{1:1:1}
+ \end{livrable}
+\end{workpackage}
+%
Index: /anr-2010/task-1.tex
===================================================================
--- /anr-2010/task-1.tex (revision 274)
+++ /anr-2010/task-1.tex (revision 274)
@@ -0,0 +1,141 @@
+\begin{taskinfo}
+\let\UPMC\leader
+\let\ALL\enable
+\end{taskinfo}
+%
+\begin{objectif}
+This task deals with the main features of digital systems.
+Its objectives are the specification of the designer input, the
+definition of the hardware architectural templates and of all the features
+that the HAS tools will share.
+\end{objectif}
+%
+\begin{workpackage}
+\subtask This \ST specifies the COACH environment for the system designer. At this
+ level the COACH framework is a black box. The deliverables are documents
+ specifying: how to feed COACH (the inputs), how to use COACH (the design flow),
+ what is generated (the outputs).
+ %(definition of the generic architecture of the
+ %MPSoC and its 3 targets hardware mapping).
+ \begin{livrable}
+ \CoutHorsD{0}{12}{\Sbull}{User specification}{3:0:0}
+ \itemV{0}{6}{d}{\Supmc}{COACH specification} \setMacroInAuxFile{specGenManualI}
+ The first version of the COACH specification.
+ This document contains the general description of the framework, the design flow and the
+ description of the architectural templates.
+ It refers to the HAS specification (deliverable {\specHasManual}) and
+ to the CSG specifcation (deliverable \specCsgManual) for the COACH input
+ descriptions.
+ \itemL{6}{12}{d}{\Supmc}{COACH specification}{1:0:0} \setMacroInAuxFile{specGenManual}
+ The final version of the {\specGenManualI} deliverable updated with the first
+ feed-backs of the demonstrator \STs.
+ \itemV{0}{6}{d}{\Stima}{CSG specification} \setMacroInAuxFile{specCsgManualI}
+ The first version of the CSG (COACH System Generator) specification.
+ It specifies how the task graph is described, the communication schemes and its
+ associated API (Application Programming Interface).
+ The base is the SRL library and the MWMR communication component defined by the SocLib
+ ANR project.
+ Nevertheless, these basic schemes will be enhanced to allow more efficient
+ synthesis.
+ \itemL{6}{12}{d}{\Stima}{CSG specification}{1:0:0} \setMacroInAuxFile{specCsgManual}
+ The final version of the {\specGenManualI} deliverable updated with the first
+ feed-backs of the demonstrator \STs.
+ \itemV{0}{6}{d}{\Subs}{HAS specification} \setMacroInAuxFile{specHasManualI}
+ The first version of the HAS (Hardware Accelerator Synthesis) specification.
+ It specifies how tasks must be written (C/C++ subset) and how
+ communication schemes defined in the {\specCsgManual} deliverable must be described for
+ coprocessor synthesis.
+ \itemL{6}{12}{d}{\Subs}{HAS specification}{2:0:0} \setMacroInAuxFile{specHasManual}
+ The final version of the {\specGenManualI} deliverable updated with the first
+ feed-backs of the demonstrator \STs.
+ \end{livrable}
+\subtask This \ST specifies the software COACH structure. The deliverable is a
+ document listing all the COACH software components and how they cooperate.
+ \begin{livrable}
+ \CoutHorsD{0}{12}{\Sthales}{User specification}{1:0:0}
+ \itemL{0}{6}{d}{\Supmc}{COACH internal \ganttlf software architecture}{1:0:0}
+ Description of the software list and the data flow among the tools.
+ \end{livrable}
+\subtask This \ST specifies the \xcoach and the \xcoachplus formats.
+ \begin{livrable}
+ \itemV{0}{6}{d+x}{\Slip}{\xcoach format specification}
+ \setMacroInAuxFile{specXcoachDocI}
+ First release of the XML specification of the \xcoach format (DTD)
+ and its associated documentation allowing to start HLS tools development.
+ \itemV{6}{12}{d+x}{\Slip}{\xcoach format specification}
+ \setMacroInAuxFile{specXcoachDocII}
+ Second release of XML specification of the \xcoach format
+ taking into account the corrections and modifications that the
+ developers of HAS tools suggested.
+ \itemL{12}{18}{d+x}{\Slip}{\xcoach format specification}{7:3:0}
+ \setMacroInAuxFile{specXcoachDoc}
+ Last release of XML specification of the \xcoach format enhanced with
+ the expression of loop potential parallelism.
+ \itemV{6}{12}{x}{\Subs}{First release of C2X}
+ \setMacroInAuxFile{specXcoachToCAI}
+ A GCC plugin C2X that generates a \xcoach description
+ (defined in {\specXcoachDocI} deliverable) from a C/C++ task description
+ (defined in {\specHasManual} deliverable).
+ \itemL{12}{18}{x}{\Subs}{C2X tool}{2:1:0}
+ \setMacroInAuxFile{specXcoachToCA}
+ An updated version of C2X (\specXcoachToCAI) which supports the \xcoach format defined
+ in the {\specXcoachDoc} deliverable and the HAS input format defined in the {\specHasManual}
+ deliverable.
+ \itemV{7}{12}{x}{\Subs}{First release of X2C}
+ \setMacroInAuxFile{specXcoachToCBI}
+ This second tool X2C regenerates a C description from a \xcoach
+ description.
+ \itemL{12}{18}{x}{\Subs}{X2C tool}{2:1:0}
+ \setMacroInAuxFile{specXcoachToCB}
+ The same software as the former (\specXcoachToCBI) but for the \xcoach format as defined
+ in the {\specXcoachDoc} deliverable and HAS input as defined in the {\specHasManual}
+ deliverable.
+ \itemV{12}{18}{x}{\Supmc}{First release of X2SC}
+ \setMacroInAuxFile{specXcoachToSystemCI}
+ The first release of the software tool X2SC that translates \xcoachplus description to CABA
+ and TLM-DT SystemC module.
+ \itemL{18}{24}{x}{\Supmc}{X2SC tool}{0:2:0}
+ \setMacroInAuxFile{specXcoachToSystemC}
+ Final release of the former software (\specXcoachToSystemCI).
+ \itemV{12}{18}{x}{\Subs}{First release of the X2VHDL}
+ \setMacroInAuxFile{specXcoachToVhdlI}
+ The first release of the software tool X2VHDL that translates \xcoachplus description to
+ synthesizable VHDL description.
+ \itemL{18}{24}{x}{\Subs}{X2VHDL tool}{0:3:0}
+ \setMacroInAuxFile{specXcoachToVhdl}
+ Final release of the former software (\specXcoachToVhdlI) and integration
+ of enhancements proposed in \novers{\specXilinxOptimization} deliverable.
+ \itemL{18}{21}{d}{\Sxilinx}{\xilinx RTL optimisation (1)}{0:3:0}
+ \setMacroInAuxFile{specXilinxOptimization}
+ This deliverable consists in optimizing the VHDL generated from \xcoachplus format
+ (deliverable \novers{\specXcoachToVhdl}) for the \xilinx RTL synthesis tools.
+ \ubs will provide several examples of VHDL source files generated from \xcoachplus,
+ with explanations about generation process of main data structures used in VHDL sources,
+ \xilinx will provide back a documentation listing that proposes VHDL generation enhancements.
+ \end{livrable}
+
+\subtask This \ST aims to define a tool in order to pilot the GCC/xcoach compiler.
+ \begin{livrable}
+ \itemL{0}{3}{d}{\Subs}{GCC driver specification}{1:0:0}
+ Specification of the GCC driver tool.
+ \itemV{3}{9}{x}{\Subs}{GCC driver}
+ First release of the GCC driver tool.
+ %en T0+18 car va peut etre evoluer en fonction du DSE µ-archi
+ \itemL{9}{12}{x}{\Subs}{GCC driver}{3:0:0}
+ Final release of the GCC driver tool.
+ \end{livrable}
+
+\subtask Backend HLS tools use a characterized macro-cell library to build the
+ micro-architecture of a coprocessor. The characterisation of a cell depends
+ on the target device. The role of this \ST is to define the macro-cells and
+ to provite a tool that characterizes them automatically by synthesizing them
+ and by extracting their delays. This is done by using RTL synthesis.
+ \begin{livrable}
+ \itemL{0}{6}{d}{\Subs}{Macro-cell definition}{1:0:0}
+ \setMacroInAuxFile{specMacroCell}
+ Definition of the macro cells and the file format describing them.
+ \itemL{6}{12}{x}{\Subs}{Macro-cell library generator}{2:0:0}
+ Final release of the software tool that generates automatically the characterized macro-cell library
+ for a FPGA device.
+ \end{livrable}
+\end{workpackage}
Index: /anr-2010/task-2.tex
===================================================================
--- /anr-2010/task-2.tex (revision 274)
+++ /anr-2010/task-2.tex (revision 274)
@@ -0,0 +1,125 @@
+\begin{taskinfo}
+\let\UPMC\leader
+\let\IRISA\enable
+\let\TIMA\enable
+\let\XILINX\enable
+\let\UBS\enable
+\end{taskinfo}
+%
+\begin{objectif}
+This task deals with the prototyping and the generation of FPGA-SoC digital systems.
+Its is described on figure~\ref{archi-csg}.
+Its objective is to allow the system designer to explore the design space by
+quickly prototyping and then to automatically generate the FPGA-SoC systems.
+This task consists of
+\begin{itemize}
+\item The development of all the missing components (SytemC models and/or synthesizable VHDL models
+of the IP-cores),
+\item The configuration and the development of drivers of the operating systems (Board Support Package, HAL),
+\item The CSG software that generates the SystemC simulators for prototyping and the FPGA-SoC system
+including its bitstream and software executable code,
+\item The specification of enhanced communication schemes and their sofware and hardware implementations.
+\end{itemize}
+This task being based on the SoCLib platform, a first release will be delivered at $T0+12$
+to allow the demonstrators to start working.
+This release will include the standard communication schemes (based on SoCLib MWMR component)
+and support the neutral architectural template for prototyping and hardware generation.
+\end{objectif}
+%
+\begin{workpackage}
+\subtask This \ST corresponds to the COACH System Generator (CSG) software.
+ \begin{livrable}
+ \itemV{0}{12}{x}{\Supmc}{CSG tool} \setMacroInAuxFile{csgCoachArch}
+ The first software release of the CSG tool that will allow demonstrators to start
+ working by using the neutral architectural template.
+ \itemV{12}{18}{x}{\Supmc}{CSG} \setMacroInAuxFile{csgPrototypingOnly}
+ The second release of CSG supports the \xilinx and \altera architectural
+ templates and the enhanced communication system, but only for SystemC prototyping.
+ This release integrates a first integration of HLS tools.
+ \itemV{18}{24}{x}{\Supmc}{CSG} \setMacroInAuxFile{csgAllArch}
+ This milestone extends CSG (\csgPrototypingOnly) to
+ FPGA-SoC generation for the \xilinx and \altera architectural template.
+ \itemL{24}{36}{x}{\Supmc}{CSG tool}{6:5.5:5.5}
+ Final release of CSG.
+ \end{livrable}
+\subtask This \ST deals with the components of the architectural templates.
+ \\
+ For the neutral architectural template, it consists of the development of the VHDL
+ synthesizable description of the missing communication components (MWMR)
+ in order to support the process network communication model.
+ Notice that the SystemC models
+ comes from the SocLib ANR project, the processor with its cache comes from the TSAR
+ ANR project.
+ \\
+ For the \xilinx and \altera architectural templates, we use the \xilinx and \altera IPs (NIOS, Microblaze, memories, busses...).
+ \begin{livrable}
+ \itemL{0}{12}{h}{\Supmc}{Neutral architecture}{1:0:0}
+ \setMacroInAuxFile{csgCoachArchTempl}
+ The VHDL synthesizable descriptions of the SocLib MWMR, TokenRing components.
+ \itemL{12}{15}{d}{\Sxilinx}{\xilinx RTL optimisation (2)}{0:2:0}
+ This deliverable consists in optimizing the VHDL descriptions of the components of
+ the neutral architectural template (deliverable \novers{\csgCoachArchTempl}) to the
+ \xilinx RTL synthesis tools.
+ \upmc will provide the VHDL descriptions, \xilinx will provide back a documentation
+ listing that proposes VHDL generation enhancements.
+ \itemV{6}{18}{x}{\Stima}{\xilinx architecture}
+ \setMacroInAuxFile{csgXilinxSystemC}
+ The SystemC simulation module of the MWMR component with a PLB bus interface plus
+ the SystemC modules of the components of the \xilinx architectural template
+ currently not available in the SocLib component library.
+ \itemL{18}{24}{h}{\Stima}{\xilinx architecture}{9:9:0}
+ The synthesizable VHDL description of the MWMR component corresponding to the
+ SystemC module of the former deliverable (\csgXilinxSystemC).
+ \itemL{24}{27}{d}{\Sxilinx}{\xilinx RTL optimisation (3)}{0:0:1.5}
+ This deliverable consists in optimizing the MWMR VHDL description (deliverable
+ \novers{\csgXilinxSystemC}) of the \xilinx architectural template.
+ \tima will provide MWMR VHDL description, \xilinx will provide back a documentation
+ listing that proposes VHDL generation enhancements.
+ \itemV{6}{18}{x}{\Sirisa}{\altera architecture}
+ \setMacroInAuxFile{csgAlteraSystemC}
+ The SystemC simulation module of the MWMR component with an AVALON bus interface plus
+ the SystemC modules of the components of the \altera architectural template
+ currently not available in the SocLib component library.
+ \itemL{18}{24}{h}{\Sirisa}{\altera architecture}{6:6:0}
+ The synthesizable VHDL description of the MWMR component corresponding to the
+ SystemC module of the former deliverable (\csgAlteraSystemC);
+ \itemL{6}{12}{d}{\Subs}{Communication adapter spec.}{1:0:0}
+ \setMacroInAuxFile{gautCOMMoptimization}
+ Specification of an optimized communication adapter (space and time) component to handle data interleaving.
+ This evolution aims to solve out of order communication weakness of the classical MWMR.
+ \itemV{12}{24}{x}{\Subs}{Communication adapter}{0:6:0}
+ First release of the tool that generates the VHDL description of the optimized communication adapter
+ and its corresponding SystemC module.
+ \itemL{24}{30}{x}{\Subs}{Comm. adapter generator}{0:6:3}
+ Final release of the tool that generates the VHDL description of the optimized
+ communication adapter and its corresponding SystemC module (\gautCOMMoptimization).
+ \itemL{24}{27}{d}{\Sxilinx}{\xilinx RTL optimisation (4)}{0:0:1.5}
+ This deliverable consists in optimizing the communication adapter VHDL description (deliverable
+ \novers{\gautCOMMoptimization}).
+ \ubs will provide communication adapter VHDL description, \xilinx will provide back a documentation
+ listing that proposes VHDL generation enhancements.
+ \end{livrable}
+\subtask This \ST consists of the configuration of the SocLib MUTEKH and DNA operating
+ system and the development of drivers for the hardware architectural templates
+ and enhanced communication schemes defined in \novers{\specCsgManual} deliverable.
+ For the \altera and \xilinx architectural templates, the OSs must also be ported on
+ the NIOS2 and MICROBLAZE processors.
+ \begin{livrable}
+ \itemV{6}{8}{x}{\Supmc}{MUTEKH OS}
+ The drivers required for the first CSG milestone (deliverable \csgCoachArch).
+ \itemV{8}{18}{x}{\Supmc}{MUTEKH 0S drivers}
+ The drivers required for the second CSG milestone ({\csgPrototypingOnly}).
+ \itemL{18}{33}{x}{\Supmc}{MUTEKH OS drivers}{1:1:2}
+ Final release of the MUTEKH OS drivers.
+ \itemL{6}{18}{x}{\Supmc}{Porting of MUTEKH OS}{1.0:1:0}
+ Porting of MUTEKH OS on the NIOS2 and MICROBLAZE processors.
+ \itemV{6}{8}{x}{\Stima}{DNA OS}
+ The drivers required for the first CSG milestone (deliverable \csgCoachArch).
+ \itemV{8}{18}{x}{\Stima}{DNA 0S}
+ The drivers required for the second CSG milestone ({\csgPrototypingOnly}).
+ \itemL{18}{33}{x}{\Stima}{DNA OS drivers}{6:3:2}
+ Final release of the DNA OS drivers.
+ \itemL{6}{18}{x}{\Stima}{Porting of DNA OS}{3:1:0}
+ Porting of DNA OS on the NIOS2 and MICROBLAZE processors.
+ \end{livrable}
+\end{workpackage}
Index: /anr-2010/task-3.tex
===================================================================
--- /anr-2010/task-3.tex (revision 274)
+++ /anr-2010/task-3.tex (revision 274)
@@ -0,0 +1,84 @@
+\begin{taskinfo}
+\let\LIP\leader
+\let\IRISA\enable
+\let\UBS\enable
+\let\UPMC\enable
+\let\TIMA\enable
+\end{taskinfo}
+%
+\begin{objectif}
+The objective of this task is to convert the input specification of
+an hardware accelerator, which must be written in a familiar language
+(C/C++) with as few constraints as possible, into a form suitable for
+the HLS tools (i.e. HAS back-end tools of the COACH project). If the
+target is an ASIP, the frontend has to extract
+patterns from the source code and convert them into the definition
+of an extensible processor. If the target is a process network, the
+front end has to distribute the workload and the data sets as fairly
+as possible, identify communication channels, and output an \xcoach
+description.
+\end{objectif}
+%
+\begin{workpackage}
+ \subtask This sub-task aims at providing compiler support for custom instructions
+ within the HAS front-end. It will take as input the COACH intermediate
+ representation, and will output an annotated COACH IR containing the custom
+ instructions definitions along with their occurrence in the application.
+ \begin{livrable}
+ \itemV{0}{18}{x}{\Sirisa}{ASIP compilation flow}
+ In this first version of the software, the computations patterns corresponding to
+ custom instructions are specified by the user, and then automatically extracted (when
+ beneficial) from the application intermediate representation.
+ \itemL{18}{24}{x}{\Sirisa}{ASIP compilation flow}{6:9:0}
+ In this second version, the software will also be able to automatically identify
+ interesting pattern candidates in the application code, and use them as custom
+ instructions.
+ \end{livrable}
+
+ \subtask In this sub-task, we provide micro-architectural template models for the two target
+ processor architectures (NIOS-II and MIPS) supported within the COACH-ASIP design flow.
+ For each processor, we provide a simulation model (System-C) and a synthesizable model (VHDL)
+ of the architecture, along with its architectural extensions
+ \begin{livrable}
+ \itemV{0}{12}{x}{\Sirisa}{SystemC for extensible MIPS }
+ { A SystemC simulation model for a simple extensible MIPS architectural template }
+ \itemL{12}{20}{x}{\Sirisa}{SystemC for extensible MIPS}{2:3:0}
+ {A SystemC simulation model for an extensible MIPS with a tight architectural integration of
+ its instruction set extensions}
+ \itemL{0}{12}{x}{\Sirisa}{SystemC for NIOS processor}{2:0:0}
+ { A SystemC simulation model for an extensible NIOS processor template, the VHDL model being
+ already available from \altera}
+ \itemV{3}{18}{h}{\Sirisa}{VHDL for an extensible MIPS}
+ {A synthesizable VHDL model for a simple extensible MIPS architectural template}
+ \itemL{18}{24}{h}{\Sirisa}{VHDL for extensible MIPS}{9:12:0}
+ {A synthesizable VHDL model for an extensible MIPS with a tight architectural integration of
+ its instruction set extensions}
+ \itemL{24}{36}{d}{\Sirisa}{Evaluation report }{0:0:2}
+ {An evaluation report with quantitative analysis of the performance/area trade-off induced by
+ the different approaches}
+ \end{livrable}
+
+ \subtask Extraction of parallelism in polyhedral loops and conversion into a process network.
+
+ \begin{livrable}
+ \itemV{0}{6}{d}{\Slip}{Method, Preliminary Definition}
+ Description and specification of a process construction method for programs with
+ polyhedral loops.
+ \itemL{30}{36}{d}{\Slip}{Process generation method}{10:0:9}
+ Final assessment of the method and improved version of the specification.
+ \itemV{6}{12}{x}{\Slip}{Process construction}
+ Preliminary implementation in the Syntol framework.
+ At this step the software will just implement a single constructor.
+ \itemV{12}{18}{x}{\Slip} {Arrays and FIFO}
+ Implementation of the array contraction and FIFO construction algorithm.
+ Conversion of the input and output to the \xcoach format.
+ \itemV{18}{30}{d+x}{\Slip}{Non-polyhedral extension}
+ Extension of automatic parallelization and array contraction
+ to non-polyhedral loops. Implementation in the Bee framework.
+ \itemL{30}{36}{x}{\Slip} {Process/FIFO construction}{10:20:12}
+ Final release taking into account the feedbacks from the
+ demonstrator \STs.
+ \end{livrable}
+
+\end{workpackage}
+
Index: /anr-2010/task-4.tex
===================================================================
--- /anr-2010/task-4.tex (revision 274)
+++ /anr-2010/task-4.tex (revision 274)
@@ -0,0 +1,99 @@
+\begin{taskinfo}
+\let\UBS\leader
+\let\UPMC\enable
+\let\TIMA\enable
+\let\XILINX\enable
+\end{taskinfo}
+%
+\begin{objectif}
+The objectives of this task are to provide the two HAS back-ends of the COACH project and
+a tool that adapt the coprocessor frequency to the FPGA-SoC frequency as required
+by the processors and the system BUS.
+%pourquoi en majuscule?
+\\
+The HAS back-ends as shown in figure~\ref{archi-hls} reads an \xcoach description and provides an
+\xcoachplus description, i.e. an \xcoach description annotated with hardware information such as
+variables binding to registers, operations bindings to cells/fonctional units, operation scheduling...
+The \xcoach format being generated by the \novers{\specXcoachToCA} deliverable and the \xcoachplus being treated by
+the \novers{\specXcoachToSystemC} and the \novers{\specXcoachToVhdl} deliverables,
+this task strongly depends on task~1.
+\par
+For the two HAS front-end, this task is based on the already existing HLS tools GAUT and
+UGH. These tools are complementary and not in competition because they cover respectively
+data and control dominated designs.
+The organization of the task is firstly to quickly integrate the existing HLS to the COACH
+framework. Secondly these tools will be improved to allows to treat data dominated application
+with a few control for GAUT and control dominated application with a few data processing
+for UGH. This will enlarge the domain the HLS can cover which is a strong limitation of the
+tools currently avilable \cite{HLSBOOK} \cite{IEEEDT} \cite{CATRENE}.
+\end{objectif}
+
+%FIXMA == {il faudrait fusionner les taches ST5-1 et ST5-2, non ???}
+\begin{workpackage}
+\subtask The goal of this \ST is to integrate the UGH HLS tool to the COACH framework. It
+ consists of suppressing the C compiler and the SystemC and VHDL drivers and replacing
+ them by \xcoach and \xcoachplus drivers i.e. C2X, X2SC and X2VHDL.
+ \begin{livrable}
+ \itemL{6}{12}{x}{\Stima}{UGH integration}{12:0:0}
+ Release of the UGH software that reads \xcoach format.
+ \itemV{12}{18}{x}{\Supmc}{UGH integration}
+ Release of the UGH software that writes \xcoachplus format.
+ \itemL{18}{33}{x}{\Supmc}{UGH integration}{0:2:4.0}
+ Final release of the UGH software.
+ \end{livrable}
+\subtask The goal of this \ST is to integrate the GAUT HLS tool to the COACH framework. It
+ consists of suppressing the C compiler and the SystemC and VHDL drivers and replacing
+ them by \xcoach and \xcoachplus drivers.
+ \begin{livrable}
+ \itemL{6}{12}{x}{\Subs}{GAUT release reading \xcoach}{6:0:0}
+ Release of the GAUT software that is able to read \xcoach format.
+ \itemL{12}{18}{x}{\Subs}{GAUT release writing \xcoachplus}{0:6:0}
+ Release of the GAUT software that is able to read \xcoach format and to write \xcoachplus format.
+ %\itemL{18}{33}{x}{\Subs}{Final release of GAUT}{0:1:6}
+ % Final release of the GAUT software.
+ \end{livrable}
+\subtask The goal of this \ST is to improve the UGH and GAUT HLS tools.
+ UGH and GAUT experimentations have shown respectively usefull enhancements.
+ \begin{livrable}
+ \itemL{18}{24}{x}{\Stima}{UGH enhancement 1}{0:9:0}
+ Release of the UGH software with support for treating automatically data dominated sections
+ included into a control dominated application.
+ \itemL{21}{27}{x}{\Stima}{UGH enhancement 2}{0:3:6}
+ Release of the UGH software able to generate a micro-architecture without the
+ variable binding currently done by the designer.
+ \itemL{12}{24}{x}{\Subs}{Release of GAUT with \ganttlf enhanced synthesis steps}{0:9:0}
+ Release of the GAUT software that supports the \xcoach model during the binding and the scheduling steps.
+ \itemL{24}{33}{x}{\Subs}{Release of GAUT supporting \ganttlf new const./obj.}{0:0:7}
+ Release of the GAUT software that supports the \xcoach model during the binding and the scheduling steps
+ and also supports new constraints and objectives.
+ \itemV{18}{24}{d}{\Subs}{Micro-architecture Exploration}\setMacroInAuxFile{MAE}
+ Specification of a Design Space Exploration framework for the HAS Back-end:
+ The high level specification tools, such as GAUT, have to be able to use synthesis feed-back
+ informations in order to explore the design space and to generate optimized architectures.
+ \itemL{24}{36}{x}{\Subs}{Micro-architecture Exploration}{0:4:4}
+ Release of the GAUT software that supports the features defined in \MAE
+ \end{livrable}
+\subtask In FPGA-SoC, the frequency is given by the processor(s) and the system BUS. The coprocessors
+ generated by HLS synthesis must respect this frequency. However, the HLS tools can not
+ guarantee that the micro-architectures they generate accurately respect this
+ frequency. This is especially the case when the target is a FPGA device, because the
+ delays are really known only after the RTL synthesis and that estimated delays used
+ by the HLS are very inaccurate. The goal of this \ST is to provide a tool that adapts
+ the coprocessors frequency to the FPGA-SoC frequency after the coprocessor RTL
+ synthesis.
+ \begin{livrable}
+ \itemV{0}{12}{d}{\Supmc}{Frequency calibration}
+ A document describing the set up of the coprocessor frequency calibration.:
+ \itemV{12}{24}{x}{\Supmc}{Frequency calibration}
+ \setMacroInAuxFile{freqCalibrationVhdl}
+ A VHDL description of hardware added to the coprocessor to enable the calibration.
+ \itemL{24}{33}{x}{\Supmc}{Frequency calibration}{2:.5:3.5}
+ The frequency calibration software consists of a driver in the FPGA-SoC operating
+ system and of a control software.
+ \itemL{24}{27}{d}{\Sxilinx}{\xilinx RTL optimisation (5)}{0:0:1.5}
+ This deliverable consists in optimizing the VHDL description provided in
+ \novers{\freqCalibrationVhdl}.
+ \upmc will provide the VHDL description, \xilinx will provide back a documentation
+ listing that proposes VHDL generation enhancements.
+ \end{livrable}
+\end{workpackage}
Index: /anr-2010/task-5.tex
===================================================================
--- /anr-2010/task-5.tex (revision 274)
+++ /anr-2010/task-5.tex (revision 274)
@@ -0,0 +1,119 @@
+% vim:set spell:
+% vim:spell spelllang=en:
+
+\begin{taskinfo}
+\let\BULL\leader
+\let\UPMC\enable
+\let\TIMA\enable
+\let\THALES\enable
+\let\XILINX\enable
+\end{taskinfo}
+%
+\begin{objectif}
+This task pools the features dedicated to HPC system design. It is described on
+figures~\ref{coach-flow} and \ref{archi-hpc}. It consists in
+\begin{itemize}
+\item Providing a software tool that helps the HPC designer to find a good partition of the initial application
+ (figure~\ref{archi-hpc}).
+\item specification of the communication schemes between the software part running on the PC and the
+FPGA-SoC.
+\item Implementing the communication scheme at all levels: partition help, software
+implementation both on the PC and in the operating system of the FPGA-SoC, hardware.
+\item Providing support for dynamic partial reconfiguration of \xilinx FPGA in order
+to optimize FPGA ressource usage.
+\end{itemize}
+
+The low level hardware transmission support will be the PCI/X bus which allows high bit-rate
+transfers. The reasons of this choice are that both \altera and \xilinx provide PCI/X IP for
+their FPGA and that GPU HPC softwares use also it.
+%This will allow us at least to be inspired by GPU communication schemes and may be to reuse
+%parts of the GPU softwares.
+
+\end{objectif}
+%
+\begin{workpackage}
+ \subtask
+ This \ST deals with the COACH HPC feature that consists in accelerating an existing
+ apllication running on a PC by migrating critical parts into a SoC implemented on an
+ FPGA plugged to the PC PCI/X bus.
+ The main steps and components of this \ST are:
+ \begin{itemize}
+ \item The definition of the communication middleware as a software API (Application
+ Programing Interface) between the application part running on the PC and the
+ application part running on the FPGA-SoC.
+ \item A software for helping the end-user to partition applications (figure~\ref{archi-hpc}).
+ This software is a library implementing the communication API with features to profile
+ the partitioned application.
+ \item The implementation of the communication API on the both sides (PC part and FPGA-SoC).
+ \end{itemize}
+ \begin{livrable}
+ \itemL{0}{6}{d}{\Sbull}{HPC communication API}{3:0:0}
+ \setMacroInAuxFile{hpcCommApi}
+ Specification describing the API.
+ \itemL{6}{12}{x}{\Supmc}{HPC partionning helper}{1:0:0}
+ \setMacroInAuxFile{hpcCommHelper}
+ A library implementing the communication API defined in the {\hpcCommApi} deliverable.
+ This library is dedicated to help the end-user to partition an applicattion for
+ HPC.
+ \itemL{12}{21}{x}{\Supmc}{HPC API for Linux PC}{0:2.5:0}
+ \setMacroInAuxFile{hpcCommLinux}
+ The PC part of the HPC communication API that comminicates with the FPGA-SOC, a
+ library and probably a LINUX module.
+ \itemL{12}{21}{x}{\Supmc}{HPC API for MUTEKH OS}{0:2.5:0}
+ \setMacroInAuxFile{hpcMutekDriver}
+ The FPGA-SoC part of the communication API, a driver.
+ \itemL{21}{24}{x}{\Stima}{HPC API for DNA OS}{0:3:0}
+ \setMacroInAuxFile{hpcDnaDriver}
+ Port of the {\hpcMutekDriver} driver on the DNA OS.
+ \itemL{24}{33}{x}{\Supmc}{HPC API}{0:0:1}
+ Bug corrections and enhancements of communication middleware
+ (\novers{\hpcCommApi}, \novers{\hpcCommHelper}, \novers{\hpcCommLinux},
+ \novers{\hpcMutekDriver}, \novers{\hpcDnaDriver}).
+ \end{livrable}
+
+\subtask This \ST deals with the implementation of hardware and SystemC modules
+ required by the neutral architectural template for using the PCI/X IP of \altera and \xilinx.
+ \begin{livrable}
+ \itemL{9}{18}{h}{\Stima}{HPC hardware \xilinx}{3:9:0}
+ \setMacroInAuxFile{hpcPlbBridge}
+ The synthesizable VHDL description of a PLB/VCI bridge and its corresponding SystemC model.
+ \itemL{9}{18}{h}{\Supmc}{HPC hardware \altera}{1:2:0}
+ \setMacroInAuxFile{hpcAvalonBridge}
+ The synthesizable VHDL description of an AVALON/VCI bridge and its corresponding SystemC model.
+ \itemL{9}{24}{h}{\Supmc}{PCI/X traffic generator}{1:1:0}
+ The SystemC description of a component that generates PCI/X traffic. It is
+ required to prototype FPGA-SoC dedicated to HPC.
+ \end{livrable}
+
+\subtask This \ST consists in integrating dynamic partial reconfiguration of \xilinx FPGA in the CSG design flow.
+It also includes appropriate SoC-FPGA OS drivers and a modification of the profiling library.
+ \begin{livrable}
+ \itemL{24}{36}{x}{\Supmc}{CSG support for \ganttlf reconfiguration}{0:0:2}
+ Modification of the CSG software to support statically reconfigurable tasks.
+ \itemL{18}{36}{x}{\Stima}{CSG module for \ganttlf dynamic reconfiguration}{0:4:12}
+ This livrable is a CSG module allowing to partition the task graph along
+ the dynamic partial reconfiguration regions. The resulting task-region assignement
+ is directly used for generation of bitstreams. The module also produces reconfiguration
+ management software to be run on the SoC-FPGA.
+ \itemL{18}{30}{x}{\Stima}{Dynamic reconfiguration \ganttlf for DNA drivers}{0:3:3}
+ \setMacroInAuxFile{hpcDynconfDriver}
+ The drivers required by the DNA OS in order to manage dynamic partial
+ reconfiguration inside the SoC-FPGA.
+ \itemL{30}{36}{x}{\Supmc}{Dynamic reconfiguration \ganttlf for MUTEKH drivers}{0:0:1}
+ Port of the {\hpcDynconfDriver} drivers on the MUTEKH OS.
+ \itemL{24}{36}{x}{\Stima}{Profiler for \ganttlf dynamic reconfiguration}{0:0:6}
+ Extension of the HPC partionning helper in order to integrate dynamic partial
+ reconfiguration dedicated features (reconfiguration time of regions, variable
+ number of coprocessors).
+ \itemL{24}{36}{d}{\Sxilinx}{Optimisation for \xilinx \ganttlf dynamic reconfiguration}{0:0:2}
+ \xilinx will work with \tima in order to better take into account during
+ partitioning decisions specific constraints due to partial reconfiguration process.
+ The deliverable is a document describing the \xilinx specific constraints.
+ \end{livrable}
+%\item This \ST is the delivery of 2 PCI/X \mustbecompleted{FIXME: Stratix4} FPGA board
+% with its PCI/X IP. These boards are dedicated to the COACH HPC development.
+% They are based on \mustbecompleted{FIXME:stratix4} FPGA device of 400,000 LUT.
+% \begin{livrable}
+% \itemL{0}{6}{m}{\Saltera}{HPC development boards}{0:0:0} Two PCI/X FPGA boards.
+% \end{livrable}
+\end{workpackage}
Index: /anr-2010/task-6.tex
===================================================================
--- /anr-2010/task-6.tex (revision 274)
+++ /anr-2010/task-6.tex (revision 274)
@@ -0,0 +1,179 @@
+\begin{taskinfo}
+\let\BULL\enable
+\let\THALES\leader
+\let\NAVTEL\enable
+\let\ZIED\enable
+\end{taskinfo}
+%
+\begin{objectif}
+This task groups the demonstrators of the COACH project.
+The demonstrators cover various domains and application types to drive
+the specification choices and to check most of the COACH features.
+\end{objectif}
+%
+\begin{workpackage}
+ \subtask
+ The application that \bull proposes is HPC oriented.
+ The domain of the application is the treatment of medical images (image noise
+ reduction and segmentation or registration).
+ Our expectation from COACH project is to enhance the \bull HPC solutions that
+ are currently based on multi-cores and GPUs with fine grain parallelism on FPGA.
+ \begin{livrable}
+ \itemV{0}{6}{d}{\Sbull}{\bull demonstrator}
+ The deliverable is a document that describes the application that will be use as
+ demonstrator.
+ \itemV{6}{12}{x}{\Sbull}{\bull demonstrator}
+ The deliverable is the specification of the demonstrator in COACH input format
+ defined in the {\specGenManual} deliverable.
+ \itemL{12}{36}{d}{\Sbull}{\bull demonstrator}{2:6:10}
+ Validation of the demonstrator, the deliverable is a document
+ describing the result of the experimentations.
+ \end{livrable}
+
+ \subtask
+ The objective of this sub-task is to specify the THALES application and to develop the
+ high level code. This application is in the domain of surveillance of critical
+ infrastructures. The objective is to detect and classify the presence of humans in the
+ restricted area. The algorithm is based on the work of Viola and
+ Jones~\cite{thales-viola}. It implements in particular a cascade of classifiers
+ operating on Haar like features, where simple weak classifiers at the beginning of the
+ cascade reject a majority of void sub-windows, before more complex classifiers
+ concentrate on potential regions of interest. This application is computation
+ intensive and also makes an intensive use of binary decision trees to cascade the
+ filters, which makes it a good candidate to assess the COACH platform.
+ \\
+ Moreover, the higher levels of computing can involve tracking and data fusion between
+ several camera streams and some other informations.
+ The targeted system will be composed of one camera connected to a PC.
+ All the computing part of the application is executed on a FPGA board connected to the
+ PC.
+ \begin{livrable}
+ \itemV{0}{6}{d}{\Sthales}{\thales demonstrator (step 1)}
+ \setMacroInAuxFile{trtAppSpecification}
+ This deliverable is a document that specifies the application.
+ \itemL{6}{12}{x}{\Sthales}{\thales demonstrator (step 1)}{4:0:0}
+ This deliverable is the code of the application spcecified former
+ deliverable (\trtAppSpecification).
+ \end{livrable}
+
+ \subtask \TRT will use its internal software environment tool SPEAR DE to describe the
+ application. The tool is able to partition and to generate the code for the target. \\
+ In this task, we will adapt SPEAR DE to generate the application description input of
+ COACH framework. We will also describe the three templates of architecture in order to
+ be able to partition the application on the architecture.
+ \begin{livrable}
+ \itemL{6}{18}{x}{\Sthales}{SPEAR-DE adaptation}{6:7:0}
+ \setMacroInAuxFile{trtSpearde}
+ Adaptation of SPEAR-DE for COACH framework.
+ \end{livrable}
+
+ \subtask
+ In this sub-task, \TRT will evaluate the COACH platform. In particular, \TRT will verify
+ its ability to generate a whole VHDL of an embedded system on FPGA for an application
+ mixing control and data flow aspects. \TRT will evaluate the performance of the
+ generated system in terms of GOPS, and the design time from a high level description.
+ \begin{livrable}
+ \itemV{18}{24}{d+x}{\Sthales}{\thales demonstrator (step 2)}
+ This deliverable is a document describing the result got for the application
+ (\trtAppSpecification) with SPEAR-DE (\trtSpearde) using COACH milestone of T0+18.
+ The updated code of the application will be also provide.
+ \itemV{24}{30}{d+x}{\Sthales}{\thales demonstrator (step 2)}
+ This deliverable is a document describing the result got for the application
+ (\trtAppSpecification) with SPEAR-DE (\trtSpearde) using COACH milestone of T0+24.
+ The updated code of the application will be also provide.
+ \itemL{30}{36}{d+x}{\Sthales}{\thales demonstrator (step 2)}{0:5:5}
+ This deliverable is a document that validates and evaluates COACH (final release)
+ for the \thales demonstrators (\trtAppSpecification).
+ The updated code of the application will be also provide.
+ \end{livrable}
+
+ \subtask FLEXRAS will design an application based on M-JPEG video standard.
+ FLEXRAS will propose a SoC architecture integrating an embedded FPGA (eFPGA).
+ The architecture is composed essentially of a processor, a bus and several RAMs.
+ The embedded FPGA is connected to the bus and communicates with the other components.
+ The (eFPGA) works in 2 modes:
+ \begin{description}
+ \item[Slave mode]
+ As a DMA, the processor will send the configuration bitstream
+ stored on the RAM to the eFPGA. In this mode, the eFPGA is considered as a
+ writeable memory and is configured by the processor.
+ \item[Master mode]
+ Once the FPGA is programmed, it becomes a coprocessor achieving the aimed task.
+ \end{description}
+ The top architecture of this SoC based-platform will be generated using COACH
+ framework. The application that will be run on the SoC corresponds initially to a
+ graph of software tasks. Critical tasks will be identified and transformed
+ automatically to hardware tasks using COACH high level synthesis feature. While
+ software tasks will be run on the processor, hardware ones will be mapped on eFPGA
+ to take advantage of its optimized resources and parallelism. FLEXRAS provides all
+ the flow from RTL synthesis to bitstream generation.
+ \begin{livrable}
+ \itemL{0}{6}{d}{\Szied}{\zied architecture}{2.4:0:0}
+ FLEXRAS will use IPs provided by LIP6 (vhdl models of SoCLIB) and its eFPGA IP to
+ generate the SoC architecture.
+ This deliverable is a document that describes this architecture.
+ \itemL{6}{18}{h}{\Szied}{eFPGA/VCI component}{3.6:3.6:0}
+ FLEXRAS has to adapt the eFPGA interface to connect it to the VCI bus.
+ This deliverable is a VHDL description.
+% \itemL{12}{18}{x}{\Szied}{bitstream loader port}{0:3.6:0}
+% Port of the bitstream loader to the MUTEKH operating system.
+ \itemL{18}{24}{x}{\Szied}{\zied demonstrators}{0:2.4:0}
+ \zied will propose to test COACH framework and the \zied architecture template
+ throught an application based on M-JPEG video standard.
+ This applicattion will containt 3 communicating tasks under the COACH format specified
+ in {\novers{\specGenManual}} deliverable.
+ The first one is a hardware task generated by the HAS tools and transformed into
+ a bit stream by the \zied tools.
+ The second is a bitstream loader that will load the bitstream of the first task on
+ the eFPGA.
+ The third is a software task that communicates with the hw task for testing it.
+ \itemL{24}{30}{x}{\Szied}{eFPGA characterisation}{0:0:2.4}
+ This deliverable is a file under the format defined by the deliverable
+ {\specMacroCell} that characterizes the eFPGA. This will allow the COACH HLS tools
+ to take into account the eFPGA delays.
+ \itemL{30}{36}{d}{\Szied}{\zied evaluation}{0:0:3.6}
+ This deliverable is a document that describes the tests, the validation and the
+ evaluation of COACH with the \zied architecture and tools.
+ \end{livrable}
+
+ \subtask
+ The \navtel Embedded Supper Computing (ESC) project is based on simple hardware but tightly
+ coupled module between %ARM
+ a embedded processor and an FPGA both on a board.
+ By using the COACH environment, \navtel will automatically synthetize two cores: one for software radio
+ through a polyphase resampler and one for an industrial control application through an embedded
+ PID controller.
+ The objective is to sequence the cores in realtime in FPGA using partial configuration methods
+ proposed in the COACH project.
+ This will allow us to gain experience on automatic multi core sequencing at system level. The
+ specification for our first work package will concern this aspect.
+
+ The ESC can function on different topologies: Single, parallel or Grid computing modes for
+ industrial and scientific applications.
+ %The ARM
+ The processor and FPGA configuration also facilitate the co-simulation which allows to gain
+ time on the development and integration phase.
+ The architecture consists of a wrapper that encapsules computing units depending on the
+ application and a real time kernal for task switching and partial reconfiguration of FPGA
+ on run time environment.
+ \parlf
+ To day \navtel develops these computing units manually.
+ \navtel expects to benefit from the COACH project especially the HLS tools for
+ generating the computing unit.
+ \begin{livrable}
+ \itemL{0}{6}{d}{\Snavtel}{\navtel \ganttlf demonstrator specification}{4:0:0}
+ \setMacroInAuxFile{navtelSpecification}
+ A document that will define the requirements for automatic RTL generation for
+ signal processing units of our market sector such as digital communication,
+ imaging and industrial control.
+ This document will include the description of some already handmade processing units.
+ \itemL{6}{18}{h}{\Snavtel}{\navtel \ganttlf wrapper adaptation}{1:1:0}
+ The adaptation of our wrapper to support coprocessor generated by COACH.
+ \itemL{18}{36}{d}{\Snavtel}{\navtel evaluation}{0:2:4}
+ \navtel will test the COACH HLS tools on the processing units that are described
+ in the {\navtelSpecification} deliverable.
+ A document will be written that describes the results obtained taking into
+ account: 1) the performance in terms of space, 2) the performance in terms of
+ time, 3) the friendlyness of the environment.
+ \end{livrable}
+\end{workpackage}
Index: /anr-2010/task-7.tex
===================================================================
--- /anr-2010/task-7.tex (revision 274)
+++ /anr-2010/task-7.tex (revision 274)
@@ -0,0 +1,80 @@
+\begin{taskinfo}
+\let\UPMC\leader
+\let\ALL\enable
+\end{taskinfo}
+%
+\begin{objectif}
+This task relates to the diffusion of the project results.
+The objective is to ensure the COACH dissemination by publishing on a public WEB site all
+the information that a COACH user requires.
+The main information features are:
+\begin{itemize}
+\item The COACH releases (milestones and final release) and their associated installation manuals.
+\item The COACH user reference manual.
+\item The user manual of the various tools.
+\item A COACH tutorial.
+\item The conference publication.
+\item A user wiki.
+\end{itemize}
+\end{objectif}
+%
+\begin{workpackage}
+ \subtask This \ST relates to the management of the WEB site and to the distribution of
+ the COACH releases.
+ \begin{livrable}
+ \itemV{0}{6}{d}{\Supmc}{Dissemination WEB site}
+ This deliverable consists firstly in providing a WEB site (name, HTTP server
+ setup, wiki) and secondly in defining the site map and finally in writting and
+ installing the pages.
+ \itemL{6}{36}{d}{\Supmc}{Dissemination WEB site}{1:.5:.5}
+ This deliverable corresponds to the standard management of a WEB site (modifying,
+ adding, suppressing, replacing pages).
+ Especialy the user reference manuals provided in the other tasks will be published
+ on this site. The published articles will be also be installed in this site.
+ \itemL{6}{36}{d+x}{\Supmc}{Release handling}{1:.5:.5}
+ This deliverable deals with the elaboration of the COACH software milestones and
+ final releases with their installation manuals and to publish then into the WEB
+ site.
+ \CoutHorsD{12}{36}{\Stima}{dissemination}{0:2:1}
+ \end{livrable}
+ \subtask
+ \label{subtask-tutorial}
+ This \ST consists of making a COACH tutorial and to publish it on the public WEB
+ site. The tutorial example will also be used as reference demonstrator of the
+ framework.
+ The application of this tutorial will be a Motion JPEG application.
+ \begin{livrable}
+ \itemV{0}{6}{x}{\Supmc}{Tutorial specification}
+ Choice of the application and its implementation as a C/C++ program.
+ \itemV{6}{12}{d+x}{\Supmc}{Tutorial}
+ The application is split into two communicating parts, the PC part and FPGA-SoC part.
+ By using the features the T0+12 milestone provides,
+ the tutorial describes how this efficient partionning was obtained.
+ The FPGA-SoC part is described as communicating task graph. The tutorial also describes
+ how a promising task graph can be obtained.
+ \itemV{18}{24}{d}{\Supmc}{Tutorial}
+ This tutorial shows how a task can be migrated to coprocessor using HAS tools and
+ how FPGA-SoC can be generated and run to FPGA. This for HAS tools and and
+ architectural template available in T0+24 milestone.
+ \itemL{30}{36}{d}{\Supmc}{Tutorial}{2:1:1}
+ The final release of the tutorial.
+ \itemL{30}{33}{d}{\Sxilinx}{\xilinx feedback}{0:0:0.5}
+ \xilinx will check that the developped tutorial works well with \xilinx tools,
+ and will propose corrections or enhancements if needed into a document.
+ \end{livrable}
+ \subtask
+ This \ST consists of making the COACH user reference manuals.
+ They will be published on the public WEB site.
+ \begin{livrable}
+ \itemL{18}{24}{d}{\Stima}{CSG User manual}{0:1:0}
+ This user manual shows how to generate a complete HW/SW system by using CSG tool.
+ \itemL{18}{24}{d}{\Slip}{HAS front-end user manual}{0:1:0}
+ This user manual shows how to apply loop transformations to a task.
+ \itemL{18}{36}{d}{\Sirisa}{ASIP user manual}{0:1:1}
+ This user manual shows how to customize a processor to obtain an ASIP.
+ \itemL{18}{24}{d}{\Subs}{HLS user manual}{0:1:0}
+ This user manual shows how a task can be synthesized by using HLS tools developped in
+ the COACH project.
+ \CoutHorsD{12}{36}{\Subs}{dissemination}{0:2:2}
+ \end{livrable}
+\end{workpackage}
Index: /anr-2010/wp.txt
===================================================================
--- /anr-2010/wp.txt (revision 274)
+++ /anr-2010/wp.txt (revision 274)
@@ -0,0 +1,252 @@
+
+**************************************************************************************************************
+Work package 1 : Specification de l'architecture logicielle de COACH et outils communs:
+
+TASK-1 LIP6+ALL Specification de COACH au niveau du concepteur de systeme:
+ COACH est une boite noire, les entrées, les sorties, le flot
+ de conception préconisé, Définition de l'architecture du MP-SoC et ses 3 mappings
+ 0+6 LIP6 Livrable-1: un document
+
+TASK-2 LIP6+ALL Structure interne de COACH.
+ 0+6 LIP6 Livrable: un document
+
+TASK-3 LAB-STIC+ALL Définition du language commun annoté (xfg: xlm flow graph)
+ 0+6 LIP Livrable 1: V0 un document, une dtd
+ 0+12 LIP Livrable 1: V1 un document, une dtd
+ 0+18 Livrable 1: V2 expression du potentiel des boucles
+
+ 0+12 LAB-STIC Livrable 2: VO gcc2coach, coach2c
+ 0+18 LAB-STIC FI gcc2coach, coach2c
+ 0+18 LIP6 Livrable 3: VO coach2systemc
+ 0+24 LIP6 FI coach2systemc
+ LAB-STIC : Livrable 4: V0 0+18 coach2vhdl
+ V1 : 0+24
+ FI : 0+32
+
+TASK-4 LAB-STIC+ALL Définition et description des cellules de base et de leur caractéristques.
+ 0+6 LAB-STIC Livrable 1: un document
+ 0+12 LAB-STIC Livrable 2: outil de caractéristion automatique
+
+**************************************************************************************************************
+Work package 2 : Outils de conception systemes:
+
+TASK-1 LIP6 Mutek Operating sytem
+ 0+12 LIP6 Livrable 1: OS pour Embedded System
+ 0+30 LIP6 Livrable 2: OS pour HPC (driver PCI/X) et reconfiguration dynamique
+
+TASK-2 TIMA DNA Operating sytem
+ 0+12 TIMA Livrable 1: OS pour Embedded System
+ 0+30 TIMA Livrable 2: OS pour HPC (driver PCI/X) et reconfiguration dynamique
+
+TASK-3 LIP6+ALL Definition de l'entrée de CSG (Coach System Generator):
+ la syntaxe d'entrée TCG, architecture,
+ les primitives de communication entre taches
+ (variable globale, canaux, tampon ping-pong).
+ 0+6 LIP6 Livrable 1: document
+ 0+12 LIP6 Livrable 2: Executable sans reconfiguration: gestion des 3 architectures.
+ 0+30 TIMA+LIP6 Livrable 3: CSG avec reconfiguration +++++ Ajouter CDP-2-3
+
+TASK-4 LIP6 Composants matériels de l'architecture SOCLIB + composants génériques
+ 0+18 LIP6 Livrable 1: VHDL synthetisable des composants VCI : MWMR, IRQ.
+wrapper
+ 0+18 IRISA? Livrable 2: wrapper SystemC VCI/AVALON
+ 0+18 IRISA? Livrable 3: wrapper VHDL synthé VCI/AVALON
+ 0+18 TIMA? Livrable 4: wrapper SystemC VCI/PLB
+ 0+18 TIMA? Livrable 5: wrapper VHDL synthé VCI/PLB
+
+ 0+18 CITI Livrable 6: VHDL synthetisable d'un composant VCI MWMR++ (DMA intelligent)
+ 0+18 CITI Livrable 7: modèle SystemC d'un composant MWMR++ VCI(DMA intelligent)
+ 0+18 LAB-STICC Livrable 8: VHDL synthetisable d'un composant spatio-temporel
+
+
+sans wrapper
+ 0+18 TIMA Livrable 2: VHDL synthetisable des composants PLB :MWMR, IRQ.
+ 0+18 TIMA Livrable 3: modèle SystemC des composants PLB :MWMR, IRQ.
+ 0+18 IRISA? Livrable 4: VHDL synthetisable des composants AVALON : MWMR, IRQ.
+ 0+18 IRISA? Livrable 5: modèle SystemC des composants AVALON :MWMR, IRQ.
+
+ 0+18 CITI Livrable 6: VHDL synthetisable d'un composant VCI MWMR++ (DMA intelligent)
+ 0+18 CITI Livrable 6: VHDL synthetisable d'un composant PLB MWMR++ (DMA intelligent)
+ 0+18 CITI Livrable 6: VHDL synthetisable d'un composant AVALON MWMR++ (DMA intelligent)
+ 0+18 CITI Livrable 6: modèle SystemC d'un composant MWMR++ VCI(DMA intelligent)
+ 0+18 CITI Livrable 6: modèle SystemC d'un composant MWMR++ PLB (DMA intelligent)
+ 0+18 CITI Livrable 6: modèle SystemC d'un composant MWMR++ AVALON(DMA intelligent)
+
+ 0+18 LAB-STICC Livrable 7: VHDL synthetisable d'un composant spatio-temporel
+
+TASK-5 TIMA Composants matériels de l'architecture Xilinx
+ 0+18 TIMA Livrable 1: modele systemC des composants MWMR, IRQ.
+ 0+20 TIMA Livrable 2: VHDL synthetisable des composants MWMR, IRQ.
+
+TASK-6 IRISA Composants matériels de l'architecture Altera
+ 0+18 IRISA Livrable 1: modele systemC des composants MWMR, IRQ.
+ 0+20 IRISA Livrable 2: VHDL synthetisable des composants MWMR, IRQ.
+
+**************************************************************************************************************
+Work package 3 : Outils de synthese front-end (polyedrique et ASIP)
+
+TASK-1 IRISA Extraction de motifs et regénération au format COACH annoté
+ 0+18 Livrable 1: V0 Intégration manuelle des motifs
+ 0+24 FI Intégration automatique des motifs (architecture-dépendant)
+
+TASK-2 IRISA Définition d'un modele simplifie de micro-architecture capable d'éxecuter des motifs issues de la tâche 1
+ 0+12 Livrable 1: Modèle SystemC du MIPS extensible
+ 0+18 Livrable 1: Modèle VHDL du MIPS extensible
+
+ 0+12 Livrable 2: Modèle SystemC du NIOS extensible
+ 0+18 Livrable 2: Modèle VHDL NIOS extensible
+
+ 0+12 Livrable 3: Modèle SystemC du µblaze extensible ??
+ 0+18 Livrable 3: Modèle µBlaze extensible ???
+
+
+TASK-3 IRISA Définition d'un modele complexe de micro-architecture
+ 0+24 Livrable 1: Modèle SystemC du MIPS extensible
+ 0+24 Livrable 1: Modèle VHDL du MIPS extensible
+ 0+36 Livrable 2: Rapport d'evaluation
+
+
+TASK-4 LIP-ALL Exploitation des boucles Polyedriques
+ 0+12 Outil d'ordonnancement
+ 0+18 Outil d'exploration des transformations
+ 0+24 generation du code xfg etendu V1
+ 0+30 gestion de la memoire et contraction des tableaux
+ 0+34 generation du code xfg etendu V2
+
+**************************************************************************************************************
+Work package 4 : Outils de synthese back-end (UGH, GAUT)
+
+TASK-1 LIP6/TIMA Adaptation de UGH a COACH
+ 0+18 TIMA Livrable 1: executable(lire du xcoach)
+ 0+18 TIMA Livrable 2: executable(ecrire du xcoach annote)
+
+TASK-2 LIP6/TIMA évolution de UGH.
+ 0+18 LIP6 Livrable 1: executable UGH qui tient compte des primitives d'IO definies
+ dans le WP2-T3
+ 0+?? TIMA Livrable 2: executable UGH qui peut generer une architecture sans que les assignations
+ des variables sur les registres soient explicites.
+
+TASK-3 LAB-STICC Adaptation de GAUT a COACH
+ 0+18 Livrable 1: executable(lire du xcoach)
+ 0+18 Livrable 2: executable(ecrire du xcoach annote)
+
+TASK-4 LAB-STICC évolution de GAUT
+ 0+18 Livrable 1: prise en compte du modèle CDFG
+ 0+?? Livrable 2: génération d'architecture multi-clock.
+ 0+?? Livrable 3: synthése hierachique
+
+TTASK-5 LIP6 Calibrage de la fréquence des coprocesseurs
+ 0+6 LIP6 Livrable 1: document
+ 0+12 LIP6 Livrable 2: VHDL synthetisable de la FSM calibrable dynamiquement
+ 0+20 LIP6 Livrable 3: logiciel de calibrage (cote OS et cote PC).
+
+
+**************************************************************************************************************
+Work package 5 : Interlogiciel de communication PC/Accélérateur:
+
+TASK-1 LIP6+ALL Définition des protocoles de communication entre l'application qui
+ tourne sur le PC et le TCG qui tourne sur l'accélérateur.
+ 0+6 LIP6 Livrable 1: Document.
+
+TASK-2 LIP6 Outils d'aide au bi-partitionnement (mesure de l'efficacité)
+ 0+12 LIP6 Livrable 1: Librairie C de communication contenant du code permettant
+ d'estimer l'efficacite.
+
+(TASK inutile si bridge)
+TASK-3 ???? HW pour l'architecture SOCLIB
+ 0+?? ???? Livrable: VHDL synthetisable d'un pont VCI/Avalon
+ 0+?? TIMA Livrable: VHDL synthetisable d'un pont VCI/Bus-xilinx
+
+TASK-4 ???? Sofware pour HPC
+ 0+?? ???? Livrable 1: driver PCI/X de IP Altera
+ 0+?? TIMA Livrable 2: driver PCI/X de IP Xilinx
+ 0+20 LIP6 Livrable 3: Implantation du protocole deifini en TASK-1 du cote PC/Linux
+ et SOC.
+
+
+**************************************************************************************************************
+
+---------------------------------------------------------------------------------
+Annexe 1
+Actions de base determinees lors d'une reunion LIP6/TIMA
+---------------------------------------------------------------------------------
+
+ HLS :
+UBS+TOUS *1) Définition des cellules et calibrage en fonction des cibles (WP1-T4)
+LIP6 *2) Calibrage de la fréquence des coprocesseurs
+TOUS *3) Définition de la représentation intermédiaire commune (WP1-T3)
+TOUS *4) Définition de la représentation intermédiaire annotée, en vue (WP1-T3)
+ de génération de SystemC et VHDL
+UBS *5) gcc2xml-coach, xml-coach2c (WP1-3)
+ - pilotage du front-end gcc
+LIP6 *6) xml-coach2SystemC (WP1-3)
+TIMA *7) xml-coach2VHDL (WP1-3)
+
+ UGH:
+LIP6+TIMA *1) Extension des primitives de communication (WP2-T3)
+ - variables globales, scalaires et tableaux
+ - pipeline lecture/calcul/écriture en utilisant des
+ primitives genre aio_read/aio_write/aio_return
+
+TIMA *2) génération automatique du DDP en fonction du comportement
+ relacher un peu les contraintes syntaxiques (WP4-T2)
+
+ 3) n'apparait pas dans les WP inclus implicite dans (WP4-T2 ou T1).
+TIMA+LIP6 *3) alléger la dépendance syntaxique entre le C et le DDP
+ - associer un ensemble de variables à un RGF
+ - ajout automatique des registres
+TIMA *4) Utilisation du xml à la place du front-end gcc actuel (WP4-T1)
+ donc en pratique du xml-coach2vpn
+LIP6 *5) Génération du xml-coach annoté (WP4-T1)
+
+ RECONFIGURATION DYNAMIQUE PARTIELLE:
+LIP6+TIMA *1) Introduction de la notion de conteneur : définition, (WP2-T3)
+ structuration, fusion, ...
+ Bitstream correspondants
+TIMA *2) Gestion de la reconfiguration dynamique partielle pour
+ optimiser l'utilisation des ressources FPGA
+TIMA *3) Définition de la gestion des bitstreams avec des copies
+ locales et stockage dans les hiérarchies mémoires
+LIP6+TIMA *4) Implantation sur DSX : connaissance de la notion de conteneur (WP2-T3-L3)
+TIMA+LIP6 *5) Impact sur l'OS (chargement dynamique d'applications ou de
+ tâches) (WP2-T1/T2-L2)
+
+ TOOLING FOR EMBEDDED
+ CSG (Coach System Generator) :
+TOUS *1) Définition d'un gabarit architectural (WP1-T1)
+TOUS *2) Définition de 3 mappings possibles : (WP1-T1)
+ soclib vhdl, xilinx et altera (en DSX)
+LIP6 *3) Introduire la notion de variables partagées dans DSX (WP2-T3)
+ - qui a le droit d'écrire une variable partagée ?
+LIP6+TIMA *4) Choix et fourniture des OS (WP2-T1/2-L1) et HW (WP2-T4/5/5) qui va avec
++TOUS - Etude des RAMLOCKS vs LL/SC
+ - Controleur d'interruption
+ - ...
+
+ TOOLING FOR HPC
+LIP6 *1) Définition des protocoles entre l'OS du PC et l'OS du SoC (W5-T1)
+LIP6 *2) Outil de mesure de l'efficacité d'un bi-partitionnement de (W5-T2)
+ l'application
+LIP6+TIMA+ *3) Connexion hw entre PC et SoC : pci-express (WP5-T3)
+IRISA bridge os/pci-express/avalon-plb/vci
+ (nécessite différentes implantations pour les
+ différentes cartes + drivers correspondant)
+LIP6 *4) Implantation du protocole et du loader : (WP2-T1/2-L2), WP5-T4-L3
+ lib unix, driver linux, driver os-soc
+
+
+---------------------------------------------------------------------------------
+Annexe 2
+---------------------------------------------------------------------------------
+____________________________________________________________________________________________________
+ |ICU Avalon |ICU Xilinx |MWMR Avalon |MWMR Xilinx |NIOS |MICROBLAZE |
+________|_______________|_______________|_______________|_______________|_______________|___________|
+SystemC |IRISA |TIMA |IRISA |TIMA |? |? |
+________|_______________|_______________|_______________|_______________|_______________|___________|
+VHDL |IRISA |TIMA |IRISA |TIMA |Altera |Xilinx |
+________|_______________|_______________|_______________|_______________|_______________|___________|
+
+
+François charot (IRISA) : développeur des composants soclib compatibles Avalon
+
+---------------------------------------------------------------------------------