[56] | 1 | % vim:set spell: |
---|
| 2 | % vim:spell spelllang=en: |
---|
| 3 | |
---|
[12] | 4 | Our project covers several critical domains in system design in order |
---|
| 5 | to achieve high performance computing. Starting from a high level description we aim |
---|
| 6 | at generating automatically both hardware and software components of the system. |
---|
| 7 | |
---|
| 8 | \subsubsection{High Performance Computing} |
---|
[56] | 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 |
---|
[66] | 13 | of the strength and influence of mass-market leaders (Intel, Nvidia). |
---|
[56] | 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). |
---|
[12] | 20 | However, using FPGAs presents significant challenges~\cite{hpc06a}. |
---|
| 21 | First, the operating frequency of an FPGA is low compared to a high-end microprocessor. |
---|
| 22 | Second, based on Amdahl law, HPC/FPGA application performance is unusually sensitive |
---|
| 23 | to the implementation quality~\cite{hpc06b}. |
---|
[56] | 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, |
---|
[180] | 28 | so that they do not have to change their habits and can have equivalent design productivity |
---|
[56] | 29 | than in others families~\cite{hpc07a}. |
---|
| 30 | |
---|
| 31 | %état de l'art FPGA |
---|
[12] | 32 | HPC/FPGA hardware is only now emerging and in early commercial stages, |
---|
| 33 | but these techniques have not yet caught up. |
---|
[56] | 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 |
---|
[180] | 41 | is based on a new programming language (mitrionC) implying important designer efforts and poor portability. |
---|
[56] | 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 | |
---|
[12] | 45 | Thus, much effort is required to develop design tools that translate high level |
---|
| 46 | language programs to FPGA configurations. |
---|
[56] | 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. |
---|
[12] | 50 | |
---|
| 51 | \subsubsection{System Synthesis} |
---|
| 52 | Today, several solutions for system design are proposed and commercialized. |
---|
[103] | 53 | The existing commercial or free tools does not |
---|
| 54 | cover the whole system synthesis process in a full automatic way. Moreover, |
---|
| 55 | they are bound to a particular device family and to IPs library. |
---|
[134] | 56 | The most commonly used are provided by \altera and \xilinx to promote their |
---|
[103] | 57 | FPGA devices. These two representative tools used to synthesize SoC on FPGA |
---|
| 58 | are introduced below. |
---|
[12] | 59 | \\ |
---|
[134] | 60 | The \xilinx System Generator for DSP~\cite{system-generateur-for-dsp} is a |
---|
[12] | 61 | plug-in to Simulink that enables designers to develop high-performance DSP |
---|
[134] | 62 | systems for \xilinx FPGAs. |
---|
[12] | 63 | Designers can design and simulate a system using MATLAB and Simulink. The |
---|
| 64 | tool will then automatically generate synthesizable Hardware Description |
---|
[134] | 65 | Language (HDL) code mapped to \xilinx pre-optimized algorithms. |
---|
| 66 | However, this tool targets only DSP based algorithms, \xilinx FPGAs and |
---|
[103] | 67 | cannot handle a complete SoC. Thus, it is not really a system synthesis tool. |
---|
[12] | 68 | \\ |
---|
| 69 | In the opposite, SOPC Builder~\cite{spoc-builder} allows to describe a |
---|
| 70 | system, to synthesis it, to programm it into a target FPGA and to upload a |
---|
| 71 | software application. |
---|
[134] | 72 | % FIXME(C2H from \altera, marche vite mais ressource monstrueuse) |
---|
[12] | 73 | Nevertheless, SOPC Builder does not provide any facilities to synthesize |
---|
| 74 | coprocessors. System Designer must provide the synthesizable description |
---|
[103] | 75 | with the feasible bus interface. Design Space Exploration is thus limited |
---|
[180] | 76 | and SystemC simulation is not possible neither at transactional nor at cycle |
---|
[103] | 77 | accurate level. |
---|
[12] | 78 | \\ |
---|
[134] | 79 | In addition, \xilinx System Generator and SOPC Builder are closed world |
---|
[12] | 80 | since each one imposes their own IPs which are not interchangeable. |
---|
| 81 | |
---|
| 82 | \subsubsection{High Level Synthesis} |
---|
| 83 | High Level Synthesis translates a sequential algorithmic description and a |
---|
[66] | 84 | set of constraints (area, power, frequency, ...) to a micro-architecture at |
---|
[12] | 85 | Register Transfer Level (RTL). |
---|
| 86 | Several academic and commercial tools are today available. Most common |
---|
| 87 | tools are SPARK~\cite{spark04}, GAUT~\cite{gaut08}, UGH~\cite{ugh08} in the |
---|
| 88 | academic world and CATAPULTC~\cite{catapult-c}, PICO~\cite{pico} and |
---|
| 89 | CYNTHETIZER~\cite{cynthetizer} in commercial world. Despite their |
---|
[180] | 90 | maturity, their usage is restrained by \cite{IEEEDT} \cite{CATRENE} \cite{HLSBOOK}: |
---|
[12] | 91 | \begin{itemize} |
---|
[103] | 92 | \item The HLS tools are not integrated into an architecture and system exploration tool. |
---|
| 93 | Thus, a designer who needs to accelerate a software part of the system, must adapt it manually |
---|
| 94 | to the HLS input dialect and performs engineering work to exploit the synthesis result |
---|
[180] | 95 | at the system level, |
---|
[181] | 96 | \item Current HLS tools can not target control AND data oriented applications, |
---|
[103] | 97 | \item HLS tools take into account only one or few constraints simultaneously while realistic |
---|
[180] | 98 | designs are multi-constrained, |
---|
[12] | 99 | Moreover, low power consumption constraint is mandatory for embedded systems. |
---|
[180] | 100 | However, it is not yet well handled or not handle at all by the synthesis tools already available, |
---|
| 101 | \item The parallelism is extracted from initial algorithmic specification, |
---|
[134] | 102 | To get more parallelism or to reduce the amount of required memory in the SoC, the user |
---|
| 103 | must re-write the algorithmic specification while there is techniques as polyedric |
---|
[180] | 104 | transformations to increase the intrinsic parallelism, |
---|
[134] | 105 | \item While they support limited loop transformations like loop unrolling and loop |
---|
| 106 | pipelining, current HLS tools do not provide support for design space exploration neither |
---|
[180] | 107 | through automatic loop transformations nor through memory mapping, |
---|
[12] | 108 | \item Despite they have the same input language (C/C++), they are sensitive to the style in |
---|
| 109 | which the algorithm is written. Consequently, engineering work is required to swap from |
---|
[180] | 110 | a tool to another, |
---|
[103] | 111 | \item They do not respect accurately the frequency constraint when they target an FPGA device. |
---|
| 112 | Their error is about 10 percent. This is annoying when the generated component is integrated |
---|
| 113 | in a SoC since it will slow down the hole system. |
---|
[12] | 114 | \end{itemize} |
---|
| 115 | Regarding these limitations, it is necessary to create a new tool generation reducing the gap |
---|
[180] | 116 | between the specification of an heterogeneous system and its hardware implementation \cite{HLSBOOK} \cite{IEEEDT}. |
---|
[12] | 117 | |
---|
| 118 | \subsubsection{Application Specific Instruction Processors} |
---|
| 119 | |
---|
| 120 | ASIP (Application-Specific Instruction-Set Processor) are programmable |
---|
| 121 | processors in which both the instruction and the micro architecture have |
---|
[103] | 122 | been tailored to a given application domain (e.g. video processing), or to a |
---|
[12] | 123 | specific application. This specialization usually offers a good compromise |
---|
[103] | 124 | between performance (w.r.t a pure software implementation on an embedded |
---|
[12] | 125 | CPU) and flexibility (w.r.t an application specific hardware co-processor). |
---|
| 126 | In spite of their obvious advantages, using/designing ASIPs remains a |
---|
| 127 | difficult task, since it involves designing both a micro-architecture and a |
---|
| 128 | compiler for this architecture. Besides, to our knowledge, there is still |
---|
[93] | 129 | no available open-source design flow for ASIP design even if such a tool |
---|
| 130 | would be valuable in the |
---|
[12] | 131 | context of a System Level design exploration tool. |
---|
| 132 | \par |
---|
| 133 | In this context, ASIP design based on Instruction Set Extensions (ISEs) has |
---|
[120] | 134 | received a lot of interest~\cite{NIOS2}, as it makes micro architecture synthesis |
---|
[12] | 135 | more tractable \footnote{ISEs rely on a template micro-architecture in which |
---|
| 136 | only a small fraction of the architecture has to be specialized}, and help ASIP |
---|
| 137 | designers to focus on compilers, for which there are still many open |
---|
[93] | 138 | problems\cite{ARC08}. |
---|
[198] | 139 | This approach however has a severe weakness, since it also significantly reduces |
---|
| 140 | opportunities for achieving good speedups (most speedups remain between 1.5x and |
---|
[12] | 141 | 2.5x), since ISEs performance is generally tied down by I/O constraints as |
---|
| 142 | they generally rely on the main CPU register file to access data. |
---|
| 143 | |
---|
| 144 | % ( |
---|
| 145 | %automaticcaly extraction ISE candidates for application code \cite{CODES04}, |
---|
| 146 | %performing efficient instruction selection and/or storage resource (register) |
---|
| 147 | %allocation \cite{FPGA08}). |
---|
[93] | 148 | To cope with this issue, recent approaches~\cite{DAC09,CODES08,TVLSI06} advocate the use of |
---|
[12] | 149 | micro-architectural ISE models in which the coupling between the processor micro-architecture |
---|
[198] | 150 | and the ISE component is tightened up so as to allow the ISE to overcome the register |
---|
| 151 | I/O limitations. However these approaches generally tackle the problem from a compiler/simulation |
---|
| 152 | point of view and do not address the problem of generating synthesizable representations for |
---|
[12] | 153 | these models. |
---|
| 154 | |
---|
| 155 | We therefore strongly believe that there is a need for an open-framework which |
---|
| 156 | would allow researchers and system designers to : |
---|
| 157 | \begin{itemize} |
---|
[180] | 158 | \item Explore the various level of interactions between the original CPU micro-architecture |
---|
| 159 | and its extension (for example through a Domain Specific Language targeted at micro-architecture |
---|
[12] | 160 | specification and synthesis). |
---|
[198] | 161 | \item Retarget the compiler instruction-selection pass |
---|
| 162 | (or prototype new passes) so as to be able to take advantage of this ISEs. |
---|
[12] | 163 | \item Provide a complete System-level Integration for using ASIP as SoC building blocks |
---|
| 164 | (integration with application specific blocks, MPSoc, etc.) |
---|
| 165 | \end{itemize} |
---|
| 166 | |
---|
| 167 | \subsubsection{Automatic Parallelization} |
---|
[31] | 168 | |
---|
[30] | 169 | The problem of compiling sequential programs for parallel computers |
---|
| 170 | has been studied since the advent of the first parallel architectures |
---|
| 171 | in the 1970s. The basic approach consists in applying program transformations |
---|
| 172 | which exhibit or increase the potential parallelism, while guaranteeing |
---|
| 173 | the preservation of the program semantics. Most of these transformations |
---|
| 174 | just reorder the operations of the program; some of them modify its |
---|
[174] | 175 | data structures. Dependences (exact or conservative) are checked to guarantee |
---|
[30] | 176 | the legality of the transformation. |
---|
| 177 | |
---|
| 178 | This has lead to the invention of many loop transformations (loop fusion, |
---|
| 179 | loop splitting, loop skewing, loop interchange, loop unrolling, ...) |
---|
| 180 | which interact in a complicated way. More recently, it has been noticed |
---|
| 181 | that all of these are just changes of basis in the iteration domain of |
---|
[174] | 182 | the program. This has lead to the introduction of the polyhedral model, |
---|
| 183 | \cite{FP:96,DRV:2000} in which the combination of two transformation is |
---|
| 184 | simply a matrix product. |
---|
[30] | 185 | |
---|
[174] | 186 | Since hardware is inherently parallel, finding parallelism in sequential |
---|
| 187 | programs in an important prerequisite for HLS. The large FPGA chips of |
---|
| 188 | today can accomodate much more parallelism than is available in basic blocks. |
---|
| 189 | The polyhedral model is the ideal tool for finding more parallelism in |
---|
| 190 | loops. |
---|
| 191 | |
---|
| 192 | As a side effect, it has been observed that the polyhedral model is a useful |
---|
[30] | 193 | tool for many other optimization, like memory reduction and locality |
---|
| 194 | improvement. Another point is |
---|
| 195 | that the polyhedral domain \emph{stricto sensu} applies only to |
---|
| 196 | very regular programs. Its extension to more general programs is |
---|
| 197 | an active research subject. |
---|
| 198 | |
---|
[66] | 199 | %\subsubsection{High Performance Computing} |
---|
| 200 | %Accelerating high-performance computing (HPC) applications with field-programmable |
---|
| 201 | %gate arrays (FPGAs) can potentially improve performance. |
---|
| 202 | %However, using FPGAs presents significant challenges~\cite{hpc06a}. |
---|
| 203 | %First, the operating frequency of an FPGA is low compared to a high-end microprocessor. |
---|
| 204 | %Second, based on Amdahl law, HPC/FPGA application performance is unusually sensitive |
---|
| 205 | %to the implementation quality~\cite{hpc06b}. |
---|
| 206 | %Finally, High-performance computing programmers are a highly sophisticated but scarce |
---|
| 207 | %resource. Such programmers are expected to readily use new technology but lack the time |
---|
| 208 | %to learn a completely new skill such as logic design~\cite{hpc07a} . |
---|
| 209 | %\\ |
---|
| 210 | %HPC/FPGA hardware is only now emerging and in early commercial stages, |
---|
| 211 | %but these techniques have not yet caught up. |
---|
| 212 | %Thus, much effort is required to develop design tools that translate high level |
---|
| 213 | %language programs to FPGA configurations. |
---|
[12] | 214 | |
---|