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

% vim:set spell:
% vim:spell spelllang=en:
\anrdoc{\begin{itemize}
\item Presenter un etat de l’art national et international, en dressant l’etat des
      connaissances sur le sujet.
\item Faire apparaître d’eventuelles contributions des partenaires de la proposition
      de projet a cet etat de l’art.
\item Faire apparaître d’eventuels resultats preliminaires.
\item Inclure les references bibliographiques necessaires en annexe 7.1.
\end{itemize}}

%Our project covers several critical domains in system design in order
%to achieve high performance computing. Starting from a high level description we aim 
%at generating automatically both hardware and software components of the system.

\subsubsection{High Performance Computing}
\label{soa:hpc}
% Un marché bouffé par les archi GPGPU tel que le FERMI de NvidiaCUDA programming language
The High-Performance Computing (HPC) world is composed of three main families of architectures:
many-core, GPGPU (General Purpose computation on Graphics Unit Processing) and FPGA.
Today, the first  two families are dominating the market by taking benefit 
of the strength and influence of mass-market leaders (Intel, Nvidia).
%such as Intel for many-core CPU and Nvidia for GPGPU.
In this market, FPGA architectures are emerging and very promising.
By adapting architecture to the software, % (the opposite is done in the others families)
FPGAs architectures enable better performance
(typically an acceleration factor between 10 and 100)
while using smaller size and less energy (and generating less heat).
However, using FPGAs presents significant challenges~\cite{hpc06a}.
First, the operating frequency of an FPGA is low compared to a high-end microprocessor.
Second, % based on Amdahl law,
 HPC/FPGA application performance is unusually sensitive 
to the implementation quality~\cite{hpc06b}.
% Thus, the performance strongly relies on the detected parallelism.
% (pour résumer les 2 derniers points)
Finally, efficient design methodology are required in order to
hide FPGA complexity and the underlying implantation subtleties to HPC users,
so that they do not have to change their habits and can have equivalent design productivity
than in others families~\cite{hpc07a}. 

%état de l'art FPGA 
HPC/FPGA hardware is only now emerging and in early commercial stages, 
but these techniques have not yet caught up. 
Industrial (Mitrionics~\cite{hpc08}, Gidel~\cite{hpc09}, Convey Computer~\cite{hpc10}) and academic (CHREC)
researches on HPC-FPGA are mainly conducted in the USA. 
None of the approaches developed in these researches are fulfilling entirely the
challenges described above. For example, Convey Computer proposes application-specific instruction 
set extension of x86 cores in an FPGA accelerator,
but extension generation is not automated and requires hardware design skills.
Mitrionics has an elegant solution based on a compute engine specifically
developed for high-performance execution in FPGAs. Unfortunately, the design flow
is based on a new programming language (mitrionC) implying important designer efforts and poor portability.
% tool relying on operator libraries (XtremeData),  
% 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" ?

Thus, much effort is required to develop design tools that translate high level
language programs to FPGA configurations.

\subsubsection{System Synthesis}
\label{soa:system:synthesis}
Today, several solutions for system design are proposed and commercialized.
The existing commercial or free tools do not
cover the whole system synthesis process in a fully automatic way. Moreover,
they are bound to a particular device family and to an IP library.
The most commonly used are provided by \altera and \xilinx to promote their
FPGA devices. These representative tools used to synthesize SoC on FPGA
are introduced below.
\\
The \xilinx System Generator for DSP~\cite{system-generateur-for-dsp} is a
plug-in to Simulink that enables designers to develop high-performance DSP
systems for \xilinx FPGAs.
Designers can specify and simulate a system using MATLAB and Simulink. The
tool will then automatically generate synthesizable Hardware Description
Language (HDL) code mapped to \xilinx pre-optimized algorithms.
However, this tool targets only signal processing algorithms, \xilinx FPGAs and
cannot handle a complete SoC. Thus, it is not really a system synthesis tool.
\\
In the opposite, SOPC Builder~\cite{spoc-builder} from \altera and \xilinx 
Platform Studio XPS from \xilinx allow to describe a system, to synthesize it, 
to program it into a target FPGA and to upload a software application.
Both SOPC Builder and XPS allow designers to select and parameterize components from 
an extensive drop-down list of IP cores (I/O core, DSP, processor,  bus core, ...) 
as well as to incorporate their own IP. Nevertheless, all the previously introduced tools 
do not provide any facilities to synthesize coprocessors and to simulate the platform 
at a high level (SystemC). 
A system designer must provide the synthesizable description of its own IP-cores
interfaces it to the SoC bus.
Design Space Exploration is thus limited and SystemC simulation is not possible
either at transactional or at cycle accurate level.
\\
In addition, \xilinx System Generator, XPS and SOPC Builder are closed world
since each one imposes their own IPs which are not interchangeable.
Designers can then only generate a synthesized netlist, VHDL/Verilog simulation test 
bench and custom software library that reflect the hardware configuration.
\\
Consequently, a designer developing an embedded system needs to master four
design environments:
\begin{enumerate}
  \item a virtual prototyping environment (in SystemC) for system level exploration,
  \item an architecture compiler to define the hardware architecture (Verilog/VHDL),
  \item one or several third-party HLS tools for coprocessor synthesis (C to RTL),
  \item and finally back-end synthesis tools for the bit-stream generation (RTL to bitstream).
\end{enumerate}
Furthermore, mixing these tools requires an important interfacing effort and this makes
the design process very complex and achievable only by designers skilled in many domains.

\subsubsection{High Level Synthesis}
\label{soa:hls}
High Level Synthesis translates a sequential algorithmic description and a
set of constraints (area, power, frequency, ...) to a micro-architecture at
Register Transfer Level (RTL).
Several academic and commercial tools are today available. The most common
tools are SPARK~\cite{spark04}, GAUT~\cite{gaut08}, UGH~\cite{ugh08} in the
academic world and CATAPULTC~\cite{catapult-c}, PICO~\cite{pico} and
CYNTHETIZER~\cite{cynthetizer} in the commercial world.  Despite their
maturity, their usage is restrained by \cite{IEEEDT} \cite{CATRENE} \cite{HLSBOOK}:
\begin{itemize}
\item HLS tools are not integrated into an architecture and system exploration tool.
Thus, a designer who needs to accelerate a software part of the system, must adapt it manually 
to the HLS input dialect and perform engineering work to exploit the synthesis result 
at the system level,
\item Current HLS tools cannot target control AND data oriented applications, 
\item HLS tools take into account mainly a unique constraint while realistic design 
is multi-constrained. 
The power consumption constraint which is mandatory for embedded systems is not yet 
well handled or not handled at all by the HLS tools already available,
\item The parallelism is limited to that present in the initial specification.
To get more parallelism or to reduce the amount of required memory in the SoC, the user
must re-write the algorithmic specification while there are techniques such as polyhedral
transformations that can automate this process.
\item While they support limited loop transformations like loop unrolling and loop
pipelining, current HLS tools do not provide support for design space exploration, either
through automatic loop transformations or for improving the memory mapping,
\item Despite having the same input language (C/C++), they are sensitive to the style in
which the algorithm is written. Consequently, engineering work is required to swap from 
a tool to another,
\item They do not respect accurately the frequency constraint when they target an FPGA device.
Their error is about 10 percent. This is annoying when the generated component is integrated
in a SoC since it will slow down the whole system.
\end{itemize}
Regarding these limitations, it is necessary to create a new tool generation reducing the gap 
between the specification of an heterogeneous system and its hardware implementation \cite{HLSBOOK} \cite{IEEEDT}.

\subsubsection{Application Specific Instruction Processors}
\label{soa:asip}
ASIP (Application-Specific Instruction-Set Processor) are programmable
processors in which both the instruction set and the micro architecture have
been tailored to a given application domain or to a
specific application.  This specialization usually offers a good compromise
between performance (w.r.t a pure software implementation on an embedded
CPU) and flexibility (w.r.t an application specific hardware co-processor).
In spite of their obvious advantages, using/designing ASIPs remains a
difficult task, since it involves designing both a micro-architecture and a
compiler for this architecture. Besides, to our knowledge, there is still
no available open-source design flow for ASIP design even if such a tool
 would be valuable in the
context of a System Level design exploration tool.
\\
In this context, ASIP design based on Instruction Set Extensions (ISEs) has 
received a lot of interest~\cite{NIOS2}, as it makes micro-architecture synthesis 
more tractable \footnote{ISEs rely on a template micro-architecture in which 
only a small fraction of the architecture has to be specialized}, and help ASIP
designers to focus on compilers, for which there are still many open
problems\cite{ARC08}.
This approach however has a severe weakness, since it also significantly reduces 
opportunities for achieving good speedups (most speedups remain between 1.5x and 
2.5x), since ISEs performance is generally limited by I/O constraints as 
they generally rely on the main CPU register file to access data.
\\
To cope with this issue, recent approaches~\cite{DAC09,CODES08,TVLSI06} advocate the use of 
micro-architectural ISE models in which the coupling between the processor micro-architecture
and the ISE component is tightened up so as to allow the ISE to overcome the register 
I/O limitations. However these approaches generally tackle the problem from a compiler/simulation 
point of view and do not address the problem of generating synthesizable representations for 
these models. 
\\
We therefore strongly believe that there is a need for an open-framework which
would allow researchers and system designers to :
\begin{itemize}
\item Explore the various level of interactions between the original CPU micro-architecture
and its extension (for example through a Domain Specific Language targeted at micro-architecture
specification and synthesis).
\item Retarget the compiler instruction-selection pass
(or prototype new passes) so as to be able to take advantage of this ISEs.
\item Provide  a complete System-level Integration for using ASIP as SoC building blocks 
(integration with application specific blocks, MPSoc, etc.)
\end{itemize}

\subsubsection{Automatic Parallelization}
\label{soa:automatic:parallelization}
The problem of compiling sequential programs for parallel computers
has been studied since the advent of the first parallel architectures 
in the 1970s. The basic approach consists in applying program transformations
which exhibit or increase the potential parallelism, while guaranteeing
the preservation of the program semantics. Most of these transformations
just reorder the operations of the program; some of them modify its
data structures. Dependences (exact or conservative) are checked to guarantee
the legality of the transformation.
\\
This has lead to the invention of many loop transformations (loop fusion,
loop splitting, loop skewing, loop interchange, loop unrolling, ...)
which interact in a complicated way. More recently, it has been noticed
that all of these are just changes of basis in the iteration domain of
the program. This has lead to the introduction of the polyhedral model
\cite{FP:96,DRV:2000}, in which the combination of two transformations is 
simply a matrix product.
\\
Since hardware is inherently parallel, finding parallelism in sequential
programs in an important prerequisite for HLS. The large FPGA chips of
today can accommodate much more parallelism than is available in basic blocks.
The polyhedral model is the ideal tool for finding more parallelism in
loops.
\\
As a side effect, it has been observed that the polyhedral model is a useful
tool for many other optimization, like memory reduction and locality
improvement. It should be noted 
that the polyhedral model \emph{stricto sensu} applies only to
very regular programs. Its extension to more general programs is
an active research subject.

\subsubsection{SoC design flow automation using IP-XACT}
\label{soa:ip-xact}
% EV: Industrial IP integration flows based on IP-XACT standards: \cite{mds1}\\
% EV: SPIRIT IP-XACT Controlled ESL Design Tool Applied to a Network-on-Chip Platform: \cite{mds2}\\
% EV: SocKET design flow and Application on industrial use cases: \cite{socketflow}\\
% IA: http://www.design-reuse.com/articles/19895/ip-xact-xml.html \cite{dandr}\\
IP-XACT is an XML based open standard defined by the Accellera consortium. 
This non-profit organisation provides a unified set of high quality IP-XACT 
specifications for documenting IP using meta-data. This meta-data will be 
used for configuring, integrating, and verifying IP in advanced SoC design 
and interfacing tools using TGI (Tight Generator Interface is a software API)
that can be used to access design meta-data descriptions of complete system designs. 
The specification for the schema is tailored to the requirements of the industry,
and focused on enabling technologies for the efficient design of electronic 
systems from concept to production. The last IEEE 1685 release of IP-XACT incorporates 
both RTL and TLM (transaction level modelling) capabilities. Thus it can be used to
package IP portfolios~\cite{dandr} and describe their assembly in complex hardware architectures.~\cite{mds1}~\cite{mds2} 
These description files are the basis for tool interoperability and data exchange 
through a common structured data management\cite{socketflow}. Today more than two hundred companies 
are members of the consortium and the board is incorporating top actors 
(STM, NXP, TI, ARM, FREESCALE, LSI, Mentor, Synopsys and Cadence), ensuring the 
wide adoption by industry. Initiatives have already
attempted to extend this standard
to the AMS IPs packaging domain (MEDEA+ Beyond Dreams Project) and to Hardware Dependent 
Software layers (MEDEA+ SoftSoc project) and Accellera is reusing these results for 
further releases.
\parlf
In IP-XACT the flow automation and data consistency is ensured by generators, which 
are program modules that process IP-XACT XML data into something useful 
for the design. They are key portable mechanism for encapsulating specialist design
knowledge and enable designers to deploy specialist knowledge in their design. It is
always possible to create generators in order to link several design or analysis tools
around a centric representation of meta-data in IP-XACT. This kind of XML schema for
meta-data management is a good solution for the federation of heterogeneous design domains
(models, tools, languages, methodologies, etc.).