Index: anr/section-3.1.tex
===================================================================
--- anr/section-3.1.tex	(revision 174)
+++ anr/section-3.1.tex	(revision 180)
@@ -26,5 +26,5 @@
 Finally, efficient design methodology are required in order to
 hide FPGA complexity and the underlying implantation subtleties to HPC users,
-so that they don't have to change their habits and can have equivalent design productivity
+so that they do not have to change their habits and can have equivalent design productivity
 than in others families~\cite{hpc07a}. 
 
@@ -39,5 +39,5 @@
 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 designer efforts and poor portability.
+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" ?
@@ -74,5 +74,5 @@
 coprocessors. System Designer must provide the synthesizable description
 with the feasible bus interface. Design Space Exploration is thus limited
-and SystemC simulation is not possible neither at transactional nor at Cycle
+and SystemC simulation is not possible neither at transactional nor at cycle
 accurate level. 
 \\
@@ -88,24 +88,25 @@
 academic world and CATAPULTC~\cite{catapult-c}, PICO~\cite{pico} and
 CYNTHETIZER~\cite{cynthetizer} in commercial world.  Despite their
-maturity, their usage is restrained by:
+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.
 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 
-at the system level.
+at the system level,
+\item They target control oriented or data oriented application only, 
 \item HLS tools take into account only one or few constraints simultaneously while realistic
-designs are multi-constrained. 
+designs are multi-constrained, 
 Moreover, low power consumption constraint is mandatory for embedded systems. 
-However, it is not yet well handled or not handle at all by the synthesis tools already available.
-\item The parallelism is extracted from initial algorithmic specification.
+However, it is not yet well handled or not handle at all by the synthesis tools already available,
+\item The parallelism is extracted from initial algorithmic 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 as polyedric
-transformations to increase the intrinsic parallelism.
+transformations to increase the intrinsic parallelism,
 \item While they support limited loop transformations like loop unrolling and loop
 pipelining, current HLS tools do not provide support for design space exploration neither
-through automatic loop transformations nor through memory mapping.
+through automatic loop transformations nor through memory mapping,
 \item Despite they have 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.
+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
@@ -113,6 +114,5 @@
 \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.
-\mustbecompleted {FIXME :: Ajouter ref livre + D\&T}
+between the specification of an heterogeneous system and its hardware implementation \cite{HLSBOOK} \cite{IEEEDT}.
 
 \subsubsection{Application Specific Instruction Processors}
@@ -138,5 +138,5 @@
 problems\cite{ARC08}.
 This approach however has a strong weakness, since it also significantly reduces 
-opportunities for achieving good seedups (most speedup remain between 1.5x and 
+opportunities for achieving good speedups (most speedup remain between 1.5x and 
 2.5x), since ISEs performance is generally tied down by I/O constraints as 
 they generally rely on the main CPU register file to access data.
@@ -156,6 +156,6 @@
 would allow researchers and system designers to :
 \begin{itemize}
-\item Explore the various level of interactions between the original CPU micro-architecure
-and its extension (for example throught a Domain Specific Language targeted at micro-architecture
+\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 (or prototype nex passes) passes so as
