source: anr/section-3.1.tex @ 172

Last change on this file since 172 was 134, checked in by coach, 15 years ago

IA: fixed mutek, altera, xilinx, and neutal architectural template

File size: 14.7 KB
Line 
1% vim:set spell:
2% vim:spell spelllang=en:
3
4Our project covers several critical domains in system design in order
5to achieve high performance computing. Starting from a high level description we aim
6at generating automatically both hardware and software components of the system.
7
8\subsubsection{High Performance Computing}
9% Un marché bouffé par les archi GPGPU tel que le FERMI de NvidiaCUDA programming language
10High-Performance Computing (HPC) world is composed of three main families of architectures:
11many-core, GPGPU (General Purpose computation on Graphics Unit Processing) and FPGA.
12The two first families are dominating the market by taking benefit
13of the strength and influence of mass-market leaders (Intel, Nvidia).
14%such as Intel for many-core CPU and Nvidia for GPGPU.
15In this market, FPGA architectures are emerging and very promising.
16By adapting architecture to the software, % (the opposite is done in the others families)
17FPGAs architectures enable better performance
18(typically between x10 and x100 accelerations)
19while using smaller size and less energy (and heat).
20However, using FPGAs presents significant challenges~\cite{hpc06a}.
21First, the operating frequency of an FPGA is low compared to a high-end microprocessor.
22Second, based on Amdahl law,  HPC/FPGA application performance is unusually sensitive
23to the implementation quality~\cite{hpc06b}.
24% Thus, the performance strongly relies on the detected parallelism.
25% (pour résumer les 2 derniers points)
26Finally, efficient design methodology are required in order to
27hide FPGA complexity and the underlying implantation subtleties to HPC users,
28so that they don't have to change their habits and can have equivalent design productivity
29than in others families~\cite{hpc07a}.
30
31%état de l'art FPGA
32HPC/FPGA hardware is only now emerging and in early commercial stages,
33but these techniques have not yet caught up.
34Industrial (Mitrionics~\cite{hpc08}, Gidel~\cite{hpc09}, Convey Computer~\cite{hpc10}) and academic (CHREC)
35researches on HPC-FPGA are mainly conducted in the USA.
36None of the approaches developed in these researches are fulfilling entirely the
37challenges described above. For example, Convey Computer proposes application-specific instruction set extension of x86 cores in FPGA accelerator,
38but extension generation is not automated and requires hardware design skills.
39Mitrionics has an elegant solution based on a compute engine specifically
40developed for high-performance execution in FPGAs. Unfortunately, the design flow
41is 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
45Thus, much effort is required to develop design tools that translate high level
46language programs to FPGA configurations.
47Moreover, 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)
49appears very interesting for improving HPC performance as well as reducing required area.
50
51\subsubsection{System Synthesis}
52Today, several solutions for system design are proposed and commercialized.
53The existing commercial or free tools does not
54cover the whole system synthesis process in a full automatic way. Moreover,
55they are bound to a particular device family and to IPs library.
56The most commonly used are provided by \altera and \xilinx to promote their
57FPGA devices. These two representative tools used to synthesize SoC on FPGA
58are introduced below.
59\\
60The \xilinx System Generator for DSP~\cite{system-generateur-for-dsp} is a
61plug-in to Simulink that enables designers to develop high-performance DSP
62systems for \xilinx FPGAs.
63Designers can design and simulate a system using MATLAB and Simulink. The
64tool will then automatically generate synthesizable Hardware Description
65Language (HDL) code mapped to \xilinx pre-optimized algorithms.
66However, this tool targets only DSP based algorithms, \xilinx FPGAs and
67cannot handle a complete SoC. Thus, it is not really a system synthesis tool.
68\\
69In the opposite, SOPC Builder~\cite{spoc-builder} allows to describe a
70system, to synthesis it, to programm it into a target FPGA and to upload a
71software application.
72% FIXME(C2H from \altera, marche vite mais ressource monstrueuse)
73Nevertheless, SOPC Builder does not provide any facilities to synthesize
74coprocessors. System Designer must provide the synthesizable description
75with the feasible bus interface. Design Space Exploration is thus limited
76and SystemC simulation is not possible neither at transactional nor at Cycle
77accurate level.
78\\
79In addition, \xilinx System Generator and SOPC Builder are closed world
80since each one imposes their own IPs which are not interchangeable.
81
82\subsubsection{High Level Synthesis}
83High Level Synthesis translates a sequential algorithmic description and a
84set of constraints (area, power, frequency, ...) to a micro-architecture at
85Register Transfer Level (RTL).
86Several academic and commercial tools are today available. Most common
87tools are SPARK~\cite{spark04}, GAUT~\cite{gaut08}, UGH~\cite{ugh08} in the
88academic world and CATAPULTC~\cite{catapult-c}, PICO~\cite{pico} and
89CYNTHETIZER~\cite{cynthetizer} in commercial world.  Despite their
90maturity, their usage is restrained by:
91\begin{itemize}
92\item The HLS tools are not integrated into an architecture and system exploration tool.
93Thus, a designer who needs to accelerate a software part of the system, must adapt it manually
94to the HLS input dialect and performs engineering work to exploit the synthesis result
95at the system level.
96\item HLS tools take into account only one or few constraints simultaneously while realistic
97designs are multi-constrained.
98Moreover, low power consumption constraint is mandatory for embedded systems.
99However, it is not yet well handled or not handle at all by the synthesis tools already available.
100\item The parallelism is extracted from initial algorithmic specification.
101To get more parallelism or to reduce the amount of required memory in the SoC, the user
102must re-write the algorithmic specification while there is techniques as polyedric
103transformations to increase the intrinsic parallelism.
104\item While they support limited loop transformations like loop unrolling and loop
105pipelining, current HLS tools do not provide support for design space exploration neither
106through automatic loop transformations nor through memory mapping.
107\item Despite they have the same input language (C/C++), they are sensitive to the style in
108which the algorithm is written. Consequently, engineering work is required to swap from
109a tool to another.
110\item They do not respect accurately the frequency constraint when they target an FPGA device.
111Their error is about 10 percent. This is annoying when the generated component is integrated
112in a SoC since it will slow down the hole system.
113\end{itemize}
114Regarding these limitations, it is necessary to create a new tool generation reducing the gap
115between the specification of an heterogeneous system and its hardware implementation.
116\mustbecompleted {FIXME :: Ajouter ref livre + D\&T}
117
118\subsubsection{Application Specific Instruction Processors}
119
120ASIP (Application-Specific Instruction-Set Processor) are programmable
121processors in which both the instruction and the micro architecture have
122been tailored to a given application domain (e.g. video processing), or to a
123specific application.  This specialization usually offers a good compromise
124between performance (w.r.t a pure software implementation on an embedded
125CPU) and flexibility (w.r.t an application specific hardware co-processor).
126In spite of their obvious advantages, using/designing ASIPs remains a
127difficult task, since it involves designing both a micro-architecture and a
128compiler for this architecture. Besides, to our knowledge, there is still
129no available open-source design flow for ASIP design even if such a tool
130 would be valuable in the
131context of a System Level design exploration tool.
132\par
133In this context, ASIP design based on Instruction Set Extensions (ISEs) has
134received a lot of interest~\cite{NIOS2}, as it makes micro architecture synthesis
135more tractable \footnote{ISEs rely on a template micro-architecture in which
136only a small fraction of the architecture has to be specialized}, and help ASIP
137designers to focus on compilers, for which there are still many open
138problems\cite{ARC08}.
139This approach however has a strong weakness, since it also significantly reduces
140opportunities for achieving good seedups (most speedup remain between 1.5x and
1412.5x), since ISEs performance is generally tied down by I/O constraints as
142they 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}). 
148To cope with this issue, recent approaches~\cite{DAC09,CODES08,TVLSI06} advocate the use of
149micro-architectural ISE models in which the coupling between the processor micro-architecture
150and the ISE component is thightened up so as to allow the ISE to overcome the register
151I/O limitations, however these approaches generally tackle the problem for a compiler/simulation
152point of view and not address the problem of generating synthesizable representations for
153these models.
154
155We therefore strongly believe that there is a need for an open-framework which
156would allow researchers and system designers to :
157\begin{itemize}
158\item Explore the various level of interactions between the original CPU micro-architecure
159and its extension (for example throught a Domain Specific Language targeted at micro-architecture
160specification and synthesis).
161\item Retarget the compiler instruction-selection (or prototype nex passes) passes so as
162to be able to take advantage of this ISEs.
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}
168% FIXME:LIP FIXME:PF FIXME:CA
169% Paul je ne suis pas sur que ce soit vraiment un etat de l'art
170% Christophe, ce que tu m'avais envoye se trouve dans obsolete/body.tex
171%\mustbecompleted{
172%Hardware is inherently parallel. On the other hand, high level languages,
173%like C or Fortran, are abstractions of the processors of the 1970s, and
174%hence are sequential. One of the aims of an HLS tool is therefore to
175%extract hidden parallelism from the source program, and to infer enough
176%hardware operators for its efficient exploitation.
177%\\
178%Present day HLS tools search for parallelism in linear pieces of code
179%acting only on scalars -- the so-called basic blocs. On the other hand,
180%it is well known that most programs, especially in the fields of signal
181%processing and image processing, spend most of their time executing loops
182%acting on arrays. Efficient use of the large amount of hardware available
183%in the next generation of FPGA chips necessitates parallelism far beyond
184%what can be extracted from basic blocs only.
185
186%The Compsys team of LIP has built an automatic parallelizer, Syntol, which
187%handle restricted C programs -- the well known polyhedral model --,
188%computes dependences and build a symbolic schedule. The schedule is
189%a specification for a parallel program. The parallelism itself can be
190%expressed in several ways: as a system of threads, or as data-parallel
191%operations, or as a pipeline. In the context of the COACH project, one
192%of the task will be to decide which form of parallelism is best suited
193%to hardware, and how to convey the results of Syntol to the actual
194%synthesis tools. One of the advantages of this approach is that the
195%resulting degree of parallelism can be easilly controlled, e.g. by
196%adjusting the number of threads, as a mean of exploring the
197%area / performance tradeoff of the resulting design.
198
199%Another point is that potentially parallel programs necessarily involve
200%arrays: two operations which write to the same location must be executed
201%in sequence. In synthesis, arrays translate to memory. However, in FPGAs,
202%the amount of on-chip memory is limited, and access to an external memory
203%has a high time penalty. Hence the importance of reducing the size of
204%temporary arrays to the minimum necessary to support the requested degree
205%of parallelism. Compsys has developped a stand-alone tool, Bee, based
206%on research by A. Darte, F. Baray and C. Alias, which can be extended
207%into a memory optimizer for COACH.
208%}
209
210The problem of compiling sequential programs for parallel computers
211has been studied since the advent of the first parallel architectures
212in the 1970s. The basic approach consists in applying program transformations
213which exhibit or increase the potential parallelism, while guaranteeing
214the preservation of the program semantics. Most of these transformations
215just reorder the operations of the program; some of them modify its
216data structures. Dpendences (exact or conservative) are checked to guarantee
217the legality of the transformation.
218
219This has lead to the invention of many loop transformations (loop fusion,
220loop splitting, loop skewing, loop interchange, loop unrolling, ...)
221which interact in a complicated way. More recently, it has been noticed
222that all of these are just changes of basis in the iteration domain of
223the program. This has lead to the invention of the polyhedral model, in
224which the combination of two transformation is simply a matrix product.
225
226As a side effect, it has been observed that the polytope model is a useful
227tool for many other optimization, like memory reduction and locality
228improvement. Another point is
229that the polyhedral domain \emph{stricto sensu} applies only to
230very regular programs. Its extension to more general programs is
231an active research subject.
232
233%\subsubsection{High Performance Computing}
234%Accelerating high-performance computing (HPC) applications with field-programmable
235%gate arrays (FPGAs) can potentially improve performance.
236%However, using FPGAs presents significant challenges~\cite{hpc06a}.
237%First, the operating frequency of an FPGA is low compared to a high-end microprocessor.
238%Second, based on Amdahl law,  HPC/FPGA application performance is unusually sensitive
239%to the implementation quality~\cite{hpc06b}.
240%Finally, High-performance computing programmers are a highly sophisticated but scarce
241%resource. Such programmers are expected to readily use new technology but lack the time
242%to learn a completely new skill such as logic design~\cite{hpc07a} .
243%\\
244%HPC/FPGA hardware is only now emerging and in early commercial stages,
245%but these techniques have not yet caught up.
246%Thus, much effort is required to develop design tools that translate high level
247%language programs to FPGA configurations.
248
Note: See TracBrowser for help on using the repository browser.