source: anr-2010/section-3.1.tex @ 385

Last change on this file since 385 was 252, checked in by coach, 15 years ago

UBS

File size: 13.8 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
10The High-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 first  two 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 do not 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 important 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 do 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 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} from \altera and \xilinx 
70Platform Studio XPS from \xilinx allows to describe a system, to synthesis it,
71to program it into a target FPGA and to upload a software application.
72Both SOPC Builder and XPS, allow designers to select and parameterize components from
73an extensive drop-down list of IP cores (I/O core, DSP, processor,  bus core, ...)
74as well as incorporate their own IP. Nevertheless, all the previously introduced tools
75do not provide any facilities to synthesize coprocessors and to simulate the platform
76at a high level (SystemC).
77System designer must provide the synthesizable description of its own IP-cores with
78the feasible bus interface. Design Space Exploration is thus limited
79and SystemC simulation is not possible neither at transactional nor at cycle
80accurate level.
81\\
82In addition, \xilinx System Generator, XPS and SOPC Builder are closed world
83since each one imposes their own IPs which are not interchangeable.
84Designers can then only generate a synthesized netlist, VHDL/Verilog simulation test
85bench and custom software library that reflect the hardware configuration.
86
87Consequently, a designer developing an embedded system needs to master four different
88design environments:
89\begin{enumerate}
90  \item a virtual prototyping environment (in SystemC) for system level exploration,
91  \item an architecture compiler to define the hardware architecture (Verilog/VHDL),
92  \item one or several third-party HLS tools for coprocessor synthesis (C to RTL),
93  \item and finally back-end synthesis tools for the bit-stream generation (RTL to bitstream).
94\end{enumerate}
95Furthermore, mixing these tools requires an important interfacing effort and this makes
96the design process very complex and achievable only by designers skilled in many domains.
97
98\subsubsection{High Level Synthesis}
99High Level Synthesis translates a sequential algorithmic description and a
100set of constraints (area, power, frequency, ...) to a micro-architecture at
101Register Transfer Level (RTL).
102Several academic and commercial tools are today available. The most common
103tools are SPARK~\cite{spark04}, GAUT~\cite{gaut08}, UGH~\cite{ugh08} in the
104academic world and CATAPULTC~\cite{catapult-c}, PICO~\cite{pico} and
105CYNTHETIZER~\cite{cynthetizer} in the commercial world.  Despite their
106maturity, their usage is restrained by \cite{IEEEDT} \cite{CATRENE} \cite{HLSBOOK}:
107\begin{itemize}
108\item HLS tools are not integrated into an architecture and system exploration tool.
109Thus, a designer who needs to accelerate a software part of the system, must adapt it manually
110to the HLS input dialect and perform engineering work to exploit the synthesis result
111at the system level,
112\item Current HLS tools can not target control AND data oriented applications,
113\item HLS tools take into account mainly a unique constraint while realistic design
114is multi-constrained.
115Low power consumption constraint which is mandatory for embedded systems is not yet
116well handled or not handled at all by the HLS tools already available,
117\item The parallelism is extracted from initial specification.
118To get more parallelism or to reduce the amount of required memory in the SoC, the user
119must re-write the algorithmic specification while there is techniques such as polyedric
120transformations to increase the intrinsic parallelism,
121\item While they support limited loop transformations like loop unrolling and loop
122pipelining, current HLS tools do not provide support for design space exploration neither
123through automatic loop transformations nor through memory mapping,
124\item Despite having the same input language (C/C++), they are sensitive to the style in
125which the algorithm dis written. Consequently, engineering work is required to swap from
126a tool to another,
127\item They do not respect accurately the frequency constraint when they target an FPGA device.
128Their error is about 10 percent. This is annoying when the generated component is integrated
129in a SoC since it will slow down the whole system.
130\end{itemize}
131Regarding these limitations, it is necessary to create a new tool generation reducing the gap
132between the specification of an heterogeneous system and its hardware implementation \cite{HLSBOOK} \cite{IEEEDT}.
133
134\subsubsection{Application Specific Instruction Processors}
135
136ASIP (Application-Specific Instruction-Set Processor) are programmable
137processors in which both the instruction and the micro architecture have
138been tailored to a given application domain or to a
139specific application.  This specialization usually offers a good compromise
140between performance (w.r.t a pure software implementation on an embedded
141CPU) and flexibility (w.r.t an application specific hardware co-processor).
142In spite of their obvious advantages, using/designing ASIPs remains a
143difficult task, since it involves designing both a micro-architecture and a
144compiler for this architecture. Besides, to our knowledge, there is still
145no available open-source design flow for ASIP design even if such a tool
146 would be valuable in the
147context of a System Level design exploration tool.
148\par
149In this context, ASIP design based on Instruction Set Extensions (ISEs) has
150received a lot of interest~\cite{NIOS2}, as it makes micro architecture synthesis
151more tractable \footnote{ISEs rely on a template micro-architecture in which
152only a small fraction of the architecture has to be specialized}, and help ASIP
153designers to focus on compilers, for which there are still many open
154problems\cite{ARC08}.
155This approach however has a severe weakness, since it also significantly reduces
156opportunities for achieving good speedups (most speedups remain between 1.5x and
1572.5x), since ISEs performance is generally tied down by I/O constraints as
158they generally rely on the main CPU register file to access data.
159
160% (
161%automaticcaly extraction ISE candidates for application code \cite{CODES04},
162%performing efficient instruction selection and/or storage resource (register)
163%allocation \cite{FPGA08}). 
164To cope with this issue, recent approaches~\cite{DAC09,CODES08,TVLSI06} advocate the use of
165micro-architectural ISE models in which the coupling between the processor micro-architecture
166and the ISE component is tightened up so as to allow the ISE to overcome the register
167I/O limitations. However these approaches generally tackle the problem from a compiler/simulation
168point of view and do not address the problem of generating synthesizable representations for
169these models.
170
171We therefore strongly believe that there is a need for an open-framework which
172would allow researchers and system designers to :
173\begin{itemize}
174\item Explore the various level of interactions between the original CPU micro-architecture
175and its extension (for example through a Domain Specific Language targeted at micro-architecture
176specification and synthesis).
177\item Retarget the compiler instruction-selection pass
178(or prototype new passes) so as to be able to take advantage of this ISEs.
179\item Provide  a complete System-level Integration for using ASIP as SoC building blocks
180(integration with application specific blocks, MPSoc, etc.)
181\end{itemize}
182
183\subsubsection{Automatic Parallelization}
184
185The problem of compiling sequential programs for parallel computers
186has been studied since the advent of the first parallel architectures
187in the 1970s. The basic approach consists in applying program transformations
188which exhibit or increase the potential parallelism, while guaranteeing
189the preservation of the program semantics. Most of these transformations
190just reorder the operations of the program; some of them modify its
191data structures. Dependences (exact or conservative) are checked to guarantee
192the legality of the transformation.
193
194This has lead to the invention of many loop transformations (loop fusion,
195loop splitting, loop skewing, loop interchange, loop unrolling, ...)
196which interact in a complicated way. More recently, it has been noticed
197that all of these are just changes of basis in the iteration domain of
198the program. This has lead to the introduction of the polyhedral model
199\cite{FP:96,DRV:2000}, in which the combination of two transformations is
200simply a matrix product.
201
202Since hardware is inherently parallel, finding parallelism in sequential
203programs in an important prerequisite for HLS. The large FPGA chips of
204today can accomodate much more parallelism than is available in basic blocks.
205The polyhedral model is the ideal tool for finding more parallelism in
206loops.
207
208As a side effect, it has been observed that the polyhedral model is a useful
209tool for many other optimization, like memory reduction and locality
210improvement. Another point is
211that the polyhedral domain \emph{stricto sensu} applies only to
212very regular programs. Its extension to more general programs is
213an active research subject.
214
215%\subsubsection{High Performance Computing}
216%Accelerating high-performance computing (HPC) applications with field-programmable
217%gate arrays (FPGAs) can potentially improve performance.
218%However, using FPGAs presents significant challenges~\cite{hpc06a}.
219%First, the operating frequency of an FPGA is low compared to a high-end microprocessor.
220%Second, based on Amdahl law,  HPC/FPGA application performance is unusually sensitive
221%to the implementation quality~\cite{hpc06b}.
222%Finally, High-performance computing programmers are a highly sophisticated but scarce
223%resource. Such programmers are expected to readily use new technology but lack the time
224%to learn a completely new skill such as logic design~\cite{hpc07a} .
225%\\
226%HPC/FPGA hardware is only now emerging and in early commercial stages,
227%but these techniques have not yet caught up.
228%Thus, much effort is required to develop design tools that translate high level
229%language programs to FPGA configurations.
230
Note: See TracBrowser for help on using the repository browser.