source: anr/section-etat-de-art.tex @ 343

Last change on this file since 343 was 339, checked in by coach, 14 years ago

corrections de langage

  • Property svn:eol-style set to native
  • Property svn:keywords set to Revision HeadURL Id Date
File size: 16.9 KB
Line 
1% vim:set spell:
2% vim:spell spelllang=en:
3\anrdoc{\begin{itemize}
4\item Presenter un etat de l’art national et international, en dressant l’etat des
5      connaissances sur le sujet.
6\item Faire apparaître d’eventuelles contributions des partenaires de la proposition
7      de projet a cet etat de l’art.
8\item Faire apparaître d’eventuels resultats preliminaires.
9\item Inclure les references bibliographiques necessaires en annexe 7.1.
10\end{itemize}}
11
12%Our project covers several critical domains in system design in order
13%to achieve high performance computing. Starting from a high level description we aim
14%at generating automatically both hardware and software components of the system.
15
16\subsubsection{High Performance Computing}
17\label{soa:hpc}
18% Un marché bouffé par les archi GPGPU tel que le FERMI de NvidiaCUDA programming language
19The High-Performance Computing (HPC) world is composed of three main families of architectures:
20many-core, GPGPU (General Purpose computation on Graphics Unit Processing) and FPGA.
21The first  two families are dominating the market by taking benefit
22of the strength and influence of mass-market leaders (Intel, Nvidia).
23%such as Intel for many-core CPU and Nvidia for GPGPU.
24In this market, FPGA architectures are emerging and very promising.
25By adapting architecture to the software, % (the opposite is done in the others families)
26FPGAs architectures enable better performance
27(typically between x10 and x100 accelerations)
28while using smaller size and less energy (and heat).
29However, using FPGAs presents significant challenges~\cite{hpc06a}.
30First, the operating frequency of an FPGA is low compared to a high-end microprocessor.
31Second, based on Amdahl law,  HPC/FPGA application performance is unusually sensitive
32to the implementation quality~\cite{hpc06b}.
33% Thus, the performance strongly relies on the detected parallelism.
34% (pour résumer les 2 derniers points)
35Finally, efficient design methodology are required in order to
36hide FPGA complexity and the underlying implantation subtleties to HPC users,
37so that they do not have to change their habits and can have equivalent design productivity
38than in others families~\cite{hpc07a}.
39
40%état de l'art FPGA
41HPC/FPGA hardware is only now emerging and in early commercial stages,
42but these techniques have not yet caught up.
43Industrial (Mitrionics~\cite{hpc08}, Gidel~\cite{hpc09}, Convey Computer~\cite{hpc10}) and academic (CHREC)
44researches on HPC-FPGA are mainly conducted in the USA.
45None of the approaches developed in these researches are fulfilling entirely the
46challenges described above. For example, Convey Computer proposes application-specific instruction set extension of x86 cores in an FPGA accelerator,
47but extension generation is not automated and requires hardware design skills.
48Mitrionics has an elegant solution based on a compute engine specifically
49developed for high-performance execution in FPGAs. Unfortunately, the design flow
50is based on a new programming language (mitrionC) implying important designer efforts and poor portability.
51% tool relying on operator libraries (XtremeData), 
52% 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" ?
53
54Thus, much effort is required to develop design tools that translate high level
55language programs to FPGA configurations.
56Moreover, as already remarked in~\cite{hpc11}, Dynamic Partial Reconfiguration~\cite{hpc12}
57(DPR, which enables changing a part of the FPGA, while the rest is still working)
58appears very interesting for improving HPC performance as well as reducing required area.
59
60\subsubsection{System Synthesis}
61\label{soa:system:synthesis}
62Today, several solutions for system design are proposed and commercialized.
63The existing commercial or free tools do not
64cover the whole system synthesis process in a full automatic way. Moreover,
65they are bound to a particular device family and to IPs library.
66The most commonly used are provided by \altera and \xilinx to promote their
67FPGA devices. These representative tools used to synthesize SoC on FPGA
68are introduced below.
69\\
70The \xilinx System Generator for DSP~\cite{system-generateur-for-dsp} is a
71plug-in to Simulink that enables designers to develop high-performance DSP
72systems for \xilinx FPGAs.
73Designers can design and simulate a system using MATLAB and Simulink. The
74tool will then automatically generate synthesizable Hardware Description
75Language (HDL) code mapped to \xilinx pre-optimized algorithms.
76However, this tool targets onlysignal processing algorithms, \xilinx FPGAs and
77cannot handle a complete SoC. Thus, it is not really a system synthesis tool.
78\\
79In the opposite, SOPC Builder~\cite{spoc-builder} from \altera and \xilinx 
80Platform Studio XPS from \xilinx allow to describe a system, to synthesize it,
81to program it into a target FPGA and to upload a software application.
82Both SOPC Builder and XPS, allow designers to select and parameterize components from
83an extensive drop-down list of IP cores (I/O core, DSP, processor,  bus core, ...)
84as well as incorporate their own IP. Nevertheless, all the previously introduced tools
85do not provide any facilities to synthesize coprocessors and to simulate the platform
86at a high level (SystemC).
87System designer must provide the synthesizable description of its own IP-cores with
88the feasible bus interface. Design Space Exploration is thus limited
89and SystemC simulation is not possible neither at transactional nor at cycle
90accurate level.
91\\
92In addition, \xilinx System Generator, XPS and SOPC Builder are closed world
93since each one imposes their own IPs which are not interchangeable.
94Designers can then only generate a synthesized netlist, VHDL/Verilog simulation test
95bench and custom software library that reflect the hardware configuration.
96
97Consequently, a designer developing an embedded system needs to master four different
98design environments:
99\begin{enumerate}
100  \item a virtual prototyping environment (in SystemC) for system level exploration,
101  \item an architecture compiler to define the hardware architecture (Verilog/VHDL),
102  \item one or several third-party HLS tools for coprocessor synthesis (C to RTL),
103  \item and finally back-end synthesis tools for the bit-stream generation (RTL to bitstream).
104\end{enumerate}
105Furthermore, mixing these tools requires an important interfacing effort and this makes
106the design process very complex and achievable only by designers skilled in many domains.
107
108\subsubsection{High Level Synthesis}
109\label{soa:hls}
110High Level Synthesis translates a sequential algorithmic description and a
111set of constraints (area, power, frequency, ...) to a micro-architecture at
112Register Transfer Level (RTL).
113Several academic and commercial tools are today available. The most common
114tools are SPARK~\cite{spark04}, GAUT~\cite{gaut08}, UGH~\cite{ugh08} in the
115academic world and CATAPULTC~\cite{catapult-c}, PICO~\cite{pico} and
116CYNTHETIZER~\cite{cynthetizer} in the commercial world.  Despite their
117maturity, their usage is restrained by \cite{IEEEDT} \cite{CATRENE} \cite{HLSBOOK}:
118\begin{itemize}
119\item HLS tools are not integrated into an architecture and system exploration tool.
120Thus, a designer who needs to accelerate a software part of the system, must adapt it manually
121to the HLS input dialect and perform engineering work to exploit the synthesis result
122at the system level,
123\item Current HLS tools can not target control AND data oriented applications,
124\item HLS tools take into account mainly a unique constraint while realistic design
125is multi-constrained.
126Low power consumption constraint which is mandatory for embedded systems is not yet
127well handled or not handled at all by the HLS tools already available,
128\item The parallelism is extracted from the initial specification.
129To get more parallelism or to reduce the amount of required memory in the SoC, the user
130must re-write the algorithmic specification while there are techniques such as polyedric
131transformations to increase the intrinsic parallelism,
132\item While they support limited loop transformations like loop unrolling and loop
133pipelining, current HLS tools do not provide support for design space exploration, either
134through automatic loop transformations or through memory mapping,
135\item Despite having the same input language (C/C++), they are sensitive to the style in
136which the algorithm is written. Consequently, engineering work is required to swap from
137a tool to another,
138\item They do not respect accurately the frequency constraint when they target an FPGA device.
139Their error is about 10 percent. This is annoying when the generated component is integrated
140in a SoC since it will slow down the whole system.
141\end{itemize}
142Regarding these limitations, it is necessary to create a new tool generation reducing the gap
143between the specification of an heterogeneous system and its hardware implementation \cite{HLSBOOK} \cite{IEEEDT}.
144
145\subsubsection{Application Specific Instruction Processors}
146\label{soa:asip}
147ASIP (Application-Specific Instruction-Set Processor) are programmable
148processors in which both the instruction set and the micro architecture have
149been tailored to a given application domain or to a
150specific application.  This specialization usually offers a good compromise
151between performance (w.r.t a pure software implementation on an embedded
152CPU) and flexibility (w.r.t an application specific hardware co-processor).
153In spite of their obvious advantages, using/designing ASIPs remains a
154difficult task, since it involves designing both a micro-architecture and a
155compiler for this architecture. Besides, to our knowledge, there is still
156no available open-source design flow for ASIP design even if such a tool
157 would be valuable in the
158context of a System Level design exploration tool.
159\par
160In this context, ASIP design based on Instruction Set Extensions (ISEs) has
161received a lot of interest~\cite{NIOS2}, as it makes micro architecture synthesis
162more tractable \footnote{ISEs rely on a template micro-architecture in which
163only a small fraction of the architecture has to be specialized}, and help ASIP
164designers to focus on compilers, for which there are still many open
165problems\cite{ARC08}.
166This approach however has a severe weakness, since it also significantly reduces
167opportunities for achieving good speedups (most speedups remain between 1.5x and
1682.5x), since ISEs performance is generally limited by I/O constraints as
169they generally rely on the main CPU register file to access data.
170
171% (
172%automaticcaly extraction ISE candidates for application code \cite{CODES04},
173%performing efficient instruction selection and/or storage resource (register)
174%allocation \cite{FPGA08}). 
175To cope with this issue, recent approaches~\cite{DAC09,CODES08,TVLSI06} advocate the use of
176micro-architectural ISE models in which the coupling between the processor micro-architecture
177and the ISE component is tightened up so as to allow the ISE to overcome the register
178I/O limitations. However these approaches generally tackle the problem from a compiler/simulation
179point of view and do not address the problem of generating synthesizable representations for
180these models.
181
182We therefore strongly believe that there is a need for an open-framework which
183would allow researchers and system designers to :
184\begin{itemize}
185\item Explore the various level of interactions between the original CPU micro-architecture
186and its extension (for example through a Domain Specific Language targeted at micro-architecture
187specification and synthesis).
188\item Retarget the compiler instruction-selection pass
189(or prototype new passes) so as to be able to take advantage of this ISEs.
190\item Provide  a complete System-level Integration for using ASIP as SoC building blocks
191(integration with application specific blocks, MPSoc, etc.)
192\end{itemize}
193
194\subsubsection{Automatic Parallelization}
195\label{soa:automatic:parallelization}
196The problem of compiling sequential programs for parallel computers
197has been studied since the advent of the first parallel architectures
198in the 1970s. The basic approach consists in applying program transformations
199which exhibit or increase the potential parallelism, while guaranteeing
200the preservation of the program semantics. Most of these transformations
201just reorder the operations of the program; some of them modify its
202data structures. Dependences (exact or conservative) are checked to guarantee
203the legality of the transformation.
204
205This has lead to the invention of many loop transformations (loop fusion,
206loop splitting, loop skewing, loop interchange, loop unrolling, ...)
207which interact in a complicated way. More recently, it has been noticed
208that all of these are just changes of basis in the iteration domain of
209the program. This has lead to the introduction of the polyhedral model
210\cite{FP:96,DRV:2000}, in which the combination of two transformations is
211simply a matrix product.
212
213Since hardware is inherently parallel, finding parallelism in sequential
214programs in an important prerequisite for HLS. The large FPGA chips of
215today can accomodate much more parallelism than is available in basic blocks.
216The polyhedral model is the ideal tool for finding more parallelism in
217loops.
218
219As a side effect, it has been observed that the polyhedral model is a useful
220tool for many other optimization, like memory reduction and locality
221improvement. Itshould be noted
222that the polyhedral model \emph{stricto sensu} applies only to
223very regular programs. Its extension to more general programs is
224an active research subject.
225
226\subsubsection{SoC design flow automation using IP-XACT}
227\label{soa:ip-xact}
228% EV: Industrial IP integration flows based on IP-XACT standards: \cite{mds1}\\
229% EV: SPIRIT IP-XACT Controlled ESL Design Tool Applied to a Network-on-Chip Platform: \cite{mds2}\\
230% EV: SocKET design flow and Application on industrial use cases: \cite{socketflow}\\
231% IA: http://www.design-reuse.com/articles/19895/ip-xact-xml.html \cite{dandr}\\
232IP-XACT is an XML based open standard defined by the Accellera consortium.
233This non-profit organisation provides a unified set of high quality IP-XACT
234specifications for documenting IP using meta-data. This meta-data will be
235used for configuring, integrating, and verifying IP in advanced SoC design
236and interfacing tools using TGI (Tight Generator Interface is a software API)
237that can be used to access design meta-data descriptions of complete system designs.
238The specification for the schema is tailored to the requirements of the industry,
239and focused on enabling technologies for the efficient design of electronic
240systems from concept to production. The last IEEE 1685 release of IP-XACT incorporates
241both RTL and TLM (transaction level modelling) capabilities. Thus it can be used to
242package IP portfolios~\cite{dandr} and describe their assembly in complex hardware architectures.~\cite{mds1}~\cite{mds2} 
243These description files are the basis for tool interoperability and data exchange
244through a common structured data management\cite{socketflow}. Today more than two hundred companies
245are members of the consortium and the board is incorporating top actors
246(STM, NXP, TI, ARM, FREESCALE, LSI, Mentor, Synopsys and Cadence), ensuring the
247wide adoption by industry. Initiatives have already
248attempted to extend this standard
249to the AMS IPs packaging domain (MEDEA+ Beyond Dreams Project) and to Hardware Dependent
250Software layers (MEDEA+ SoftSoc project) and Accellera is reusing these results for
251further releases.
252\parlf
253In IP-XACT the flow automation and data constistency is ensured by generators, which
254are program modules that process IP-XACT XML data into something useful
255for the design. They are key portable mechanism for encapsulating specialist design
256knowledge and enable designers to deploy specialist knowledge in their design. It is
257always possible to create generators in order to link several design or analysis tools
258around a centric representation of metadata in IP-XACT. This kind of XML schema for
259metadata management is a good solution for the federation of heterogeneous design domains
260(models, tools, languages, methodologies, etc.).
261
262%\subsubsection{High Performance Computing}
263%Accelerating high-performance computing (HPC) applications with field-programmable
264%gate arrays (FPGAs) can potentially improve performance.
265%However, using FPGAs presents significant challenges~\cite{hpc06a}.
266%First, the operating frequency of an FPGA is low compared to a high-end microprocessor.
267%Second, based on Amdahl law,  HPC/FPGA application performance is unusually sensitive
268%to the implementation quality~\cite{hpc06b}.
269%Finally, High-performance computing programmers are a highly sophisticated but scarce
270%resource. Such programmers are expected to readily use new technology but lack the time
271%to learn a completely new skill such as logic design~\cite{hpc07a} .
272%\\
273%HPC/FPGA hardware is only now emerging and in early commercial stages,
274%but these techniques have not yet caught up.
275%Thus, much effort is required to develop design tools that translate high level
276%language programs to FPGA configurations.
277
Note: See TracBrowser for help on using the repository browser.