FIFO et HLS

jfriedt
1 parent 6dfba800f9
Showing 1 changed file with 13 additions and 56 deletions Side-by-side Diff
ifcs2018_proceeding.tex
@@ -67,7 +67,8 @@
 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 @@
 \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 @@
 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 @@
 	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.
...	...	@@ -67,7 +67,8 @@
67	67	the non-linear behavior of the downconverter introduces noise or spurious signal aliasing as
68	68	well as the generation of the frequency sum signal in addition to the frequency difference.
69	69	These unwanted spectral characteristics must be rejected before decimating the data stream
70		-for the phase noise spectral characterization. The characteristics introduced between the downconverter
	70	+for the phase noise spectral characterization. The characteristics introduced between the
	71	+downconverter
71	72	and the decimation processing blocks are core characteristics of an oscillator characterization
72	73	system, and must reject out-of-band signals below the targeted phase noise -- typically in the
73	74	sub -170~dBc/Hz for ultrastable oscillator we aim at characterizing. The filter blocks will
74	75
...	...	@@ -81,13 +82,20 @@
81	82	\section{Finite impulse response filter}
82	83
83	84	We select FIR filter for their unconditional stability and ease of design. A FIR filter is defined
84		-by a set of weights $b_k$ applied to the inputs $x_k$ through a convolution to generate the outputs $y_k$
	85	+by a set of weights $b_k$ applied to the inputs $x_k$ through a convolution to generate the
	86	+outputs $y_k$
85	87	$$y_n=\sum_{k=0}^N b_k x_{n-k}$$
86	88
87	89	As opposed to an implementation on a general purpose processor in which word size is defined by the
88	90	processor architecture, implementing such a filter on an FPGA offer more degrees of freedom since
89		-not only the coefficient values and number of taps must be defined, but also the number of bits defining
90		-the coefficients and the sample size.
	91	+not only the coefficient values and number of taps must be defined, but also the number of bits
	92	+defining the coefficients and the sample size. For this reason, and because we consider pipeline
	93	+processing (as opposed to First-In, First-Out memory batch processing) of radiofrequency
	94	+signals, High Level Synthesis (HLS) languages \cite{kasbah2008multigrid} are not considered but
	95	+the problem is tackled at the Very-high-speed-integrated-circuit Hardware Description Language (VHDL).
	96	+Since latency is not an issue in a openloop phase noise characterization instrument, the large
	97	+numbre of taps in the FIR, as opposed to the shorter Infinite Impulse Response (IIR) filter,
	98	+is not considered as an issue as would be in a closed loop system.
91	99
92	100	The coefficients are classically expressed as floating point values. However, this binary
93	101	number representation is not efficient for fast arithmetic computation by an FPGA. Instead,
94	102
95	103
96	104
...	...	@@ -242,63 +250,14 @@
242	250	fruitful discussions.
243	251
244	252
	253	+XXX
245	254
246	255	\subsubsection{Contraintes}
247		- \label{def-contraintes}
248		- Maintenant que nous avons d\'efini ce qu'\'etait une chaine de traitement, nous allons voir
249		- quelles sont les contraintes li\'ees à celles-ci.
250	256
251		- Le temps d'ex\'ecution des t\^aches se compte en front montant d'horloge souvent appel\'e
252		- coup d'horloge. On a donc une unit\'e de temps discr\'etis\'ee car un coup d'horloge est indivisible.
253		- les dates sont donc cadenc\'ees par l'horloge du FPGA.
254		-
255		- Chaque t\^ache doit pouvoir traiter chaque donn\'ee qui arrive, ce qui impose une contrainte
256		- forte de d\'ebit d'entr\'ee. En effet, dans le cadre du traitement du signal, il est primordial
257		- d'avoir toutes les donn\'ees de manière cons\'ecutive. Si la moindre donn\'ee est perdue, le r\'esultat
258		- obtenu n'est plus valide. Cette contrainte se traduit la plupart du temps par de m\'ecanisme de
259		- FIFO qui bufferise les donn\'ees entrantes (dans le cas où la t\^ache n\'ecessite en tableau de donn\'ees,
260		- par exemple). Ou cela peut aussi se mettre en place par un m\'ecanisme de pipeline ou de parall\'elisme
261		- à l'int\'erieur du bloc. Mais cela relève de l'impl\'ementation bas niveau du bloc.
262		-
263		- Le temps d'ex\'ecution d'une t\^ache correspond à la latence d'un bloc. Il s'agit donc du
264		- temps que passe une donn\'ee brute dans le bloc avant de ressortir trait\'ee. Dans notre contexte
265		- la latence n'est pas importante. En effet, puisqu'on a un flux de donn\'ees continu, après un court laps
266		- de temps toutes les t\^aches ont d\'epass\'e leur temps de latence et elles produisent les donn\'ees
267		- r\'egulièrement.
268		-
269		- Il y a tout de même une exception à cela, c'est lors d'un traitement parallèle. Dans l'exemple de la
270		- figure \ref{exemple-chaine-traitement}, on voit un bloc qui divise le flux en deux branches. Dans le
271		- cas où on resynchronise le flux, il est imp\'eratif que la somme des latences des deux branches soit la
272		- même. Cela peut donc imposer la pr\'esence de blocs qui ajoutent de la latence sans faire de traitements utiles.
273		-
274		- En revanche, une t\^ache se caract\'erise par un d\'ebit de sortie et celui-ci doit rester fixe.
275		- 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
276		- fluctuant, il est \'evident que la contrainte d'entr\'ee ne sera pas possible à formaliser.
277		-
278		- Une autre contrainte li\'ee de manière plus globale est la consommation de ressources. Comme nous l'avons
279		- dit dans la section \ref{def-fpga}, le FPGA dispose d'un nombre de portes logiques limit\'e.
280		- Il faut donc que la chaine de traitement ne d\'epasse pas le nombre de ressources dont dispose la puce
281		- FPGA.
282		-
283		- La consommation de ressources est influenc\'ee par les blocs de traitement. En effet, pour pouvoir
284		- tenir les d\'ebits d'entr\'ee \'elev\'ees, cela consomme \'enorm\'ement de ressources. Plus le d\'ebit est rapide, plus
285		- la consommation de ressources sera grande.
286		-
287		- \subsection{Travaux traitant du sujet}
288		- Nous avons commenc\'e notre recherche en lisant des articles traitant de l'optimisation dans un FPGA.
289		- Dans sa thèse, S. Mirzaei \cite{these-dsp-fpga} donne surtout des bonnes pratiques pour d\'evelopper
290		- des composants FPGA bas niveau. Ce n'est pas exactement ce que nous cherchions.
291		-
292	257	Dans les r\'ef\'erences \cite{zhuo2007scalable, olariu1993computing, pan1999improved}, les auteurs
293	258	proposent tous des optimisations hardware uniquement. Cependant ces articles sont focalis\'es sur des optimisations mat\'erielles
294	259	or notre objectif est de trouver une formalisation math\'ematique d'un FPGA.
295	260
296		- Une autre approche est propos\'ee par S. Kasbah et al. dans leur article \cite{kasbah2008multigrid}.
297		- En effet, ils utilisent une approche HLS de leur problème. Ils ont utilis\'e un synth\'etiseur optimis\'e et
298		- un langage d\'eriv\'e du C++ pour d\'ecrire leur algorithme. Bien qu'ils obtiennent de bons r\'esultats,
299		- leur m\'ethode n'est pas exploitable dans notre cas, car ils n'ont pas les mêmes contraintes de d\'ebit et
300		- de temps r\'eel que nous.
301		-
302	261	Une dernière approche que nous avons \'etudi\'ee est l'utilisation de \emph{skeletons}. D. Crookes et A. Benkrid
303	262	ont beaucoup parl\'e de cette m\'ethode dans leur articles \cite{crookes1998environment, crookes2000design, benkrid2002towards}.
304	263	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 @@
317	276	ces blocs en Prolog pour faire un langage descriptif permettant d'assembler les blocs de manière
318	277	optimale. En partant de cette description, ils arrivent à g\'en\'erer directement le code VHDL.
319	278
320		- 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
321		- est de caract\'eriser des blocs \'ecrits en VHDL, en donnant diff\'erents caract\'eristiques :
322	279	\begin{itemize}
323	280	\item la latence du bloc repr\'esente, en coups d'horloge, le temps entre l'entr\'ee de la donn\'ee
324	281	et le temps où la même donn\'ee ressort du bloc.