]> AND Private Git Repository - dmems12.git/commitdiff
Logo AND Algorithmique Numérique Distribuée

Private GIT Repository
11ème :
authorStéphane Domas <sdomas@prodigy.iut-bm.univ-fcomte.fr>
Fri, 21 Oct 2011 13:55:32 +0000 (15:55 +0200)
committerStéphane Domas <sdomas@prodigy.iut-bm.univ-fcomte.fr>
Fri, 21 Oct 2011 13:55:32 +0000 (15:55 +0200)
- moidf resultat XP

dmems12.tex
lever-xp.jpg [new file with mode: 0644]

index 534a689f04861dea4bff6d500add0d369c3a5f4e..10db6244de9d66bf5861f7f42700d7a49ee986ba 100644 (file)
@@ -44,7 +44,7 @@
 
 
 
 
 
 
-\title{Using FPGAs for high speed and real time cantilever deflection estimation}
+\title{A new approach based on least square methods to estimate in real time cantilevers deflection with a FPGA}
 \author{\IEEEauthorblockN{Raphaël Couturier\IEEEauthorrefmark{1}, Stéphane Domas\IEEEauthorrefmark{1}, Gwenhaël Goavec-Merou\IEEEauthorrefmark{2} and Michel Lenczner\IEEEauthorrefmark{2}}
 \IEEEauthorblockA{\IEEEauthorrefmark{1}FEMTO-ST, DISC, University of Franche-Comte, Belfort, France\\
 \{raphael.couturier,stephane.domas\}@univ-fcomte.fr}
 \author{\IEEEauthorblockN{Raphaël Couturier\IEEEauthorrefmark{1}, Stéphane Domas\IEEEauthorrefmark{1}, Gwenhaël Goavec-Merou\IEEEauthorrefmark{2} and Michel Lenczner\IEEEauthorrefmark{2}}
 \IEEEauthorblockA{\IEEEauthorrefmark{1}FEMTO-ST, DISC, University of Franche-Comte, Belfort, France\\
 \{raphael.couturier,stephane.domas\}@univ-fcomte.fr}
@@ -90,19 +90,18 @@ the cantiliver which result in a complex fabrication process.
 
 In this  paper our attention is focused  on a method based  on interferometry to
 measure cantilevers' displacements.  In  this method cantilevers are illuminated
 
 In this  paper our attention is focused  on a method based  on interferometry to
 measure cantilevers' displacements.  In  this method cantilevers are illuminated
-by  an optic  source. The  interferometry produces  fringes on  each cantilevers
+by  an optic  source. The  interferometry produces  fringes on  each cantilever
 which enables to  compute the cantilever displacement.  In  order to analyze the
 fringes a  high speed camera  is used. Images  need to be processed  quickly and
 then  a estimation  method is  required to  determine the  displacement  of each
 which enables to  compute the cantilever displacement.  In  order to analyze the
 fringes a  high speed camera  is used. Images  need to be processed  quickly and
 then  a estimation  method is  required to  determine the  displacement  of each
-cantilever.  In~\cite{AFMCSEM11},  the authors have  used an algorithm  based on
+cantilever.  In~\cite{AFMCSEM11},  authors have  used an algorithm  based on
 spline to estimate the cantilevers' positions.
 
 spline to estimate the cantilevers' positions.
 
-   The overall  process gives
-accurate results  but all the computation  are performed on  a standard computer
-using labview.  Consequently,  the main drawback of this  implementation is that
-the computer is a bootleneck in the overall process. In this paper we propose to
-use a  method based on least  square and to  implement all the computation  on a
-FGPA.
+The overall process gives accurate results but all the computations
+are performed on a standard computer using LabView.  Consequently, the
+main drawback of this implementation is that the computer is a
+bootleneck. In this paper we propose to use a method based on least
+square and to implement all the computation on a FGPA.
 
 The remainder  of the paper  is organized as  follows. Section~\ref{sec:measure}
 describes  more precisely  the measurement  process. Our  solution based  on the
 
 The remainder  of the paper  is organized as  follows. Section~\ref{sec:measure}
 describes  more precisely  the measurement  process. Our  solution based  on the
@@ -118,13 +117,6 @@ presented.
 \section{Measurement principles}
 \label{sec:measure}
 
 \section{Measurement principles}
 \label{sec:measure}
 
-
-
-
-
-
-
-
 \subsection{Architecture}
 \label{sec:archi}
 %% description de l'architecture générale de l'acquisition d'images
 \subsection{Architecture}
 \label{sec:archi}
 %% description de l'architecture générale de l'acquisition d'images
@@ -138,24 +130,26 @@ deflection scheme and  sentitive to the angular displacement  of the cantilever,
 interferometry  is sensitive  to  the  optical path  difference  induced by  the
 vertical displacement of the cantilever.
 
 interferometry  is sensitive  to  the  optical path  difference  induced by  the
 vertical displacement of the cantilever.
 
-The system build  by authors of~\cite{AFMCSEM11} has been  developped based on a
-Linnick     interferomter~\cite{Sinclair:05}.    It     is     illustrated    in
-Figure~\ref{fig:AFM}.  A  laser diode  is first split  (by the splitter)  into a
-reference beam and a sample beam  that reachs the cantilever array.  In order to
-be  able to  move  the cantilever  array, it  is  mounted on  a translation  and
-rotational hexapod  stage with  five degrees of  freedom. The optical  system is
-also fixed to the stage.  Thus,  the cantilever array is centered in the optical
-system which  can be adjusted accurately.   The beam illuminates the  array by a
-microscope objective  and the  light reflects on  the cantilevers.  Likewise the
-reference beam  reflects on a  movable mirror.  A  CMOS camera chip  records the
-reference and  sample beams which  are recombined in  the beam splitter  and the
-interferogram.   At the  beginning of  each  experiment, the  movable mirror  is
-fitted  manually in  order to  align the  interferometric  fringes approximately
-parallel  to the cantilevers.   When cantilevers  move due  to the  surface, the
-bending of  cantilevers produce  movements in the  fringes that can  be detected
-with    the    CMOS    camera.     Finally    the    fringes    need    to    be
-analyzed. In~\cite{AFMCSEM11}, the authors used a LabView program to compute the
-cantilevers' movements from the fringes.
+The system build by these authors is based on a Linnick
+interferomter~\cite{Sinclair:05}.  It is illustrated in
+Figure~\ref{fig:AFM}.  A laser diode is first split (by the splitter)
+into a reference beam and a sample beam that reachs the cantilever
+array.  In order to be able to move the cantilever array, it is
+mounted on a translation and rotational hexapod stage with five
+degrees of freedom. The optical system is also fixed to the stage.
+Thus, the cantilever array is centered in the optical system which can
+be adjusted accurately.  The beam illuminates the array by a
+microscope objective and the light reflects on the cantilevers.
+Likewise the reference beam reflects on a movable mirror.  A CMOS
+camera chip records the reference and sample beams which are
+recombined in the beam splitter and the interferogram.  At the
+beginning of each experiment, the movable mirror is fitted manually in
+order to align the interferometric fringes approximately parallel to
+the cantilevers.  When cantilevers move due to the surface, the
+bending of cantilevers produce movements in the fringes that can be
+detected with the CMOS camera.  Finally the fringes need to be
+analyzed. In~\cite{AFMCSEM11}, authors used a LabView program to
+compute the cantilevers' deflections from the fringes.
 
 \begin{figure}    
 \begin{center}
 
 \begin{figure}    
 \begin{center}
@@ -171,21 +165,29 @@ cantilevers' movements from the fringes.
 \subsection{Cantilever deflection estimation}
 \label{sec:deflest}
 
 \subsection{Cantilever deflection estimation}
 \label{sec:deflest}
 
-As shown on image \ref{img:img-xp}, each cantilever is covered by
-interferometric fringes. The fringes will distort when cantilevers are
-deflected. Estimating the deflection is done by computing this
-distortion. For that, (ref A. Meister + M Favre) proposed a method
-based on computing the phase of the fringes, at the base of each
-cantilever, near the tip, and on the base of the array. They assume
-that a linear relation binds these phases, which can be use to
-"unwrap" the phase at the tip and to determine the deflection.\\
-
-More precisely, segment of pixels are extracted from images taken by a
-high-speed camera. These segments are large enough to cover several
-interferometric fringes and are placed at the base and near the tip of
-the cantilevers. They are called base profile and tip profile in the
-following. Furthermore, a reference profile is taken on the base of
-the cantilever array.
+\begin{figure}    
+\begin{center}
+\includegraphics[width=\columnwidth]{lever-xp}
+\end{center}
+\caption{Portion of an image picked by the camera}
+\label{fig:img-xp}   
+\end{figure}
+
+As shown on image \ref{fig:img-xp}, each cantilever is covered by
+several interferometric fringes. The fringes will distort when
+cantilevers are deflected. Estimating the deflection is done by
+computing this distortion. For that, authors of \cite{AFMCSEM11}
+proposed a method based on computing the phase of the fringes, at the
+base of each cantilever, near the tip, and on the base of the
+array. They assume that a linear relation binds these phases, which
+can be use to "unwrap" the phase at the tip and to determine the deflection.\\
+
+More precisely, segment of pixels are extracted from images taken by
+the camera. These segments are large enough to cover several
+interferometric fringes. As said above, they are placed at the base
+and near the tip of the cantilevers. They are called base profile and
+tip profile in the following. Furthermore, a reference profile is
+taken on the base of the cantilever array.
 
 The pixels intensity $I$ (in gray level) of each profile is modelized by:
 
 
 The pixels intensity $I$ (in gray level) of each profile is modelized by:
 
@@ -344,10 +346,11 @@ that communicate between i.MX and Spartan6, using Spartan3 as a
 tunnel. By default, the WEIM interface provides a clock signal at
 100MHz that is connected to dedicated FPGA pins.
 
 tunnel. By default, the WEIM interface provides a clock signal at
 100MHz that is connected to dedicated FPGA pins.
 
-The Spartan6 is an LX100 version. It has 15822 slices, equivalent to
-101261 logic cells. There are 268 internal block RAM of 18Kbits, and
-180 dedicated multiply-adders (named DSP48), which is largely enough
-for our project.
+The Spartan6 is an LX100 version. It has 15822 slices, each slice
+containing 4 LUTs and 8 flip/flops. It is equivalent to 101261 logic
+cells. There are 268 internal block RAM of 18Kbits, and 180 dedicated
+multiply-adders (named DSP48), which is largely enough for our
+project.
 
 Some I/O pins of Spartan6 are connected to two $2\times 17$ headers
 that can be used as user wants. For the project, they will be
 
 Some I/O pins of Spartan6 are connected to two $2\times 17$ headers
 that can be used as user wants. For the project, they will be
@@ -362,18 +365,18 @@ phase. The second one, detailed in this article, is based on a
 classical least square method but suppose that frequency is already
 known.
 
 classical least square method but suppose that frequency is already
 known.
 
-\subsubsection{Spline algorithm}
+\subsubsection{Spline algorithm (SPL)}
 \label{sec:algo-spline}
 Let consider a profile $P$, that is a segment of $M$ pixels with an
 intensity in gray levels. Let call $I(x)$ the intensity of profile in $x
 \in [0,M[$. 
 
 \label{sec:algo-spline}
 Let consider a profile $P$, that is a segment of $M$ pixels with an
 intensity in gray levels. Let call $I(x)$ the intensity of profile in $x
 \in [0,M[$. 
 
-At  first, only $M$  values of  $I$ are  known, for  $x =  0, 1,  \ldots,M-1$. A
-normalisation  allows  to scale  known  intensities  into  $[-1,1]$. We  compute
-splines  that fit  at best  these normalised  intensities. Splines  (SPL  in the
-following) are  used to interpolate $N  = k\times M$ points  (typically $k=4$ is
-sufficient), within $[0,M[$. Let call  $x^s$ the coordinates of these $N$ points
-    and $I^s$ their intensities.
+At first, only $M$ values of $I$ are known, for $x = 0, 1,
+\ldots,M-1$. A normalisation allows to scale known intensities into
+$[-1,1]$. We compute splines that fit at best these normalised
+intensities. Splines are used to interpolate $N = k\times M$ points
+(typically $k=4$ is sufficient), within $[0,M[$. Let call $x^s$ the
+coordinates of these $N$ points and $I^s$ their intensities.
 
 In order to have the frequency, the mean line $a.x+b$ (see equation \ref{equ:profile}) of $I^s$ is
 computed. Finding intersections of $I^s$ and this line allow to obtain
 
 In order to have the frequency, the mean line $a.x+b$ (see equation \ref{equ:profile}) of $I^s$ is
 computed. Finding intersections of $I^s$ and this line allow to obtain
@@ -394,7 +397,7 @@ Two things can be noticed:
   computation of $\theta$.
 \end{itemize}
 
   computation of $\theta$.
 \end{itemize}
 
-\subsubsection{Least square algorithm}
+\subsubsection{Least square algorithm (LSQ)}
 
 Assuming that we compute the phase during the acquisition loop,
 equation \ref{equ:profile} has only 4 parameters: $a, b, A$, and
 
 Assuming that we compute the phase during the acquisition loop,
 equation \ref{equ:profile} has only 4 parameters: $a, b, A$, and
@@ -694,24 +697,42 @@ will include real experiments in the final version of this paper.
 % - en parallèle : simulink et VHDL à la main
 
 
 % - en parallèle : simulink et VHDL à la main
 
 
-From the  LSQ algorithm,  we have written  a C  program which uses  only integer
-values  that have  been  previously  scaled. The  quantization  of doubles  into
-integers has  been performed  in order  to obtain a  good trade-off  between the
-number of bits  used and the precision. We have  compared the result of
-the LSQ version  using integers and doubles. We have observed  that the results of
-both versions were similar.
-
-Then we have built  two versions of VHDL codes: one directly  by hand coding and
-the     other     with    Matlab     using     the     Simulink    HDL     coder
-feature~\cite{HDLCoder}. Although  the approach is completely  different we have
-obtain VHDL  codes that are quite  comparable. Each approach  has advantages and
-drawbacks.   Roughly speaking, hand  coding provides  beautiful and  much better
-structured code  while HDL  coder provides  code faster.  In  terms of  speed of
-code, we  think that both  approaches will be  quite comparable with  a slightly
-advantage for hand coding.  We hope that real experiments will confirm that.  In
-the  LSQ algorithm, we  have replaced  all the  divisions by  multiplications by
-constants since divisions  are performed with constants depending  of the number
-of pixels in the profile (i.e. $M$).
+From the LSQ algorithm, we have written a C program that uses only
+integer values. We use a very simple quantization by multiplying
+double precision values by a power of two, keeping the integer
+part. For example, all values stored in lut$_s$, lut$_c$, $\ldots$ are
+scaled by 1024.  Since LSQ also computes average, variance, ... to
+remove the slope, the result of implied euclidian divisions may be
+relatively wrong. To avoid that, we also scale the pixel intensities
+by a power of two. Futhermore, assuming $nb_s$ is fixed, these
+divisions have a knonw denominator. Thus, they can be replaced by
+their multiplication/shift counterpart. Finally, all other
+multiplications or divisions by a power of two have been replaced by
+left or right bit shifts. By the way, the code only contains
+additions, substractions and multiplications of signed integers, which
+is perfectly adapted to FGPAs.
+
+As said above, hardware constraints have a great influence on the VHDL
+implementation. Consequently, we searched the maximum value of each
+variable as a function of the different scale factors and the size of
+profiles, which gives their maximum size in bits. That size determines
+the maximum scale factors that allow to use the least possible RAMs
+and DSPs. Actually, we implemented our algorithm with this maximum
+size but current works study the impact of quantization on the results
+precision and design complexity. We have compared the result of the
+LSQ version using integers and doubles and observed that the precision
+of both were similar.
+
+Then we built two versions of VHDL codes: one directly by hand coding
+and the other with Matlab using the Simulink HDL coder
+feature~\cite{HDLCoder}. Although the approach is completely different
+we obtained VHDL codes that are quite comparable. Each approach has
+advantages and drawbacks.  Roughly speaking, hand coding provides
+beautiful and much better structured code while Simulink allows to
+produce a code faster.  In terms of throughput and latency,
+simulations shows that the two approaches are close with a slight
+advantage for hand coding.  We hope that real experiments will confirm
+that.
 
 \subsection{Simulation}
 
 
 \subsection{Simulation}
 
diff --git a/lever-xp.jpg b/lever-xp.jpg
new file mode 100644 (file)
index 0000000..37beb08
Binary files /dev/null and b/lever-xp.jpg differ