diff --git a/ifcs2018_proceeding.tex b/ifcs2018_proceeding.tex index d74da7d..58bee8a 100644 --- a/ifcs2018_proceeding.tex +++ b/ifcs2018_proceeding.tex @@ -67,7 +67,8 @@ As with the analog mixer, the non-linear behavior of the downconverter introduces noise or spurious signal aliasing as well as the generation of the frequency sum signal in addition to the frequency difference. These unwanted spectral characteristics must be rejected before decimating the data stream -for the phase noise spectral characterization. The characteristics introduced between the downconverter +for the phase noise spectral characterization. The characteristics introduced between the +downconverter and the decimation processing blocks are core characteristics of an oscillator characterization system, and must reject out-of-band signals below the targeted phase noise -- typically in the sub -170~dBc/Hz for ultrastable oscillator we aim at characterizing. The filter blocks will @@ -81,13 +82,20 @@ data being processed. \section{Finite impulse response filter} We select FIR filter for their unconditional stability and ease of design. A FIR filter is defined -by a set of weights $b_k$ applied to the inputs $x_k$ through a convolution to generate the outputs $y_k$ +by a set of weights $b_k$ applied to the inputs $x_k$ through a convolution to generate the +outputs $y_k$ $$y_n=\sum_{k=0}^N b_k x_{n-k}$$ As opposed to an implementation on a general purpose processor in which word size is defined by the processor architecture, implementing such a filter on an FPGA offer more degrees of freedom since -not only the coefficient values and number of taps must be defined, but also the number of bits defining -the coefficients and the sample size. +not only the coefficient values and number of taps must be defined, but also the number of bits +defining the coefficients and the sample size. For this reason, and because we consider pipeline +processing (as opposed to First-In, First-Out memory batch processing) of radiofrequency +signals, High Level Synthesis (HLS) languages \cite{kasbah2008multigrid} are not considered but +the problem is tackled at the Very-high-speed-integrated-circuit Hardware Description Language (VHDL). +Since latency is not an issue in a openloop phase noise characterization instrument, the large +numbre of taps in the FIR, as opposed to the shorter Infinite Impulse Response (IIR) filter, +is not considered as an issue as would be in a closed loop system. The coefficients are classically expressed as floating point values. However, this binary number representation is not efficient for fast arithmetic computation by an FPGA. Instead, @@ -242,63 +250,14 @@ The authors would like to thank E. Rubiola, F. Vernotte, G. Cabodevila for suppo fruitful discussions. +XXX \subsubsection{Contraintes} - \label{def-contraintes} - Maintenant que nous avons d\'efini ce qu'\'etait une chaine de traitement, nous allons voir - quelles sont les contraintes li\'ees à celles-ci. - - Le temps d'ex\'ecution des t\^aches se compte en front montant d'horloge souvent appel\'e - coup d'horloge. On a donc une unit\'e de temps discr\'etis\'ee car un coup d'horloge est indivisible. - les dates sont donc cadenc\'ees par l'horloge du FPGA. - - Chaque t\^ache doit pouvoir traiter chaque donn\'ee qui arrive, ce qui impose une contrainte - forte de d\'ebit d'entr\'ee. En effet, dans le cadre du traitement du signal, il est primordial - d'avoir toutes les donn\'ees de manière cons\'ecutive. Si la moindre donn\'ee est perdue, le r\'esultat - obtenu n'est plus valide. Cette contrainte se traduit la plupart du temps par de m\'ecanisme de - FIFO qui bufferise les donn\'ees entrantes (dans le cas où la t\^ache n\'ecessite en tableau de donn\'ees, - par exemple). Ou cela peut aussi se mettre en place par un m\'ecanisme de pipeline ou de parall\'elisme - à l'int\'erieur du bloc. Mais cela relève de l'impl\'ementation bas niveau du bloc. - - Le temps d'ex\'ecution d'une t\^ache correspond à la latence d'un bloc. Il s'agit donc du - temps que passe une donn\'ee brute dans le bloc avant de ressortir trait\'ee. Dans notre contexte - la latence n'est pas importante. En effet, puisqu'on a un flux de donn\'ees continu, après un court laps - de temps toutes les t\^aches ont d\'epass\'e leur temps de latence et elles produisent les donn\'ees - r\'egulièrement. - - Il y a tout de même une exception à cela, c'est lors d'un traitement parallèle. Dans l'exemple de la - figure \ref{exemple-chaine-traitement}, on voit un bloc qui divise le flux en deux branches. Dans le - cas où on resynchronise le flux, il est imp\'eratif que la somme des latences des deux branches soit la - même. Cela peut donc imposer la pr\'esence de blocs qui ajoutent de la latence sans faire de traitements utiles. - - En revanche, une t\^ache se caract\'erise par un d\'ebit de sortie et celui-ci doit rester fixe. - Cela s'explique par la contrainte du d\'ebit d'entr\'ee du bloc de traitement suivant. Si un bloc a un d\'ebit de sortie - fluctuant, il est \'evident que la contrainte d'entr\'ee ne sera pas possible à formaliser. - - Une autre contrainte li\'ee de manière plus globale est la consommation de ressources. Comme nous l'avons - dit dans la section \ref{def-fpga}, le FPGA dispose d'un nombre de portes logiques limit\'e. - Il faut donc que la chaine de traitement ne d\'epasse pas le nombre de ressources dont dispose la puce - FPGA. - - La consommation de ressources est influenc\'ee par les blocs de traitement. En effet, pour pouvoir - tenir les d\'ebits d'entr\'ee \'elev\'ees, cela consomme \'enorm\'ement de ressources. Plus le d\'ebit est rapide, plus - la consommation de ressources sera grande. - - \subsection{Travaux traitant du sujet} - Nous avons commenc\'e notre recherche en lisant des articles traitant de l'optimisation dans un FPGA. - Dans sa thèse, S. Mirzaei \cite{these-dsp-fpga} donne surtout des bonnes pratiques pour d\'evelopper - des composants FPGA bas niveau. Ce n'est pas exactement ce que nous cherchions. Dans les r\'ef\'erences \cite{zhuo2007scalable, olariu1993computing, pan1999improved}, les auteurs proposent tous des optimisations hardware uniquement. Cependant ces articles sont focalis\'es sur des optimisations mat\'erielles or notre objectif est de trouver une formalisation math\'ematique d'un FPGA. - Une autre approche est propos\'ee par S. Kasbah et al. dans leur article \cite{kasbah2008multigrid}. - En effet, ils utilisent une approche HLS de leur problème. Ils ont utilis\'e un synth\'etiseur optimis\'e et - un langage d\'eriv\'e du C++ pour d\'ecrire leur algorithme. Bien qu'ils obtiennent de bons r\'esultats, - leur m\'ethode n'est pas exploitable dans notre cas, car ils n'ont pas les mêmes contraintes de d\'ebit et - de temps r\'eel que nous. - Une dernière approche que nous avons \'etudi\'ee est l'utilisation de \emph{skeletons}. D. Crookes et A. Benkrid ont beaucoup parl\'e de cette m\'ethode dans leur articles \cite{crookes1998environment, crookes2000design, benkrid2002towards}. L'id\'ee essentielle est qu'ils r\'ealisent des composants très optimis\'es et param\'etrables. Ainsi lorsqu'ils @@ -317,8 +276,6 @@ fruitful discussions. ces blocs en Prolog pour faire un langage descriptif permettant d'assembler les blocs de manière optimale. En partant de cette description, ils arrivent à g\'en\'erer directement le code VHDL. - G. Goavec-Merou, dans sa thèse\cite{gwen-cogen}, pr\'esente un outil, CoGen, bas\'e sur l'approche en skeletons. Son id\'ee - est de caract\'eriser des blocs \'ecrits en VHDL, en donnant diff\'erents caract\'eristiques : \begin{itemize} \item la latence du bloc repr\'esente, en coups d'horloge, le temps entre l'entr\'ee de la donn\'ee et le temps où la même donn\'ee ressort du bloc.