jfriedt / IFCS2018 article

Download as
Browse Code »

Commit 6dfba800f965ef6546d303f7c3bea1a0b80f39bb

Authored by jfriedt
1 parent ee2ff04c62
Exists in master

complement a la partie filtre et inclusion du rapport de fin de M2 dont on pourr… 

…a s'inspirer pour expliquer la simu

Showing 3 changed files with 560 additions and 12 deletions Side-by-side Diff

... ... @@ -12,7 +12,7 @@
12 12 view_poster: $(TARGET)_poster
13 13 evince $(TARGET)_poster.pdf
14 14  
15   -$(TARGET)_abstract: $(TARGET)_abstract.tex references.bib
  15 +$(TARGET)_abstract: $(TARGET)_abstract.tex references.bib biblio.bib
16 16 $(TEX) $@.tex
17 17 $(BIB) $@
18 18 $(TEX) $@.tex
... ... @@ -22,7 +22,7 @@
22 22 $(TEX) $@.tex
23 23 $(TEX) $@.tex
24 24  
25   -$(TARGET)_proceeding: $(TARGET)_proceeding.tex references.bib
  25 +$(TARGET)_proceeding: $(TARGET)_proceeding.tex references.bib biblio.bib
26 26 $(TEX) $@.tex
27 27 $(BIB) $@
28 28 $(TEX) $@.tex
  1 +@thesis{gwen-cogen,
  2 +author = {Gwenhaël Goavec-Merou},
  3 +title = {Générateur de coprocesseur pour le traitement de données en flux (vidéo ou similaire) sur FPGA},
  4 +institution = {FEMTO-ST},
  5 +year = {2014}
  6 +}
  7 +
  8 +@article{hide,
  9 + title={HIDE: A hardware intelligent description environment},
  10 + author={Benkrid, Khaled and Belkacemi, S and Benkrid, Abdsamad},
  11 + journal={Microprocessors and Microsystems},
  12 + volume={30},
  13 + number={6},
  14 + pages={283--300},
  15 + year={2006},
  16 + publisher={Elsevier}
  17 +}
  18 +
  19 +@inproceedings{skeleton,
  20 + title={High level programming for FPGA based image and video processing using hardware skeletons},
  21 + author={Benkrid, Khaled and Crookes, Danny and Smith, J and Benkrid, Abdsamad},
  22 + booktitle={Field-Programmable Custom Computing Machines, 2001. FCCM'01. The 9th Annual IEEE Symposium on},
  23 + pages={219--226},
  24 + year={2001},
  25 + organization={IEEE}
  26 +}
  27 +
  28 +@article{benkrid2004application,
  29 + title={From application descriptions to hardware in seconds: a logic-based approach to bridging the gap},
  30 + author={Benkrid, Khaled and Crookes, Danny},
  31 + journal={Very Large Scale Integration (VLSI) Systems, IEEE Transactions on},
  32 + volume={12},
  33 + number={4},
  34 + pages={420--436},
  35 + year={2004},
  36 + publisher={IEEE}
  37 +}
  38 +
  39 +@phdthesis{these-dsp-fpga,
  40 + title={Design methodologies and architectures for digital signal processing on FPGAs},
  41 + author={Mirzaei, Shahnam},
  42 + year={2010},
  43 + school={UNIVERSITY OF CALIFORNIA SANTA BARBARA}
  44 +}
  45 +
  46 +@article{def1-ordo,
  47 + title={Algorithmique Parallèle-Cours Et Exercices Corrigés},
  48 + author={Legrand, Arnaud and Robert, Yves},
  49 + year={2003},
  50 + publisher={Dunod}
  51 +}
  52 +
  53 +@article{these-mathias,
  54 + title={Optimisation du débit pour des applications linéaires multi-tâches sur plateformes distribuées incluant des temps de reconfiguration},
  55 + author={Coqblin, Mathias},
  56 + institution = {FEMTO-ST},
  57 + year={2012}
  58 +}
  59 +
  60 +@thesis{these-alex,
  61 +author = {Alexandru Dobrila},
  62 +title = {Optimisation du débit en environnement distribué incertain},
  63 +institution = {FEMTO-ST},
  64 +year = {2011}
  65 +}
  66 +
  67 +@book{def2-ordo,
  68 + title={Handbook of scheduling: algorithms, models, and performance analysis},
  69 + author={Leung, Joseph YT},
  70 + year={2004},
  71 + publisher={CRC Press}
  72 +}
  73 +
  74 +@inproceedings{def-ordo-en-ligne,
  75 + title={On the Definition of "On-Line" in Job Scheduling Problems},
  76 + author={Feitelson, Dror G and Mu'alem, Ahuva W},
  77 + booktitle={SIGACT NEWS},
  78 + year={2000},
  79 + organization={Citeseer}
  80 +}
  81 +
  82 +@article{shmueli2005backfilling,
  83 + title={Backfilling with lookahead to optimize the packing of parallel jobs},
  84 + author={Shmueli, Edi and Feitelson, Dror G},
  85 + journal={Journal of Parallel and Distributed Computing},
  86 + volume={65},
  87 + number={9},
  88 + pages={1090--1107},
  89 + year={2005},
  90 + publisher={Elsevier}
  91 +}
  92 +
  93 +@article{graham1979optimization,
  94 + title={Optimization and approximation in deterministic sequencing and scheduling: a survey},
  95 + author={Graham, Ronald L and Lawler, Eugene L and Lenstra, Jan Karel and Kan, AHG Rinnooy},
  96 + journal={Annals of discrete mathematics},
  97 + volume={5},
  98 + pages={287--326},
  99 + year={1979},
  100 + publisher={Elsevier}
  101 +}
  102 +
  103 +@article{salvador2012accelerating,
  104 + title={Accelerating FPGA-based evolution of wavelet transform filters by optimized task scheduling},
  105 + author={Salvador, Ruben and Vidal, Alberto and Moreno, Felix and Riesgo, Teresa and Sekanina, Lukas},
  106 + journal={Microprocessors and Microsystems},
  107 + volume={36},
  108 + number={5},
  109 + pages={427--438},
  110 + year={2012},
  111 + publisher={Elsevier}
  112 +}
  113 +
  114 +@article{zhuo2007scalable,
  115 + title={Scalable and modular algorithms for floating-point matrix multiplication on reconfigurable computing systems},
  116 + author={Zhuo, Ling and Prasanna, Viktor K},
  117 + journal={Parallel and Distributed Systems, IEEE Transactions on},
  118 + volume={18},
  119 + number={4},
  120 + pages={433--448},
  121 + year={2007},
  122 + publisher={IEEE}
  123 +}
  124 +
  125 +@article{olariu1993computing,
  126 + title={Computing the Hough transform on reconfigurable meshes},
  127 + author={Olariu, Stephan and Schwing, James L and Zhang, Jingyuan},
  128 + journal={Image and vision computing},
  129 + volume={11},
  130 + number={10},
  131 + pages={623--628},
  132 + year={1993},
  133 + publisher={Elsevier}
  134 +}
  135 +
  136 +@article{pan1999improved,
  137 + title={An improved constant-time algorithm for computing the Radon and Hough transforms on a reconfigurable mesh},
  138 + author={Pan, Yi and Li, Keqin and Hamdi, Mounir},
  139 + journal={Systems, Man and Cybernetics, Part A: Systems and Humans, IEEE Transactions on},
  140 + volume={29},
  141 + number={4},
  142 + pages={417--421},
  143 + year={1999},
  144 + publisher={IEEE}
  145 +}
  146 +
  147 +@article{kasbah2008multigrid,
  148 + title={Multigrid solvers in reconfigurable hardware},
  149 + author={Kasbah, Safaa J and Damaj, Issam W and Haraty, Ramzi A},
  150 + journal={Journal of Computational and Applied Mathematics},
  151 + volume={213},
  152 + number={1},
  153 + pages={79--94},
  154 + year={2008},
  155 + publisher={Elsevier}
  156 +}
  157 +
  158 +@inproceedings{crookes1998environment,
  159 + title={An environment for generating FPGA architectures for image algebra-based algorithms},
  160 + author={Crookes, Danny and Alotaibi, Khalid and Bouridane, Ahmed and Donachy, Paul and Benkrid, Abdsamad},
  161 + booktitle={Image Processing, 1998. ICIP 98. Proceedings. 1998 International Conference on},
  162 + pages={990--994},
  163 + year={1998},
  164 + organization={IEEE}
  165 +}
  166 +
  167 +@article{crookes2000design,
  168 + title={Design and implementation of a high level programming environment for FPGA-based image processing},
  169 + author={Crookes, D and Benkrid, K and Bouridane, A and Alotaibi, K and Benkrid, A},
  170 + journal={IEE Proceedings-Vision, Image and Signal Processing},
  171 + volume={147},
  172 + number={4},
  173 + pages={377--384},
  174 + year={2000},
  175 + publisher={IET}
  176 +}
  177 +
  178 +@article{benkrid2002towards,
  179 + title={Towards a general framework for FPGA based image processing using hardware skeletons},
  180 + author={Benkrid, Khaled and Crookes, Danny and Benkrid, Abdsamad},
  181 + journal={Parallel Computing},
  182 + volume={28},
  183 + number={7},
  184 + pages={1141--1154},
  185 + year={2002},
  186 + publisher={Elsevier}
  187 +}
ifcs2018_proceeding.tex
Diff comments   View file @ 6dfba80
1 1 \documentclass[a4paper,conference]{IEEEtran/IEEEtran}
2 2 \usepackage{graphicx,color,hyperref}
3 3 \usepackage{amsfonts}
  4 +\usepackage{amsthm}
  5 +\usepackage{amssymb}
  6 +\usepackage{amsmath}
4 7 \usepackage{url}
5 8 \usepackage[normalem]{ulem}
6 9 \graphicspath{{/home/jmfriedt/gpr/170324_avalanche/}{/home/jmfriedt/gpr/1705_homemade/}}
... ... @@ -23,6 +26,7 @@
23 26 \maketitle
24 27 \thispagestyle{plain}
25 28 \pagestyle{plain}
  29 +\newtheorem{definition}{Definition}
26 30  
27 31 \begin{abstract}
28 32 Software Defined Radio (SDR) provides stability, flexibility and reconfigurability to
29 33  
30 34  
31 35  
32 36  
... ... @@ -88,17 +92,30 @@
88 92 The coefficients are classically expressed as floating point values. However, this binary
89 93 number representation is not efficient for fast arithmetic computation by an FPGA. Instead,
90 94 we select to quantify these floating point values into integer values. This quantization
91   -will result in some precision loss. As illustrated in Fig. \ref{float_vs_int}, we see that we aren't
92   -need too coefficients or too sample size. If we have lot of coefficients but a small sample size,
93   -the first and last are equal to zero. But if we have too sample size for few coefficients that not improve the quality.
  95 +will result in some precision loss.
94 96  
  97 +%As illustrated in Fig. \ref{float_vs_int}, we see that we aren't
  98 +%need too coefficients or too sample size. If we have lot of coefficients but a small sample size,
  99 +%the first and last are equal to zero. But if we have too sample size for few coefficients that not improve the quality.
  100 +
95 101 % JMF je ne comprends pas la derniere phrase ci-dessus ni la figure ci dessous
96   -\begin{figure}[h!tb]
97   -\includegraphics[width=\linewidth]{images/float-vs-integer.pdf}
98   -\caption{Impact of the quantization resolution of the coefficients}
  102 +%\begin{figure}[h!tb]
  103 +%\includegraphics[width=\linewidth]{images/float-vs-integer.pdf}
  104 +%\caption{Impact of the quantization resolution of the coefficients}
99 105 %\label{float_vs_int}
100   -\end{figure}
  106 +%\end{figure}
101 107  
  108 +The tradeoff between quantization resolution and number of coefficients when considering
  109 +integer operations is not trivial. As an illustration of the issue related to the
  110 +relation between number of fiter taps and quantization, Fig. \ref{float_vs_int} exhibits
  111 +a 128-coefficient FIR bandpass filter designed using floating point numbers (blue). Upon
  112 +quantization on 6~bit integers, 60 of the 128~coefficients in the beginning and end of the
  113 +taps become null, making the large number of coefficients irrelevant and allowing to save
  114 +processing resource by shrinking the filter length. This tradeoff aimed at minimizing resources
  115 +to reach a given rejection level, or maximizing out of band rejection for a given computational
  116 +resource, will drive the investigation on cascading filters designed with varying tap resolution
  117 +and tap length, as will be shown in the next section.
  118 +
102 119 \begin{figure}[h!tb]
103 120 \includegraphics[width=\linewidth]{images/demo_filtre}
104 121 \caption{Impact of the quantization resolution of the coefficients: the quantization is
... ... @@ -107,7 +124,6 @@
107 124 \label{float_vs_int}
108 125 \end{figure}
109 126  
110   -
111 127 \section{Filter optimization}
112 128  
113 129 A basic approach for implementing the FIR filter is to compute the transfer function of
... ... @@ -130,7 +146,6 @@
130 146 trivial. The resource occupation of a FIR filter is considered as $c_i+d_i+\log_2(N_i)$ which is
131 147 the number of bits needed in a worst case condition to represent the output of the FIR.
132 148  
133   -
134 149 \begin{figure}[h!tb]
135 150 \includegraphics[width=\linewidth]{images/noise-rejection.pdf}
136 151 \caption{Rejection as a function of number of coefficients and number of bits}
137 152  
... ... @@ -226,7 +241,351 @@
226 241 The authors would like to thank E. Rubiola, F. Vernotte, G. Cabodevila for support and
227 242 fruitful discussions.
228 243  
  244 +
  245 +
  246 + \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 +
  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 + Dans les r\'ef\'erences \cite{zhuo2007scalable, olariu1993computing, pan1999improved}, les auteurs
  293 + proposent tous des optimisations hardware uniquement. Cependant ces articles sont focalis\'es sur des optimisations mat\'erielles
  294 + or notre objectif est de trouver une formalisation math\'ematique d'un FPGA.
  295 +
  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 + Une dernière approche que nous avons \'etudi\'ee est l'utilisation de \emph{skeletons}. D. Crookes et A. Benkrid
  303 + ont beaucoup parl\'e de cette m\'ethode dans leur articles \cite{crookes1998environment, crookes2000design, benkrid2002towards}.
  304 + L'id\'ee essentielle est qu'ils r\'ealisent des composants très optimis\'es et param\'etrables. Ainsi lorsqu'ils
  305 + veulent faire un d\'eveloppement, ils utilisent les blocs d\'ejà faits.
  306 +
  307 + Ces blocs repr\'esentent une \'etape de calcul (une d\'ecimation, un filtrage, une modulation, une
  308 + d\'emodulation etc...). En prenant le cas du FIR, on rend param\'etrables les valeurs des coefficients
  309 + utilis\'es pour le produit de convolutions ainsi que leur nombre. Le facteur de d\'ecimation est
  310 + lui aussi param\'etrable.
  311 +
  312 + On gagne ainsi beaucoup de temps de d\'eveloppement car on r\'eutilise des composants d\'ejà \'eprouv\'es et optimis\'es.
  313 + De plus, au fil des projets, on constitue une bibliothèque de composants nous
  314 + permettant de faire une chaine complète très simplement.
  315 +
  316 + K. Benkrid, S. Belkacemi et A. Benkrid dans leur article\cite{hide} caract\'erisent
  317 + ces blocs en Prolog pour faire un langage descriptif permettant d'assembler les blocs de manière
  318 + optimale. En partant de cette description, ils arrivent à g\'en\'erer directement le code VHDL.
  319 +
  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 + \begin{itemize}
  323 + \item la latence du bloc repr\'esente, en coups d'horloge, le temps entre l'entr\'ee de la donn\'ee
  324 + et le temps où la même donn\'ee ressort du bloc.
  325 + \item l'acceptance repr\'esente le nombre de donn\'ees par coup d'horloge que le bloc est capable
  326 + de traiter.
  327 + \item la sortance repr\'esente le nombre de donn\'ees qui sortent par coup d'horloge.
  328 + \end{itemize}
  329 +
  330 + Gr\^ace à cela, le logiciel est capable de donner une impl\'ementation optimale d'un problème qu'on lui
  331 + soumet. Le problème ne se d\'efinit pas uniquement par un r\'esultat attendu mais aussi par des
  332 + contraintes de d\'ebit et/ou de pr\'ecision.
  333 +
  334 + Dans une second temps, nous nous sommes aussi int\'eress\'es à des articles d'ordonnancement.
  335 + Nous avons notamment lu des documents parlant des cas des micro-usines.
  336 +
  337 + Les micro-usines ressemblent un peu à des FPGA dans le sens où on connait à l'avance les
  338 + t\^aches à effectuer et leurs caract\'eristiques. Nous allons donc nous inspirer
  339 + de leur modèle pour essayer de construire le notre.
  340 +
  341 + Dans sa thèse A. Dobrila \cite{these-alex} traite d'un problème de tol\'erance aux pannes
  342 + dans le contextes des mirco-usines. Mais les FPGA ne sont pas concern\'es dans la mesure
  343 + où si le composant tombe en panne, tout le traitement est paralys\'e. Cette thèse nous a n\'eanmoins
  344 + permis d'avoir un exemple de formalisation de problème.
  345 +
  346 + Pour finir nous avons lu la thèse de M. Coqblin \cite{these-mathias} qui elle aussi traite du sujet
  347 + des micro-usines. Le travail de M. Coqblin porte surtout sur une chaine de traitement
  348 + reconfigurable, il tient compte dans ses travaux du surcoût engendr\'e par la reconfiguration d'une machine.
  349 + Cela n'est pas tout à fait exploitable dans notre contexte puisqu'une
  350 + puce FPGA d\'es qu'elle est programm\'ee n'a pas la possibilit\'e de reconfigurer une partie de sa chaine de
  351 + traitement. Là encore, nous avions un exemple de formalisation d'un problème.
  352 +
  353 + Pour conclure, nous avons vu deux approches li\'ees à deux domaines diff\'erents. La première est le
  354 + point de vue \'electronique qui se focalise principalement sur des optimisations mat\'erielles ou algorithmiques.
  355 + La seconde est le point de vue informatique : les modèles sont très g\'en\'eriques et ne sont pas
  356 + adapt\'es au cas des FPGA. La suite de ce rapport se concentrera donc sur la recherche d'un compromis
  357 + entre ces deux points de vue.
  358 +
  359 + \section{Contexte d'ordonnancement}
  360 + Dans cette partie, nous donnerons des d\'efinitions de termes rattach\'es au domaine de l'ordonnancement
  361 + et nous verrons que le sujet trait\'e se rapproche beaucoup d'un problème d'ordonnancement. De ce fait
  362 + nous pourrons aller plus loin que les travaux vus pr\'ec\'edemment et nous tenterons des approches d'ordonnancement
  363 + et d'optimisation.
  364 +
  365 + \subsection{D\'efinition du vocabulaire}
  366 + Avant tout, il faut d\'efinir ce qu'est un problème d'optimisation. Il y a deux d\'efinitions
  367 + importantes à donner. La première est propos\'ee par Legrand et Robert dans leur livre \cite{def1-ordo} :
  368 + \begin{definition}
  369 + \label{def-ordo1}
  370 + Un ordonnancement d'un système de t\^aches $G\ =\ (V,\ E,\ w)$ est une fonction $\sigma$ :
  371 + $V \rightarrow \mathbb{N}$ telle que $\sigma(u) + w(u) \leq \sigma(v)$ pour toute arête $(u,\ v) \in E$.
  372 + \end{definition}
  373 +
  374 + Dit plus simplement, l'ensemble $V$ repr\'esente les t\^aches à ex\'ecuter, l'ensemble $E$ repr\'esente les d\'ependances
  375 + des t\^aches et $w$ les temps d'ex\'ecution de la t\^ache. La fonction $\sigma$ donne donc l'heure de d\'ebut de
  376 + chacune des t\^aches. La d\'efinition dit que si une t\^ache $v$ d\'epend d'une t\^ache $u$ alors
  377 + la date de d\'ebut de $v$ sera plus grande ou \'egale au d\'ebut de l'ex\'ecution de la t\^ache $u$ plus son
  378 + temps d'ex\'ecution.
  379 +
  380 + Une autre d\'efinition importante qui est propos\'ee par Leung et al. \cite{def2-ordo} est :
  381 + \begin{definition}
  382 + \label{def-ordo2}
  383 + L'ordonnancement traite de l'allocation de ressources rares à des activit\'es avec
  384 + l'objectif d'optimiser un ou plusieurs critères de performance.
  385 + \end{definition}
  386 +
  387 + Cette d\'efinition est plus g\'en\'erique mais elle nous int\'eresse d'avantage que la d\'efinition \ref{def-ordo1}.
  388 + En effet, la partie qui nous int\'eresse dans cette première d\'efinition est le respect de la pr\'ec\'edance des t\^aches.
  389 + Dans les faits les dates de d\'ebut ne nous int\'eressent pas r\'eellement.
  390 +
  391 + En revanche la d\'efinition \ref{def-ordo2} sera au c\oe{}ur du projet. Pour se convaincre de cela,
  392 + il nous faut d'abord d\'efinir quel est le type de problème d'ordonnancement qu'on traite et quelles
  393 + sont les m\'ethodes qu'on peut appliquer.
  394 +
  395 + Les problèmes d'ordonnancement peuvent être class\'es en diff\'erentes cat\'egories :
  396 + \begin{itemize}
  397 + \item T\^aches ind\'ependantes : dans cette cat\'egorie de problèmes, les t\^aches sont complètement ind\'ependantes
  398 + les unes des autres. Dans notre cas, ce n'est pas le plus adapt\'e.
  399 + \item Graphe de t\^aches : la d\'efinition \ref{def-ordo1} d\'ecrit cette cat\'egorie. La plupart du temps,
  400 + les t\^aches sont repr\'esent\'ees par une DAG. Cette cat\'egorie est très proche de notre cas puisque nous devons \'egalement ex\'ecuter
  401 + des t\^aches qui ont un certain nombre de d\'ependances. On pourra même dire que dans certain cas,
  402 + on a des anti-arbres, c'est à dire que nous avons une multitude de t\^aches d'entr\'ees qui convergent vers une
  403 + t\^ache de fin.
  404 + \item Workflow : cette cat\'egorie est une sous cat\'egorie des graphes de t\^aches dans le sens où
  405 + il s'agit d'un graphe de t\^aches r\'ep\'et\'e de nombreuses de fois. C'est exactement ce type de problème
  406 + que nous traitons ici.
  407 + \end{itemize}
  408 +
  409 + Bien entendu, cette liste n'est pas exhaustive et il existe de nombreuses autres classifications et sous-classifications
  410 + de ces problèmes. Nous n'avons parl\'e ici que des cat\'egories les plus communes.
  411 +
  412 + Un autre point à d\'efinir, est le critère d'optimisation. Il y a là encore un grand nombre de
  413 + critères possibles. Nous allons donc parler des principaux :
  414 + \begin{itemize}
  415 + \item Temps de compl\'etion total (ou Makespan en anglais) : ce critère est l'un des critères d'optimisation
  416 + les plus courant. Il s'agit donc de minimiser la date de fin de la dernière t\^ache de l'ensemble des
  417 + t\^aches à ex\'ecuter. L'enjeu de cette optimisation est donc de trouver l'ordonnancement optimal permettant
  418 + la fin d'ex\'ecution au plus tôt.
  419 + \item Somme des temps d'ex\'ecution (Flowtime en anglais) : il s'agit de faire la somme des temps d'ex\'ecution de toutes les t\^aches
  420 + et d'optimiser ce r\'esultat.
  421 + \item Le d\'ebit : ce critère quant à lui, vise à augmenter au maximum le d\'ebit de traitement des donn\'ees.
  422 + \end{itemize}
  423 +
  424 + En plus de cela, on peut avoir besoin de plusieurs critères d'optimisation. Il s'agit dans ce cas d'une optimisation
  425 + multi-critères. Bien entendu, cela complexifie d'autant plus le problème car la solution la plus optimale pour un
  426 + des critères peut être très mauvaise pour un autre critère. De ce cas, il s'agira de trouver une solution qui permet
  427 + de faire le meilleur compromis entre tous les critères.
  428 +
  429 +
  430 + \subsection{Formalisation du problème}
  431 + \label{formalisation}
  432 + Maintenant que nous avons donn\'e le vocabulaire li\'e à l'ordonnancement, nous allons pouvoir essayer caract\'eriser
  433 + formellement notre problème. En effet, nous allons reprendre les contraintes \'enonc\'ees dans la sections \ref{def-contraintes}
  434 + et nous essayerons de les formaliser le plus finement possible.
  435 +
  436 + Comme nous l'avons dit, une t\^ache est un bloc de traitement. Chaque t\^ache $i$ dispose d'un ensemble de paramètres
  437 + que nous nommerons $\mathcal{P}_{i}$. Cet ensemble $\mathcal{P}_i$ est propre à chaque t\^ache et il variera d'une
  438 + t\^ache à l'autre. Nous reviendrons plus tard sur les paramètres qui peuvent composer cet ensemble.
  439 +
  440 + Outre cet ensemble $\mathcal{P}_i$, chaque t\^ache dispose de paramètres communs :
  441 + \begin{itemize}
  442 + \item Dur\'ee de la t\^ache : Comme nous l'avons dit auparavant, dans le cadre d'un FPGA le temps est compt\'e en nombre de coup d'horloge.
  443 + En outre, les blocs sont toujours sollicit\'es, certains même sont capables de lire et de renvoyer une r\'esultat à chaque coups d'horloge.
  444 + Donc la dur\'ee d'une t\^ache ne peut être le laps de temps entre l'entr\'ee d'une donn\'ee et la sortie d'une autre. Nous d\'efinirons la
  445 + dur\'ee comme le temps de traitement d'une donn\'ee, c'est à dire la diff\'erence de temps entre la date de sortie d'une donn\'ee
  446 + et de sa date d'entr\'ee. Nous nommerons cette dur\'ee $\delta_i$. % Je devrais la nomm\'ee w comme dans la def2
  447 + \item La pr\'ecision : La pr\'ecision d'une donn\'ee est le nombre de bits significatifs qu'elle compte. En effet, au fil des traitements
  448 + les pr\'ecisions peuvent varier. On nomme donc la pr\'ecision d'entr\'ee d'une t\^ache $i$ comme $\pi_i^-$ et la pr\'ecision en sortie $\pi_i^+$.
  449 + \item La fr\'equence du flux en entr\'ee (ou sortie) : Cette fr\'equence repr\'esente la fr\'equence des donn\'ees qui arrivent (resp. sortent).
  450 + Selon les t\^aches, les fr\'equences varieront. En effet, certains blocs ralentissent le flux c'est pourquoi on distingue la fr\'equence du
  451 + flux en entr\'ee et la fr\'equence en sortie. Nous nommerons donc la fr\'equence du flux en entr\'ee $f_i^-$ et la fr\'equence en sortie $f_i^+$.
  452 + \item La quantit\'e de donn\'ees en entr\'ee (ou en sortie) : Il s'agit de la quantit\'e de donn\'ees que le bloc s'attend à traiter (resp.
  453 + est capable de produire). Les t\^aches peuvent avoir à traiter des gros volumes de donn\'ees et n'en ressortir qu'une partie. Cette
  454 + fois encore, il nous faut donc diff\'erencier l'entr\'ee et la sortie. Nous nommerons donc la quantit\'e de donn\'ees entrantes $q_i^-$
  455 + et la quantit\'e de donn\'ees sortantes $q_i^+$ pour une t\^ache $i$.
  456 + \item Le d\'ebit d'entr\'ee (ou de sortie) : Ce paramètre correspond au d\'ebit de donn\'ees que la t\^ache est capable de traiter ou qu'elle
  457 + fournit en sortie. Il s'agit simplement de l'expression des deux pr\'ec\'edents paramètres. Nous d\'efinirons donc la d\'ebit entrant de la
  458 + t\^ache $i$ comme $d_i^-\ =\ q_i^-\ *\ f_i^-$ et le d\'ebit sortant comme $d_i^+\ =\ q_i^+\ *\ f_i^+$.
  459 + \item La taille de la t\^ache : La taille dans les FPGA \'etant limit\'ee, ce paramètre exprime donc la place qu'occupe la t\^ache au sein du bloc.
  460 + Nous nommerons $\mathcal{A}_i$ cette taille.
  461 + \item Les pr\'ed\'ecesseurs et successeurs d'une t\^ache : cela nous permet de connaître les t\^aches requises pour pouvoir traiter
  462 + la t\^ache $i$ ainsi que les t\^aches qui en d\'ependent. Ces ensemble sont not\'es $\Gamma _i ^-$ et $ \Gamma _i ^+$ \\
  463 + %TODO Est-ce vraiment un paramètre ?
  464 + \end{itemize}
  465 +
  466 + Ces diff\'erents paramètres communs sont fortement li\'es aux \'el\'ements de $\mathcal{P}_i$. Voici quelques exemples de relations
  467 + que nous avons identifi\'ees :
  468 + \begin{itemize}
  469 + \item $ \delta _i ^+ \ = \ \mathcal{F}_{\delta}(\pi_i^-,\ \pi_i^+,\ d_i^-,\ d_i^+,\ \mathcal{P}_i) $ donne le temps d'ex\'ecution
  470 + de la t\^ache en fonction de la pr\'ecision voulue, du d\'ebit et des paramètres internes.
  471 + \item $ \pi _i ^+ \ = \ \mathcal{F}_{p}(\pi_i^-,\ \mathcal{P}_i) $, la fonction $F_p$ donne la pr\'ecision en sortie selon la pr\'ecision de d\'epart
  472 + et les paramètres internes de la t\^ache.
  473 + \item $d_i^+\ =\ \mathcal{F}_d(d_i^-, \mathcal{P}_i)$, la fonction $F_d$ donne le d\'ebit sortant de la t\^ache en fonction du d\'ebit
  474 + sortant et des variables internes de la t\^ache.
  475 + \item $A_i^+\ =\ \mathcal{F}_A(\pi_i^-,\ \pi_i^+,\ d_i^-,\ d_i^+, \mathcal{P}_i)$
  476 + \end{itemize}
  477 + Pour le moment, nous ne sommes pas capables de donner une d\'efinition g\'en\'erale de ces fonctions. Mais en revanche,
  478 + sur quelques exemples simples (cf. \ref{def-contraintes}), nous parvenons à donner une \'evaluation de ces fonctions.
  479 +
  480 + Maintenant que nous avons donn\'e toutes les notations utiles, nous allons \'enoncer des contraintes relatives à notre problème. Soit
  481 + un DGA $G(V,\ E)$, on a pour toutes arêtes $(i, j)\ \in\ E$ les in\'equations suivantes :
  482 +
  483 + \paragraph{Contrainte de pr\'ecision :}
  484 + Cette in\'equation traduit la contrainte de pr\'ecision d'une t\^ache à l'autre :
  485 + \begin{align*}
  486 + \pi _i ^+ \geq \pi _j ^-
  487 + \end{align*}
  488 +
  489 + \paragraph{Contrainte de d\'ebit :}
  490 + Cette in\'equation traduit la contrainte de d\'ebit d'une t\^ache à l'autre :
  491 + \begin{align*}
  492 + d _i ^+ = q _j ^- * (f_i + (1 / s_j) ) & \text{ où } s_j \text{ est une valeur positive de temporisation de la t\^ache}
  493 + \end{align*}
  494 +
  495 + \paragraph{Contrainte de synchronisation :}
  496 + Il s'agit de la contrainte qui impose que si à un moment du traitement, le DAG se s\'epare en plusieurs branches parallèles
  497 + et qu'elles se rejoignent plus tard, la somme des latences sur chacune des branches soit la même.
  498 + Plus formellement, s'il existe plusieurs chemins disjoints, partant de la t\^ache $s$ et allant à la t\^ache de $f$ alors :
  499 + \begin{align*}
  500 + \forall \text{ chemin } \mathcal{C}1(s, .., f),
  501 + \forall \text{ chemin } \mathcal{C}2(s, .., f)
  502 + \text{ tel que } \mathcal{C}1 \neq \mathcal{C}2
  503 + \Rightarrow
  504 + \sum _{i} ^{i \in \mathcal{C}1} \delta_i = \sum _{i} ^{i \in \mathcal{C}2} \delta_i
  505 + \end{align*}
  506 +
  507 + \paragraph{Contrainte de place :}
  508 + Cette in\'equation traduit la contrainte de place dans le FPGA. La taille max de la puce FPGA est nomm\'e $\mathcal{A}_{FPGA}$ :
  509 + \begin{align*}
  510 + \sum ^{\text{t\^ache } i} \mathcal{A}_i \leq \mathcal{A}_{FPGA}
  511 + \end{align*}
  512 +
  513 + \subsection{Exemples de mod\'elisation}
  514 + \label{exemples-modeles}
  515 + Nous allons maintenant prendre quelques blocs de traitement simples afin d'illustrer au mieux notre modèle.
  516 + Pour tous nos exemple, nous prendrons un d\'ebit en entr\'ee de 200 Mo/s avec une pr\'ecision de 16 bit.
  517 +
  518 + Prenons tout d'abord l'exemple d'un bloc de d\'ecimation. Le but de ce bloc est de ralentir le flux en ne gardant
  519 + que certaines donn\'ees à intervalle r\'egulier. Cet intervalle est appel\'e le facteur de d\'ecimation, on le notera $N$.
  520 +
  521 + Donc d'après notre mod\'elisation :
  522 + \begin{itemize}
  523 + \item $N \in \mathcal{P}_i$
  524 + %TODO N ou 1 ?
  525 + \item $\delta _i = N\ c.h.$ (coup d'horloge)
  526 + \item $\pi _i ^+ = \pi _i ^- = 16 bits$
  527 + \item $f _i ^+ = f _i ^-$
  528 + \item $q _i ^+ = q _i ^- / N$
  529 + \item $d _i ^+ = q _i ^- / N / f _i ^-$
  530 + \item $\Gamma _i ^+ = \Gamma _i ^- = 1$\\
  531 + %TODO Je ne sais pas trouver la taille...
  532 + \end{itemize}
  533 +
  534 + Un autre exemple int\'eressant que l'on peut donner, c'est le cas des spliters. Il s'agit la aussi d'un bloc très
  535 + simple qui permet de dupliquer un flux. On peut donc donner un nombre de sorties à cr\'eer, on note ce paramètre
  536 + %TODO pas très inspir\'e...
  537 + $X$. Voici ce que donne notre mod\'elisation :
  538 + \begin{itemize}
  539 + \item $X \in \mathcal{P}_i$
  540 + \item $\delta _i = 1\ c.h.$
  541 + \item $\pi _i ^+ = \pi _i ^- = 16 bits$
  542 + \item $f _i ^+ = f _i ^-$
  543 + \item $q _i ^+ = q _i ^-$
  544 + \item $d _i ^+ = d _i ^-$
  545 + \item $\Gamma _i ^- = 1$
  546 + \item $\Gamma _i ^+ = X$\\
  547 + \end{itemize}
  548 +
  549 + L'exemple suivant traite du cas du shifter. Il s'agit d'un bloc qui a pour but de diminuer le nombre de bits des
  550 + donn\'ees afin d'acc\'el\'erer les traitement sur les blocs suivants. On peut donc donner le nombre de bits à shifter,
  551 + on note ce paramètre $S$. Voici ce que donne notre mod\'elisation :
  552 + \begin{itemize}
  553 + \item $S \in \mathcal{P}_i$
  554 + \item $\delta _i = 1\ c.h.$
  555 + \item $\pi _i ^+ = \pi _i ^- - S$
  556 + \item $f _i ^+ = f _i ^-$
  557 + \item $q _i ^+ = q _i ^-$
  558 + \item $d _i ^+ = d _i ^-$
  559 + \item $\Gamma _i ^+ = \Gamma _i ^- = 1$\\
  560 + \end{itemize}
  561 +
  562 + Nous allons traiter un dernier exemple un peu plus complexe, le cas d'un filtre d\'ecimateur (ou FIR). Ce bloc
  563 + est compos\'e de beaucoup de paramètres internes. On peut d\'efinir un nombre d'\'etages $E$, qui repr\'esente le nombre
  564 + d'it\'erations à faire avant d'arrêter le traitement. Afin d'effectuer son filtrage, on doit donner au bloc un ensemble
  565 + de coefficients $C$ et par cons\'equent ces coefficients ont leur propre pr\'ecision $\pi _C$. Pour finir, le dernier
  566 + paramètre à donner est le facteur de d\'ecimation $N$. Si on applique notre mod\'elisation, on peut obtenir cela :
  567 + \begin{itemize}
  568 + \item $E \in \mathcal{P}_i$
  569 + \item $C \in \mathcal{P}_i$
  570 + \item $\pi _C \in \mathcal{P}_i$
  571 + \item $N \in \mathcal{P}_i$
  572 + \item $\delta _i = E * |C| * q_i^-\ c.h.$ %Trop simpliste
  573 + \item $\pi _i ^+ = \pi _i ^- * \pi _C$
  574 + \item $f _i ^+ = f _i ^-$
  575 + \item $q _i ^+ = q _i ^- / N$
  576 + \item $d _i ^+ = q _i ^- / N / f _i ^-$
  577 + \item $\Gamma _i ^+ = \Gamma _i ^- = 1$\\
  578 + \end{itemize}
  579 +
  580 + Ces exemples ne sont que des modèles provisoires; pour s'assurer de leur performance, il faudra les
  581 + confronter à des simulations.
  582 +
  583 +
  584 +Bien que les articles sur les skeletons, \cite{gwen-cogen}, \cite{skeleton} et \cite{hide}, nous aient donn\'e des indices sur une possible
  585 + mod\'elisation, ils \'etaient encore trop focalis\'es sur l'optimisation spatiale des blocs. Nous nous sommes donc inspir\'es de ces travaux
  586 + pour proposer notre modèle, en faisant abstraction des optimisations bas niveau.
  587 +
229 588 \bibliographystyle{IEEEtran}
230   -\bibliography{references}
  589 +\bibliography{references,biblio}
231 590 \end{document}