Index: /anr/section-3.1.tex
===================================================================
--- /anr/section-3.1.tex	(revision 251)
+++ /anr/section-3.1.tex	(revision 252)
@@ -55,5 +55,5 @@
 they are bound to a particular device family and to IPs library.
 The most commonly used are provided by \altera and \xilinx to promote their
-FPGA devices. These two representative tools used to synthesize SoC on FPGA
+FPGA devices. These representative tools used to synthesize SoC on FPGA
 are introduced below.
 \\
@@ -67,48 +67,32 @@
 cannot handle a complete SoC. Thus, it is not really a system synthesis tool.
 \\
-In the opposite, SOPC Builder~\cite{spoc-builder} allows to describe a
-system, to synthesis it, to programm it into a target FPGA and to upload a
-software application.
-% FIXME(C2H from \altera, marche vite mais ressource monstrueuse)
-Nevertheless, SOPC Builder does not provide any facilities to synthesize
-coprocessors. System Designer must provide the synthesizable description
-with the feasible bus interface. Design Space Exploration is thus limited
+In the opposite, SOPC Builder~\cite{spoc-builder} from \altera and \xilinx 
+Platform Studio XPS from \xilinx allows to describe a system, to synthesis 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 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). 
+System designer must provide the synthesizable description of its own IP-cores with 
+the feasible bus interface. Design Space Exploration is thus limited
 and SystemC simulation is not possible neither at transactional nor at cycle
 accurate level. 
 \\
-In addition, \xilinx System Generator and SOPC Builder are closed world
+In addition, \xilinx System Generator, XPS and SOPC Builder are closed world
 since each one imposes their own IPs which are not interchangeable.
-%By using SOPC Builder~\cite{spoc-builder} from \altera, designers can select and
-%parameterize components from an extensive drop-down list of IP cores (I/O core, DSP,
-%processor,  bus core, ...) as well as incorporate their own IP.
-%Designers can then generate a synthesized netlist, simulation test bench and custom
-%software library that reflect the hardware configuration.
-%Nevertheless, SOPC Builder does not provide any facilities to synthesize coprocessors and to
-%simulate the platform at a high design level (systemC). 
-%In addition, SOPC Builder is proprietary and only works together with \altera's Quartus compilation
-%tool to implement designs on \altera devices (Stratix, Arria, Cyclone).
-%PICO~\cite{pico} and CATAPULT-C~\cite{catapult-c} allow to synthesize
-%coprocessors from a C++ description.
-%Nevertheless, they can only deal with data dominated applications and they do not handle
-%the platform level.
-%Similarly, the 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 design 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 macro-cells.
-%However, this tool targets only DSP based algorithms.
-%\\
-%Consequently, a designer developping an embedded system needs to master four different
-%design environments:
-%\begin{enumerate}
-%  \item a virtual prototyping environment such as SoCLib for system level exploration,
-%  \item an architecture compiler (such as SOPC Builder from \altera, or System generator
-%  from \xilinx) to define the hardware architecture,
-%  \item one or several HLS tools (such as PICO~\cite{pico} or CATAPULT-C~\cite{catapult-c}) for 
-%        coprocessor synthesis,
-%  \item and finally backend synthesis tools (such as Quartus or Synopsys) for the bit-stream generation.
-%\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.
+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 different
+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}
@@ -122,14 +106,14 @@
 maturity, their usage is restrained by \cite{IEEEDT} \cite{CATRENE} \cite{HLSBOOK}:
 \begin{itemize}
-\item The HLS tools are not integrated into an architecture and system exploration tool.
+\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 performs engineering work to exploit the synthesis result 
+to the HLS input dialect and perform engineering work to exploit the synthesis result 
 at the system level,
 \item Current HLS tools can not target control AND data oriented applications, 
-\item HLS tools take into account only one or few constraints simultaneously while realistic
-designs are multi-constrained, 
-Moreover, low power consumption constraint is mandatory for embedded systems. 
-However, it is not yet well handled or not handled at all by the synthesis tools already available,
-\item The parallelism is extracted from initial algorithmic specification.
+\item HLS tools take into account mainly a unique constraint while realistic design 
+is multi-constrained. 
+Low 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 extracted from 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 is techniques such as polyedric
@@ -152,5 +136,5 @@
 ASIP (Application-Specific Instruction-Set Processor) are programmable
 processors in which both the instruction and the micro architecture have
-been tailored to a given application domain (e.g. video processing), or to a
+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