-pixels and to store them in memory, ... the phase computation is
-obviously the bottle-neck of the whole process. For example, if we
-consider the camera actually in use, an exposition time of 2.5ms for
-$1024\times 1204$ pixels seems the minimum that can be reached. For
-100 cantilevers, if we neglect the time to extract pixels, it implies
-that computing the deflection of a single
-cantilever should take less than 25$\mu$s, thus 12.5$\mu$s by phase.\\
-
-In fact, this timing is a very hard constraint. Let consider a very
-small programm that initializes twenty million of doubles in memory
-and then does 1000000 cumulated sums on 20 contiguous values
-(experimental profiles have about this size). On an intel Core 2 Duo
-E6650 at 2.33GHz, this program reaches an average of 155Mflops.
-
-%%Itimplies that the phase computation algorithm should not take more than
-%%$155\times 12.5 = 1937$ floating operations. For integers, it gives $3000$ operations.
-
-Obviously, some cache effects and optimizations on
-huge amount of computations can drastically increase these
-performances : peak efficiency is about 2.5Gflops for the considered
-CPU. But this is not the case for phase computation that used only few
-tenth of values.\\
-
-In order to evaluate the original algorithm, we translated it in C
-language. As said further, for 20 pixels, it does about 1550
-operations, thus an estimated execution time of $1550/155
-=$10$\mu$s. For a more realistic evaluation, we constructed a file of
-1Mo containing 200 profiles of 20 pixels, equally scattered. This file
-is equivalent to an image stored in a device file representing the
-camera. We obtained an average of 10.5$\mu$s by profile (including I/O
-accesses). It is under are requirements but close to the limit. In
-case of an occasional load of the system, it could be largely
-overtaken. A solution would be to use a real-time operating system but
-another one to search for a more efficient algorithm.
-
-But the main drawback is the latency of such a solution : since each
-profile must be treated one after another, the deflection of 100
-cantilevers takes about $200\times 10.5 = 2.1$ms, which is inadequate
-for an efficient control. An obvious solution is to parallelize the
-computations, for example on a GPU. Nevertheless, the cost to transfer
-profile in GPU memory and to take back results would be prohibitive
-compared to computation time. It is certainly more efficient to
-pipeline the computation. For example, supposing that 200 profiles of
-20 pixels can be pushed sequentially in the pipelined unit cadenced at
-a 100MHz (i.e. a pixel enters in the unit each 10ns), all profiles
-would be treated in $200\times 20\times 10.10^{-9} =$ 40$\mu$s plus
-the latency of the pipeline. This is about 500 times faster than
-actual results.\\
-
-For these reasons, an FPGA as the computation unit is the best choice
-to achieve the required performance. Nevertheless, passing from
-a C code to a pipelined version in VHDL is not obvious at all. As
-explained in the next section, it can even be impossible because of
-some hardware constraints specific to FPGAs.
-
-
-\section{Proposed solution}
+pixels and to store them in memory, the phase computation is the
+bottleneck of the whole process. For example, the camera in the setup
+of \cite{AFMCSEM11} provides $%
+1024\times 1204$ pixels with an exposition time of 2.5ms. Thus, if we
+the pixel extraction time is neglected, each phase calculation of a
+100-cantilever array should take no more than 12.5$\mu$s.
+
+In fact, this timing is a very hard constraint. To illustrate this point, we
+consider a very small program that initializes twenty million of doubles in
+memory and then does 1,000,000 cumulated sums on 20 contiguous values
+(experimental profiles have about this size). On an intel Core 2 Duo E6650
+at 2.33GHz, this program reaches an average of 155Mflops.
+Obviously, some cache effects and optimizations on huge amount of
+computations can drastically increase these performances: peak efficiency is
+about 2.5Gflops for the considered CPU. But this is not the case for phase
+computation that is using only a few tenth of values.
+
+In order to evaluate the original algorithm, we translated it in C language.
+As stated before, for 20 pixels, it does about 1,550 operations, thus an
+estimated execution time of $1,550/155=$10$\mu $s. For a more realistic
+evaluation, we constructed a file of 1Mo containing 200 profiles of 20
+pixels, equally scattered. This file is equivalent to an image stored in a
+device file representing the camera. We obtained an average of 10.5$\mu$s
+by profile (including I/O accesses). It is under our requirements but close
+to the limit. In case of an occasional load of the system, it could be
+largely overtaken. Solutions would be to use a real-time operating system or
+to search for a more efficient algorithm.
+
+However, the main drawback is the latency of such a solution because each
+profile must be treated one after another and the deflection of 100
+cantilevers takes about $200\times 10.5=2.1$ms. This would be inadequate
+for real-time requirements as for individual cantilever active control. An
+obvious solution is to parallelize the computations, for example on a GPU.
+Nevertheless, the cost of transferring profile in GPU memory and of taking
+back results would be prohibitive compared to computation time.
+
+We remark that when possible, it is more efficient to pipeline the
+computation. For example, supposing that 200 profiles of 20 pixels
+could be pushed sequentially in a pipelined unit cadenced at a 100MHz
+(i.e. a pixel enters in the unit each 10ns), all profiles would be
+treated in $200\times 20\times 10.10^{-9}=$ 40$\mu$s plus the latency
+of the pipeline. Such a solution would be meeting our requirements and
+would be 50 times faster than our C code, and even more compared to
+the LabView version use in \cite{AFMCSEM11}. FPGAs are appropriate for
+such implementation, so they turn out to be the computation units of
+choice to reach our performance requirements. Nevertheless, passing
+from a C code to a pipelined version in VHDL is not obvious at all. It
+can even be impossible because of FPGA hardware constraints. All these
+points are discussed in the following sections.
+
+\section{An hardware/software solution}
+
