Changeset 40
- Timestamp:
- Jan 19, 2010, 5:03:37 PM (15 years ago)
- Location:
- anr
- Files:
-
- 4 edited
Legend:
- Unmodified
- Added
- Removed
-
anr/section-4.4.tex
r38 r40 53 53 \item[\xcoachplus format (\novers{\specXcoachDoc}, 54 54 \novers{\specXcoachToSystemC}, \novers{\specXcoachToVhdl})] 55 Its aim is the generation of the coprocessors (hardware \& prototyping model) ,56 By centralizing the coprocessor generation, it guarantees their operating55 Its aim is the generation of the coprocessors (hardware \& prototyping model). 56 By centralizing the coprocessor generation, it guarantees their functioning 57 57 independently of the used HAS tools. 58 58 Our experience with UGH and GAUT give us confidence in the succes of this … … 62 62 The SocLib component library contains most of the SystemC models used for the 63 63 prototyping description of the ALTERA and XILINX architectural templates. 64 Nevertheless, at this time we do 'nt know how many are missing and if the existing64 Nevertheless, at this time we do not know how many are missing and if the existing 65 65 are really useables. 66 If the work of theses tasks is to important, they will be given up.66 If the work of theses tasks is too important, they will be abandoned. 67 67 In this case the work-arround to prototype the XILINX and ALTERA architectural 68 68 templates is to use the COACH one. These architectures being very similar, the … … 71 71 \item[VCI/AVALON \& VCI/PLB bridges (\novers{\hpcAvalonBridge}, \novers{\hpcPlbBridge})] 72 72 If one of these tasks is impossible or too important or leads to inefficiency, 73 will be given up.73 it will be abandoned. 74 74 In this case, the COACH architectural template will not be available for HPC and 75 75 a SystemC VCI model corresponding to the PCI/X IP will be developped to allow -
anr/task-4.tex
r36 r40 6 6 % 7 7 \begin{objectif} 8 Th is objectives of this task are to providesthe 2 HAS back-ends of the COACH project and9 a tool that adapt the coprocessor frequency to the FPGA-SoC frequency . This later is given8 The objectives of this task are to provide the 2 HAS back-ends of the COACH project and 9 a tool that adapt the coprocessor frequency to the FPGA-SoC frequency as given 10 10 by the processors and the BUS. 11 %pourquoi en majuscule? 11 12 \\ 12 The HAS back-ends as shown figure~\ref{archi-hls} reads \xcoach data and provides13 \xcoachplus data that is \xcoach formatannotated with hardware information such as14 variable binded on register, operation binded on cell and sheduled. The \xcoach format13 The HAS back-ends as shown in figure~\ref{archi-hls} reads \xcoach data and provides 14 \xcoachplus data, i.e. \xcoach data annotated with hardware information such as 15 variables bindings to registers, operations bindings to cells and a schedule. The \xcoach format 15 16 being generated by {\specXcoachToC} deliverable and \xcoachplus being treated by 16 17 \novers{\specXcoachToSystemC} and \novers{\specXcoachToVhdl} deliverables, 17 this task is very dependen t of thetask~1.18 this task is very dependen on task~1. 18 19 \par 19 20 For the two HAS front-end, this task is based on the already existing HLS tools GAUT and 20 tools. These tools are complementary and not competitor because they cover irespectively21 data and control dominated orthogonal domain.21 UGH. These tools are complementary and not in competition because they cover respectively 22 data and control dominated designs. 22 23 The organization of the task is firstly to integrate quickly the existing HLS to the COACH 23 24 framework. Secondly these tools will be improved to allows to treat data dominated application 24 with a few control for GAUT and control dominated application with a few data treatment25 with a few control for GAUT and control dominated application with a few data processing 25 26 for UGH. This will enlarge the domain the HLS can cover. 26 27 \end{objectif} … … 53 54 automatically data dominated sections included into a control dominated application. 54 55 \item{}{21}{27}{x}{\Stima}{UGH enhancement 2} The UGH software that is able to 55 generate a nmicro-architecture without the variable binding currently done by the56 generate a micro-architecture without the variable binding currently done by the 56 57 designer. 57 58 \item{}{18}{24}{x}{\Subs}{GAUT enhancement 1} A GAUT excutable that is able to … … 64 65 \item In FPGA-SoC, the frequency is given by the processors and the BUS. The coprocessors 65 66 generated by HLS synthesis must respect this frequency. However, the HLS tools can not 66 guarantee that the micro-architectures they generate , respect accuratelythis67 guarantee that the micro-architectures they generate accurately respect this 67 68 frequency. This is especially the case when the target is a FPGA device, because the 68 69 delays are really known only after the RTL synthesis and that estimated delays used 69 by the HLS are very impreci s. The goal of this \ST is to provide a featureto adapt70 by the HLS are very imprecize. The goal of this \ST is to provide a tool to adapt 70 71 the coprocessors frequency to the FPGA-SoC frequency after the coprocessor RTL 71 72 synthesis. -
anr/task-5.tex
r38 r40 32 32 \global\edef\hpcCommApi{\name} 33 33 \end{livrable} 34 \item This \ST aims consists in helping the application partitioning help.34 \item This \ST consists in helping to partition the application. 35 35 It is a library implementing the communication API with features to profile 36 the application partionning.36 the partitioned application. 37 37 \begin{livrable} 38 38 \item{}{6}{12}{x}{\Supmc}{HPC partionning helper} A library implementing the communication 39 39 API defined in the {\hpcCommApi} delivrable. 40 40 \end{livrable} 41 \item This \ST aims with the implementation of the communication API on the both sides (PC41 \item This \ST deals with the implementation of the communication API on the both sides (PC 42 42 part and FPGA-SoC). 43 43 \begin{livrable} 44 44 \item{}{12}{21}{x}{\Supmc}{HPC API for Linux PC} The PC part of the HPC communication API 45 that comminicate with the FPGA-SOC, a library and probably a LINUX module.45 that comminicates with the FPGA-SOC, a library and probably a LINUX module. 46 46 \item{}{12}{21}{x}{\Supmc}{HPC API for MUTEK OS} The FPGA-SoC part of the communication API, a 47 47 driver.\global\edef\hpcMutekDriver{\name} 48 48 \item{}{21}{24}{x}{\Stima}{HPC API for DNA OS} Port of the {\hpcMutekDriver} driver on the DNA OS. 49 49 \end{livrable} 50 \item This \ST aims with the implementation of hardware required by the COACH50 \item This \ST deals with the implementation of hardware required by the COACH 51 51 architectural template for using the PCI/X IP of \altera and \xilinx. 52 52 \begin{livrable} … … 56 56 \item{}{9}{18}{h}{\Saltera}{HPC hardware \altera} 57 57 \setMacroInAuxFile{hpcAvalonBridge} 58 The synthesizable VHDL description of a AVALON/VCI bridge and its corresponding SystemC model.58 The synthesizable VHDL description of an AVALON/VCI bridge and its corresponding SystemC model. 59 59 \end{livrable} 60 \item This \ST aims with the dynamic reconfiguration ofFPGA.60 \item This \ST deals with the dynamic reconfiguration of an FPGA. 61 61 \begin{livrable} 62 62 \item{}{18}{30}{x}{\Stima}{dynamic reconfiguration \ganttlf DNA drivers} -
anr/task-6.tex
r36 r40 11 11 % 12 12 \begin{workpackage}{D6} 13 \item This \ST is the reference demonstrator. It is a HPC application and so it covers13 \item This \ST is the reference demonstrator. It is an HPC application and so it covers 14 14 in addition to HPC (task-5) both the system genration (task-2), the HAS (task-3) and (task-4). 15 15 The reference demonstrator can be a Motion JPEG application, 16 or an application that draws in 3D (under open GL) a metor cloud attracted by a sun an17 planets,16 or an application that draws in 3D (under open GL) a simulation of a 17 metor cloud attracted by a sun and planets, 18 18 or a database management system. 19 19 \begin{livrable} … … 21 21 implementation as a PC C/C++ program. 22 22 \item{VF}{6}{12}{x}{\Supmc}{reference demonstrator} The demonstrator 23 split ed into 2 parts, a description as communicantetask graph of the FPGA-SoC part.23 split in two parts, a description as a communicating task graph of the FPGA-SoC part. 24 24 \end{livrable} 25 25 \end{workpackage}
Note: See TracChangeset
for help on using the changeset viewer.