Changeset 56
- Timestamp:
- Feb 1, 2010, 6:07:27 PM (15 years ago)
- Location:
- anr
- Files:
-
- 11 edited
Legend:
- Unmodified
- Added
- Removed
-
anr/anr.bib
r15 r56 4 4 @InProceedings{hpc06a, 5 5 author = {{M.B. Gokhale and al.}}, 6 title = {{Promises and Pitfalls of Reconfigurable }},6 title = {{Promises and Pitfalls of Reconfigurable Supercomputing}}, 7 7 booktitle = {Systems and Algorithms, CSREA Press}, 8 8 pages = {11-20}, … … 24 24 year = {2007}, 25 25 } 26 @misc{hpc08, 27 title = {Mitrionics}, 28 howpublished = {http://www.mitrionics.com/}, 29 year = {2009}, 30 } 31 @misc{hpc09, 32 title = {Gidel}, 33 howpublished = {http://www.gidel.com/}, 34 year = {2009}, 35 } 36 @misc{hpc10, 37 title = {Convey Computer}, 38 howpublished = {http://www.conveycomputers.com/}, 39 year = {2009}, 40 } 41 @InProceedings{hpc11, 42 author = {E. El-Araby, I. Gonzalez and T. El-Ghazawi}, 43 title = {Virtual Architecture and Design Automation for Partial Reconfiguration }, 44 booktitle = {HPRCTA}, 45 year = {2008}, 46 } 47 @InProceedings{hpc12, 48 author = {{P. Lysaght and J. Dunlop}}, 49 title = {Dynamic Reconfiguration of Field Programmable Gate Arrays}, 50 booktitle = {Field Programmable Logic and Applications, Oxford, England}, 51 month = {Sept}, 52 year = {1993}, 53 } 54 26 55 27 56 % System design -
anr/section-2.1.tex
r38 r56 95 95 to the elimination of huge hardware investment in opposite to ASIC based solution. 96 96 \\ 97 This new market may explode in the same way as the micro-computer ma tket in the eighties. This success was due97 This new market may explode in the same way as the micro-computer market in the eighties. This success was due 98 98 to the low cost of the first micro-processors (compared to main frames) and the advent of high level 99 99 programming languages which allowed a high number of programmers to launch start-ups in software -
anr/section-2.2.tex
r30 r56 6 6 providing the industry the novel design capabilities enabling them to increase their 7 7 design productivity with design exploration and synthesis methods that are placed on top 8 of the stat -of-theart methods, and thus, allowing the industry to better cope with the8 of the state-of-the-art methods, and thus, allowing the industry to better cope with the 9 9 complexity of designed digital systems. 10 10 \par -
anr/section-3.1.tex
r31 r56 1 % vim:set spell: 2 % vim:spell spelllang=en: 3 1 4 Our project covers several critical domains in system design in order 2 5 to achieve high performance computing. Starting from a high level description we aim … … 4 7 5 8 \subsubsection{High Performance Computing} 6 Accelerating high-performance computing (HPC) applications with field-programmable 7 gate arrays (FPGAs) can potentially improve performance. 9 % Un marché bouffé par les archi GPGPU tel que le FERMI de NvidiaCUDA programming language 10 High-Performance Computing (HPC) world is composed of three main families of architectures: 11 many-core, GPGPU (General Purpose computation on Graphics Unit Processing) and FPGA. 12 The two first families are dominating the market by taking benefit 13 of the strength and influence of mass-market leaders (Intel, Nvidia) 14 %such as Intel for many-core CPU and Nvidia for GPGPU. 15 In this market, FPGA architectures are emerging and very promising. 16 By adapting architecture to the software, % (the opposite is done in the others families) 17 FPGAs architectures enable better performance 18 (typically between x10 and x100 accelerations) 19 while using smaller size and less energy (and heat). 8 20 However, using FPGAs presents significant challenges~\cite{hpc06a}. 9 21 First, the operating frequency of an FPGA is low compared to a high-end microprocessor. 10 22 Second, based on Amdahl law, HPC/FPGA application performance is unusually sensitive 11 23 to the implementation quality~\cite{hpc06b}. 12 Finally, High-performance computing programmers are a highly sophisticated but scarce 13 resource. Such programmers are expected to readily use new technology but lack the time 14 to learn a completely new skill such as logic design~\cite{hpc07a} . 15 \\ 24 % Thus, the performance strongly relies on the detected parallelism. 25 % (pour résumer les 2 derniers points) 26 Finally, efficient design methodology are required in order to 27 hide FPGA complexity and the underlying implantation subtleties to HPC users, 28 so that they don't have to change their habits and can have equivalent design productivity 29 than in others families~\cite{hpc07a}. 30 31 %état de l'art FPGA 16 32 HPC/FPGA hardware is only now emerging and in early commercial stages, 17 33 but these techniques have not yet caught up. 34 Industrial (Mitrionics~\cite{hpc08}, Gidel~\cite{hpc09}, Convey Computer~\cite{hpc10}) and academic (CHREC) 35 researches on HPC-FPGA are mainly conducted in the USA. 36 None of the approaches developed in these researches are fulfilling entirely the 37 challenges described above. For example, Convey Computer proposes application-specific instruction set extension of x86 cores in FPGA accelerator, 38 but extension generation is not automated and requires hardware design skills. 39 Mitrionics has an elegant solution based on a compute engine specifically 40 developed for high-performance execution in FPGAs. Unfortunately, the design flow 41 is based on a new programming language (mitrionC) implying designer efforts and poor portability. 42 % tool relying on operator libraries (XtremeData), 43 % 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" ? 44 18 45 Thus, much effort is required to develop design tools that translate high level 19 46 language programs to FPGA configurations. 47 Moreover, as already remarked in~\cite{hpc11}, Dynamic Partial Reconfiguration~\cite{hpc12} 48 (DPR, which enables changing a part of the FPGA, while the rest is still working) 49 appears very interesting for improving HPC performance as well as reducing required area. 20 50 21 51 \subsubsection{System Synthesis} -
anr/section-3.2.tex
r33 r56 82 82 RTL IP cores (generic, ALTERA/NIOS/AVALON, XILINX/MICROBLAZE/OPB), 83 83 one design space exploration tool, 84 oneoperating system (OS).84 2 operating system (OS). 85 85 \\ 86 86 The framework fonctionality will be demonstrated with XXX-EXAMPLE1, XXX-EXAMPLE2 -
anr/section-4.1.tex
r46 r56 11 11 \caption{\label{archi-hpc} software architecture of HPC} 12 12 \end{figure} 13 %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 ? 13 14 % 14 15 Figures~\ref{archi-csg}, \ref{archi-hls} and \ref{archi-hpc} … … 17 18 has to provide. 18 19 \vspace*{.75ex}\par 19 For the system gen ration presented in figure~\ref{archi-csg}, the conductor20 For the system generation presented in figure~\ref{archi-csg}, the conductor 20 21 is the tool \verb!CSG! (COACH System Generator). Its inputs are a process 21 22 network describing the application to design and the synthesis parameters. … … 32 33 design space or as a bitstream\footnote{COACH generates synthesizable VHDL, and 33 34 launch the Xilinx or Altera RTL synthesis tools.} directly downloadable on the 34 FPGA device. 35 FPGA device\footnote{Additional partial bitstreams are generated in case of 36 dynamic partial reconfiguration}. 35 37 \\ 36 38 %To proove CSG that COACH is open and CSG is really configurable, COACH will … … 65 67 other running in a FPGA plugged on the PCI/X PC bus. The two parts exchange data 66 68 through communication primitives (tag 2) implemented in a library. 67 T o evaluate if the relevance of the partitioning, the designer can builda69 The relevance of the partitioning is evaluated through a 68 70 simulator. Once the partitioning is validated, the design of the FPGA part 69 71 is done through \verb!CSG! (figure~\ref{archi-csg}). 72 73 70 74 \vspace*{.75ex}\par 71 75 \mustbecompleted{FIXME == MODIFICATION DE LA FIGURE} … … 93 97 \item\textbf{Communication between PC \& FPGA-SoC:} 94 98 This task pools the features dedicated to HPC. The main are the 95 partitioning validation (see figure~\ref{archi-hpc}, the sytem drivers for 96 both PC and FPGA-SoC sides, the hardware communication components. 99 partitioning validation (see figure~\ref{archi-hpc}), the sytem drivers for 100 both PC and FPGA-SoC sides, the hardware communication components and 101 support for dynamic partial reconfiguration. 97 102 \item\textbf{Demonstrators:} 98 103 This task groups the demonstrators of the COACH project. -
anr/section-4.4.tex
r51 r56 47 47 supported. 48 48 The main restriction are: 49 1) The HAS tools are not yet optimum,50 2) dynamic reconfiguration is not supported,49 1) The HAS tools have not been yet enhanced, 50 2) dynamic partial reconfiguration is not supported, 51 51 3) \mustbecompleted{FIXME:ALL .....} 52 52 \item[Final Release ($T0+36$)] -
anr/task-1.tex
r52 r56 36 36 The base is the SRL library and the MWMR communication component defined by the SocLib 37 37 ANR project. 38 Nevertheless, these basic schemes will be enhanced to allow more effic ent38 Nevertheless, these basic schemes will be enhanced to allow more efficient 39 39 synthesis. 40 40 \itemL{6}{12}{d}{\Stima}{CSG user manual}{1:0:0} \setMacroInAuxFile{specCsgManual} -
anr/task-2.tex
r52 r56 14 14 \item the development of all the missing components (SytemC model and/or synthesizable VHDL description), 15 15 \item the configuration and the development of drivers of the operating systems, 16 \item the CSG software that generates the simulators for protot iping and the FPGA-SoC system,16 \item the CSG software that generates the simulators for prototyping and the FPGA-SoC system, 17 17 \item the specification of enhanced communication schemes and their sofware and hardware implementation. 18 18 \end{itemize} … … 106 106 Maintenance work. 107 107 \itemL{6}{18}{x}{\Stima}{Port of DNA OS}{0:0:0} 108 Port of MUTEKOS on the NIOS2 and MICROBLAZE processors.108 Port of DNA OS on the NIOS2 and MICROBLAZE processors. 109 109 \end{livrable} 110 110 \end{workpackage} -
anr/task-4.tex
r52 r56 6 6 % 7 7 \begin{objectif} 8 The objectives of this task are to provide the 2HAS back-ends of the COACH project and8 The objectives of this task are to provide the two HAS back-ends of the COACH project and 9 9 a tool that adapt the coprocessor frequency to the FPGA-SoC frequency as given 10 10 by the processors and the BUS. … … 16 16 being generated by \novers{\specXcoachToCA} deliverable and \xcoachplus being treated by 17 17 \novers{\specXcoachToSystemC} and \novers{\specXcoachToVhdl} deliverables, 18 this task is very dependen on task~1.18 this task is very dependent on task~1. 19 19 \par 20 20 For the two HAS front-end, this task is based on the already existing HLS tools GAUT and … … 29 29 \begin{workpackage} 30 30 \item The goal of this \ST is to integrate the UGH HLS tool to the COACH framework. It 31 consists of suppressing the C com mpiler and the SystemC and VHDL drivers and replacing31 consists of suppressing the C compiler and the SystemC and VHDL drivers and replacing 32 32 them by \xcoach and \xcoachplus drivers. 33 33 \begin{livrable} -
anr/task-5.tex
r52 r56 1 % vim:set spell: 2 % vim:spell spelllang=en: 3 1 4 \begin{taskinfo} 2 5 \let\UPMC\leader … … 10 13 \begin{itemize} 11 14 \item Helping the HPC designer to find a good partition of the initial application 12 (figure~\ref{archi-hpc} .13 \item Providing communication schemes between the software part run ing on the PC and the15 (figure~\ref{archi-hpc}). 16 \item Providing communication schemes between the software part running on the PC and the 14 17 FPGA-SoC. 15 18 \item Implementing the communication scheme at all levels: partition help, software 16 19 implementation both on the PC and in the operating system of the FPGA-SoC, hardware. 17 \item FPGA reconfiguration. \mustbecompleted{FIXME:TIMA}20 \item Providing support for dynamic partial reconfiguration of \xilinx FPGA in order to optimize FPGA ressource usage. 18 21 \end{itemize} 22 19 23 The low level hardware transmission support will be the PCI/X bus which allows high bit-rate 20 24 transfers. The reasons of this choices are that both ALTERA and Xilinx provide PCI/X IP for … … 22 26 This will allow us at least to be inspired by GPU communication schemes and may be to reuse 23 27 parts of the GPU softwares. 28 29 24 30 \end{objectif} 25 31 % … … 31 37 \itemL{0}{6}{d}{\Supmc}{HPC communication API}{1.0:0:0} 32 38 \setMacroInAuxFile{hpcCommApi} 33 User refer nce manual describing the API.39 User reference manual describing the API. 34 40 \end{livrable} 35 \item This \ST consists in helping to partition the application.41 \item This \ST consists in helping to partition applications. 36 42 It is a library implementing the communication API with features to profile 37 43 the partitioned application. 44 %FIXME (Olivier) pour moi, on veut un outil de profiling pour partitionner l'application. 45 % It is a profiling (or simulation) library implementing the communication API 46 38 47 \begin{livrable} 39 48 \itemL{6}{12}{x}{\Supmc}{HPC partionning helper}{1:0:0} … … 52 61 Port of the {\hpcMutekDriver} driver on the DNA OS. 53 62 \itemL{24}{33}{x}{\Supmc}{HPC API}{0:0:1} 54 Maintenance work of HPC API for both L unix PC and MUTEK OS.63 Maintenance work of HPC API for both Linux PC and MUTEK OS. 55 64 \end{livrable} 56 65 \item This \ST deals with the implementation of hardware required by the COACH … … 64 73 The synthesizable VHDL description of an AVALON/VCI bridge and its corresponding SystemC model. 65 74 \end{livrable} 66 \item This \ST deals with the dynamic reconfiguration of an FPGA. 75 \item This \ST consists in integrating dynamic partial reconfiguration of \xilinx FPGA in the CSG design flow. 76 It also includes appropriate SoC-FPGA OS drivers and a modification of the profiling library. 77 67 78 \begin{livrable} 79 \itemL{18}{36}{x}{\Supmc}{CSG support for \ganttlf dynamic reconfiguration} 80 Extension of the \xilinx architectural template ({\csgAllArch}) 81 in order to integrate dynamic partial reconfiguration regions. 82 Modification of CSG software to support the extended \xilinx template. 68 83 \itemL{18}{30}{x}{\Stima}{dynamic reconfiguration \ganttlf DNA drivers}{0:0:0} 69 84 \setMacroInAuxFile{hpcDynconfDriver} 70 \mustbecompleted{FIXME:TIMA ....} 85 The drivers required by the DNA OS in order to manage dynamic partial reconfiguration inside the SoC-FPGA. 71 86 \itemL{30}{36}{x}{\Supmc}{dynamic reconfiguration \ganttlf MUTEK drivers}{0:0:1} 72 Port of the {\hpcDynconfDriver} \mustbecompleted{FIXME:TIMA driver} on the MUTEK OS. 73 \itemL{24}{36}{x}{\Supmc}{CSG support for \ganttlf dynamic reconfiguration}{0:0:2} 74 \mustbecompleted{FIXME:TIMA ....} 75 \itemL{18}{36}{x}{\Stima}{PC support for \ganttlf dynamic reconfiguration}{0:0:0} 76 \mustbecompleted{FIXME:TIMA ....} 77 \end{livrable} 87 Port of the {\hpcDynconfDriver} drivers on the MUTEK OS. 88 \itemL{18}{36}{x}{\Stima}{HPC support for \ganttlf dynamic reconfiguration}{0:0:2} 89 Extension of the HPC partionning helper in order to integrate dynamic partial reconfiguration dedicated features 90 (reconfiguration time of regions, variable number of coprocessors) 91 \end{livrable} 78 92 \item This \ST is the delivery of 2 PCI/X \mustbecompleted{FIXME: Stratix4} FPGA board 79 93 with its PCI/X IP. These boards are dedicated to the COACH HPC development.
Note: See TracChangeset
for help on using the changeset viewer.