Cette page fait partie d’une série de pages consacrée au timing. La page précédente a passé en revue les bases de la théorie qui se cache derrière les contraintes temporelles (timing constraints). L’étape suivante consiste à voir comment cette théorie s’applique.
Vue d’ensemble
Cette page présente la contrainte temporelle la plus importante, celle qui définit la fréquence d’une horloge. S’ensuit un exemple détaillé d’analyse d’un chemin (path) dans un rapport de timing.
Les détails de l’analyse qui figure dans un rapport de timing peuvent sembler un sujet avancé, mais il n’en est rien : le rôle des contraintes temporelles est de piloter l’analyse de timing que l’outil effectue sur la conception, et de définir précisément ce qui doit être satisfait. Pour comprendre les contraintes temporelles, il faut donc regarder l’analyse de timing. Or cette analyse se lit dans les rapports de timing.
De plus, il ne suffit pas d’écrire des contraintes temporelles. Il est important de savoir vérifier qu’elles agissent correctement sur la conception. Cette vérification n’est possible qu’avec une compréhension approfondie du rapport de timing. Sans elle, on peut facilement se reposer sur des contraintes qui ne remplissent pas leur rôle, puis se demander pourquoi la conception logique ne fonctionne pas correctement.
Tous les outils FPGA génèrent les rapports de timing sous forme de fichiers texte, et ce sont ces rapports qui sont présentés ici. Les outils disposent aussi d’une interface graphique pour visualiser exactement les mêmes informations. Cette interface est parfois utile, parfois déroutante ; travailler sur les rapports texte est donc une première étape importante.
La contrainte de période
La contrainte temporelle la plus utile est la contrainte de période : elle indique à l’outil la fréquence d’un signal d’horloge.
Par exemple, supposons que la conception logique ne soit constituée que de ce module Verilog :
module top(
input clk,
input foo,
output reg bar_reg);
reg foo_reg;
reg bar;
always @(posedge clk)
begin
foo_reg <= foo;
bar <= !foo_reg;
bar_reg <= bar;
end
endmodule
On voit clairement dans le Verilog que @clk sert d’horloge et que ce signal est un port externe (c’est-à-dire relié à une broche physique du FPGA).
Si la fréquence de @clk est de 250 MHz (4 ns), une contrainte de la forme suivante est nécessaire :
create_clock -period 4 -name clk [get_ports clk]
Cette commande signifie : « Il y a une horloge sur le port d’entrée-sortie appelée @clk. Sa période est de 4 ns. Si d’autres contraintes temporelles doivent faire référence à cette horloge, elles utiliseront le nom "clk". »
Remarques :
- La valeur du paramètre "period" doit être la période effective de l’horloge. Il ne faut pas choisir une valeur plus petite « pour être plus prudent » (ce qui reviendrait à sur-contraindre). Il n’y a jamais de raison de faire cela. Si cela aide, c’est qu’il y a un autre problème à résoudre.
- Si une remise à zéro asynchrone (asynchronous reset) est utilisée, create_clock ne protège pas la bascule contre des violations de ses exigences temporelles sur ce signal de reset. Ce point est expliqué sur une autre page.
Analyse de timing
Examinons à présent l’analyse de timing que fait Vivado pour l’exigence de temps de préparation (setup) du chemin qui commence à @foo_reg et se termine à @bar. Autrement dit, c’est le chemin correspondant à cette expression Verilog :
bar <= !foo_reg;
L’analyse de timing présentée ici se compose de trois parties, qui apparaissent dans le rapport de timing dans cet ordre :
- Un en-tête, qui contient le résumé de l’analyse du chemin et quelques informations supplémentaires.
- Un calcul du temps qui s’écoule entre un front d’horloge et le moment où un état logique stable est présent sur l’entrée de la deuxième bascule (@bar dans cet exemple).
- Un calcul qui détermine à quel moment l’entrée de la deuxième bascule doit être stable pour satisfaire l’exigence temporelle.
Ces trois parties sont montrées et décrites séparément ci-dessous. À noter que le rapport de timing ne comporte aucun séparateur visible entre ces parties. En particulier, on ne voit pas clairement dans le rapport où se termine la deuxième partie et où commence la troisième. C’est au lecteur de reconnaître le début de la troisième partie en se fiant à son contenu.
Bien que ce soit le rapport de timing de Vivado qui soit montré ici, Quartus et plusieurs autres outils FPGA adoptent la même méthodologie. Les informations des rapports des autres outils sont en général présentées un peu différemment. La théorie derrière ces rapports est cependant la même. Parcourir cet exemple est donc utile pour les autres outils FPGA également.
Nous allons laisser de côté la première partie du rapport pour l’instant, et y revenir après avoir examiné les deux premières parties. Il est plus facile d’expliquer le rapport dans cet ordre. Mais d’abord, quelques mots de généralités.
La stratégie de l’analyse de timing
Contrairement à l’analyse statique simple que nous avons vue sur la page précédente, une véritable analyse de timing doit tenir compte des imperfections de l’horloge. Pour ce faire, le calcul des délais part de l’origine de l’horloge, par exemple de la broche physique d’entrée de l’horloge. Cela diffère du simple calcul du délai du chemin de données (montré sur la page précédente), qui ne prend en compte que le délai du chemin de données.
L’expérience théorique est donc la suivante : on démarre un chronomètre en même temps qu’un front d’horloge à l’origine de l’horloge. On laisse le chronomètre tourner pendant que ce front se propage jusqu’à la première bascule et l’active. On continue de mesurer le temps pendant que cette bascule met à jour sa sortie, puis on suit le signal mis à jour jusqu’à sa destination. On arrête le chronomètre lorsque ce signal atteint la deuxième bascule.
L’étape suivante consiste à vérifier si le résultat est bon. Pour la condition sur tsu, cela signifie que le signal est arrivé assez tôt par rapport au front d’horloge suivant.
Mais c’est un front d’horloge sur la deuxième bascule. Quand arrivera-t-il ?
Pour le savoir, on redémarre le chronomètre avec le front suivant à l’origine de l’horloge. On arrête le chronomètre lorsque ce second front atteint la deuxième bascule. Le point de départ est donc le même, mais le front est plus tardif et sa destination est différente.
Après cette expérience théorique, on sait quand le front d’horloge arrive sur la deuxième bascule. Pour respecter la condition sur tsu, l’entrée de cette bascule doit être stable suffisamment tôt par rapport à ce front.
Le chronomètre de la première expérience indique quand la donnée est stable sur la deuxième bascule. Le chronomètre de la deuxième expérience indique quand le front d’horloge arrive sur cette même bascule. Il ne reste plus qu’à comparer ces deux nombres et à vérifier que la différence est supérieure à ce qu’exige tsu.
Cette méthode permet de prendre en compte les incertitudes liées à l’horloge, car on peut appliquer le pire cas dans les deux expériences théoriques. Pour un calcul de temps de préparation (setup), tous les délais sont pris à leur valeur maximale dans la première expérience. Le calcul donne ainsi l’instant le plus tardif possible auquel le signal peut arriver sur l’entrée de la deuxième bascule. En revanche, pour la deuxième expérience, tous les délais sont pris à leur valeur minimale. Le résultat est l’instant le plus précoce possible auquel le second front peut arriver sur la deuxième bascule.
Le calcul est donc fait pour le scénario dans lequel le signal arrive le plus tard possible et le front d’horloge arrive le plus tôt possible. Si la condition sur le temps de préparation est satisfaite dans ces conditions, il ne fait aucun doute qu’elle l’est toujours.
Pour un calcul de temps de maintien (hold), c’est l’inverse : on utilise les délais minimaux pour la première expérience et les délais maximaux pour la seconde.
Le calcul du chemin source
Comme mentionné plus haut, la première partie du rapport sera montrée plus loin. Examinons maintenant la deuxième partie de l’analyse : le calcul du chemin source. Il se compose de deux segments :
- Le chemin d’horloge source (source clock path) part du front montant sur la broche d’entrée d’horloge du FPGA et se termine lorsque ce front arrive sur l’entrée d’horloge de @foo_reg.
- Le chemin de données (data path) poursuit le voyage jusqu’à ce que le signal sur l’entrée de données de @bar soit mis à jour avec la nouvelle valeur. Ce segment correspond à l’analyse statique simple présentée sur la page précédente.
Ces deux segments calculent donc ensemble le temps qui va du front montant sur la broche d’horloge externe du FPGA jusqu’à ce que la donnée atteigne la deuxième bascule.
Voici la partie concernée du rapport de timing :
Location Delay type Incr(ns) Path(ns) Netlist Resource(s)
------------------------------------------------------------------- -------------------
(clock clk rise edge) 0.000 0.000 r
AG12 0.000 0.000 r clk (IN)
net (fo=0) 0.000 0.000 clk_IBUF_inst/I
AG12 INBUF (Prop_INBUF_HRIO_PAD_O)
0.738 0.738 r clk_IBUF_inst/INBUF_INST/O
net (fo=1, routed) 0.105 0.843 clk_IBUF_inst/OUT
AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
0.049 0.892 r clk_IBUF_inst/IBUFCTRL_INST/O
net (fo=1, routed) 0.839 1.731 clk_IBUF
BUFGCE_X1Y0 BUFGCE (Prop_BUFCE_BUFGCE_I_O)
0.101 1.832 r clk_IBUF_BUFG_inst/O
X2Y0 (CLOCK_ROOT) net (fo=3, routed) 1.389 3.221 clk_IBUF_BUFG
SLICE_X49Y58 FDRE r foo_reg_reg/C
------------------------------------------------------------------- -------------------
SLICE_X49Y58 FDRE (Prop_EFF2_SLICEL_C_Q)
0.138 3.359 f foo_reg_reg/Q
net (fo=1, routed) 0.241 3.600 foo_reg
SLICE_X49Y58 LUT1 (Prop_D5LUT_SLICEL_I0_O)
0.244 3.844 r bar__0_i_1/O
net (fo=1, routed) 0.046 3.890 p_0_in
SLICE_X49Y58 FDRE r bar_reg__0/D
------------------------------------------------------------------- -------------------
Chaque ligne de cette partie représente un élément logique ou un fil. Lorsque la colonne "Delay type" contient "net", la ligne correspond à un fil. Tous les délais de cette nature sont des délais de routage, c’est-à-dire le temps que met le signal pour aller d’un élément logique à un autre.
La colonne intitulée "Incr" indique le délai apporté par chaque élément du chemin. La colonne "Path" indique le délai total cumulé jusqu’à ce point.
Dans le rapport, la ligne horizontale au milieu marque la fin du chemin d’horloge source et le début du chemin de données. Regardons maintenant de plus près les délais de ces deux chemins.
Les sept premiers délais concernent la broche d’entrée, qui est AG12 (c’est la position physique de cette broche). D’après ce rapport, la broche d’entrée et la logique associée contribuent pour un délai total de 1,731 ns.
Le buffer d’horloge global ajoute encore 0,101 ns entre son entrée et sa sortie. Vient ensuite un délai de routage du réseau d’horloge global, relativement important : 1,389 ns. C’est le temps nécessaire pour que le signal d’horloge atteigne l’entrée d’horloge de @foo_reg. Ce délai important s’explique par le fait qu’un buffer d’horloge global et un arbre d’horloge sont utilisés pour distribuer ce signal. Ces ressources de routage sont conçues pour distribuer une horloge sur de grandes parties du FPGA avec le même délai vers toutes les destinations. Il y a donc un délai important, même lorsque l’horloge n’atteint que quelques destinations, comme dans cet exemple (le fan-out de l’horloge n’est que de 3).
À ce stade, l’horloge a enfin atteint la slice qui contient la bascule, soit SLICE_X49Y58 dans cet exemple. C’est donc la fin du chemin d’horloge source. La ligne horizontale du rapport indique le début du chemin de données. Dans l’exemple de la page précédente, c’est là que commence l’analyse statique simple.
Dans la colonne Netlist Resources, à droite, on lit "foo_reg_reg/C" sur la ligne au-dessus de la ligne horizontale, puis "foo_reg_reg/Q" juste après. La ligne qui suit la ligne horizontale est donc bien le délai de l’horloge vers la sortie de la bascule de @foo_reg (de C à Q). Ce délai est de 0,138 ns. « FDRE » signifie Flip-flop with Data, Reset and Enable (bascule avec données, remise à zéro et activation).
Viennent ensuite un délai de routage vers la LUT (0,241 ns), le délai de propagation (propagation delay) à l’intérieur de la LUT (0,244 ns), puis le délai de routage vers la deuxième bascule (0,046 ns). Les délais de routage sont exceptionnellement faibles, car tout est regroupé dans une seule slice.
Pour résumer cette partie, il a fallu 3,221 ns pour que le front d’horloge voyage de la broche externe jusqu’à l’entrée d’horloge de la première bascule. Ensuite, il a fallu 0,669 ns jusqu’à ce que le signal mis à jour arrive à l’entrée de la deuxième bascule (3,890 − 3,221 = 0,669 ns). Au total, le temps entre le front d’horloge sur la broche externe et un signal stable à la destination finale (l’entrée de données de la deuxième bascule) était de 3,890 ns (au maximum ; c’est un calcul dans le pire cas).
Il est donc temps de se demander si c’était assez tôt. La condition sur le temps de préparation est-elle respectée ?
Chemin d’horloge de destination
Le but de ce second calcul est de découvrir avec quelle rapidité le front d’horloge peut voyager de la broche externe jusqu’à l’entrée d’horloge de la deuxième bascule.
À noter que la destination de ce chemin d’horloge est la deuxième bascule. Il ne faut pas confondre avec le chemin d’horloge du calcul précédent, dont la destination était la première bascule.
Il existe aussi d’autres différences notables :
- Seul le chemin d’horloge est calculé. Autrement dit, par rapport au calcul précédent, seul le segment jusqu’à la ligne horizontale est pris en compte.
- Le chronomètre théorique, cette fois, démarre à 4 ns et non à zéro. En effet, le but de ce calcul est de vérifier si le signal de données arrive assez tôt pour satisfaire la condition sur le temps de préparation. Le calcul commence donc au deuxième front d’horloge, qui se trouve à 4 ns d’après la contrainte de période pour clk (c’est-à-dire la commande create_clock montrée plus haut).
- Les délais des différents éléments de ce segment sont plus faibles. Cela se voit facilement dans cet exemple particulier, car les deux bascules se trouvent dans la même slice ; les chemins d’horloge sont donc exactement les mêmes dans les deux calculs (ce n’est généralement pas le cas). Nous y reviendrons plus bas.
- Les trois dernières lignes de ce calcul (clock pessimism, clock uncertainty et Setup_DFF2_SLICEL_C_D) ne représentent pas des éléments logiques, mais des paramètres temporels.
La troisième partie de l’analyse de timing (le chemin d’horloge de destination) se présente comme suit :
(clock clk rise edge) 4.000 4.000 r
AG12 0.000 4.000 r clk (IN)
net (fo=0) 0.000 4.000 clk_IBUF_inst/I
AG12 INBUF (Prop_INBUF_HRIO_PAD_O)
0.515 4.515 r clk_IBUF_inst/INBUF_INST/O
net (fo=1, routed) 0.066 4.581 clk_IBUF_inst/OUT
AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
0.034 4.615 r clk_IBUF_inst/IBUFCTRL_INST/O
net (fo=1, routed) 0.722 5.337 clk_IBUF
BUFGCE_X1Y0 BUFGCE (Prop_BUFCE_BUFGCE_I_O)
0.091 5.428 r clk_IBUF_BUFG_inst/O
X2Y0 (CLOCK_ROOT) net (fo=3, routed) 1.218 6.646 clk_IBUF_BUFG
SLICE_X49Y58 FDRE r bar_reg__0/C
clock pessimism 0.527 7.173
clock uncertainty -0.035 7.138
SLICE_X49Y58 FDRE (Setup_DFF2_SLICEL_C_D)
0.067 7.205 bar_reg__0
-------------------------------------------------------------------
required time 7.205
arrival time -3.890
-------------------------------------------------------------------
slack 3.315
L’outil a choisi de placer @foo_reg et @bar dans la même slice. Dans ce cas particulier, le chemin d’horloge de cette analyse est donc le même que celui de la première analyse. On voit facilement que la séquence des éléments logiques est exactement la même que dans l’analyse précédente, jusqu’à la ligne horizontale. Après cette séquence, deux paramètres temporels ajustent le calcul : le pessimisme d’horloge (clock pessimism) et l’incertitude d’horloge (clock uncertainty). Ceux-ci sont traités séparément en bas de cette page.
Une ligne avant la dernière de ce calcul, on trouve l’instant le plus précoce auquel le deuxième front d’horloge peut arriver : 7,138 ns après le premier front. La condition sur le temps de préparation exige que le signal de données soit stable avant ce front. tsu précise de combien. Pour obtenir l’instant le plus tardif auquel la donnée doit être stable, on soustrait donc tsu du temps d’arrivée de l’horloge.
Dans l’exemple ci-dessus, tsu est négatif et vaut −0,067 ns. Le résultat final est donc 7,138 − (−0,067) = 7,205 ns. Autrement dit, la donnée doit être stable sur la deuxième bascule au plus tard 7,205 ns après le premier front d’horloge.
Dans le calcul précédent, on a obtenu que la donnée est stable 3,890 ns après ce front, au pire. C’est donc suffisant, avec une marge : l’écart entre ce qui est exigé et ce qui est garanti est de 7,205 − 3,890 = 3,315 ns. Autrement dit, la marge (slack) est de 3,315 ns.
Résumé de l’analyse de timing
Il est temps de revenir à la première partie du rapport de timing du chemin. Cette partie précède les calculs montrés ci-dessus et résume les principaux résultats. En outre, cet en-tête clarifie certaines valeurs qui apparaissent dans ces calculs.
Gardez donc à l’esprit que c’est ainsi que commence l’analyse de timing d’un chemin :
Slack (MET) : 3.315ns (required time - arrival time)
Source: foo_reg_reg/C
(rising edge-triggered cell FDRE clocked by clk {rise@0.000ns fall@2.000ns period=4.000ns})
Destination: bar_reg__0/D
(rising edge-triggered cell FDRE clocked by clk {rise@0.000ns fall@2.000ns period=4.000ns})
Path Group: clk
Path Type: Setup (Max at Slow Process Corner)
Requirement: 4.000ns (clk rise@4.000ns - clk rise@0.000ns)
Data Path Delay: 0.669ns (logic 0.382ns (57.100%) route 0.287ns (42.900%))
Logic Levels: 1 (LUT1=1)
Clock Path Skew: -0.048ns (DCD - SCD + CPR)
Destination Clock Delay (DCD): 2.646ns = ( 6.646 - 4.000 )
Source Clock Delay (SCD): 3.221ns
Clock Pessimism Removal (CPR): 0.527ns
Clock Uncertainty: 0.035ns ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
Total System Jitter (TSJ): 0.071ns
Total Input Jitter (TIJ): 0.000ns
Discrete Jitter (DJ): 0.000ns
Phase Error (PE): 0.000ns
Clock Net Delay (Source): 1.389ns (routing 0.002ns, distribution 1.387ns)
Clock Net Delay (Destination): 1.218ns (routing 0.002ns, distribution 1.216ns)
Cette partie regroupe de nombreuses informations variées ; je vais les passer en revue une à une. Commençons donc par la première ligne :
Slack (MET) : 3.315ns (required time - arrival time)
Cela indique que la contrainte a été respectée (met) et qu’il restait une marge, soit 3,315 ns.
Source: foo_reg_reg/C
(rising edge-triggered cell FDRE clocked by clk {rise@0.000ns fall@2.000ns period=4.000ns})
Destination: bar_reg__0/D
(rising edge-triggered cell FDRE clocked by clk {rise@0.000ns fall@2.000ns period=4.000ns})
Ces lignes indiquent quel chemin de données est examiné. Celui-ci est défini par son point de départ et son point d’arrivée (Source et Destination). Le chemin de données commence à foo_reg_reg/C, qui est l’entrée d’horloge de @foo_reg. Ce chemin se termine sur l’entrée de données bar_reg__0/D.
Par ailleurs, « clk » est mentionné, avec sa forme d’onde. Remarquez que « clk » désigne le nom qui a été donné à l’horloge par create_clock. Dans cet exemple, « clk » est aussi le nom du signal d’horloge. Mais si un autre nom est utilisé dans le paramètre « -name » de la contrainte, c’est ce nom qui apparaît dans le rapport de timing, quel que soit le nom réel du signal. Cela vaut pour toutes les occurrences de « clk » dans cet exemple de rapport.
Path Group: clk
Le Path Group (groupe de chemins) est « clk » ici, ce qui indique que le chemin est examiné en raison de la contrainte du même nom.
Path Type: Setup (Max at Slow Process Corner)
Le Path Type est Setup. Cela signifie que l’on examine la condition sur le temps de préparation. « Max at Slow Process Corner » signifie que les délais maximaux ont été utilisés dans le calcul du chemin de données (le premier calcul). La signification de « Corner » dans ce contexte est expliquée plus bas.
Requirement: 4.000ns (clk rise@4.000ns - clk rise@0.000ns)
Rappelons qu’il y a un chronomètre imaginaire qui est démarré pour chacune des deux expériences théoriques décrites plus haut. La « Requirement » est la différence de temps entre les départs de ces chronomètres. Ici, c’est la période d’horloge exigée par la contrainte, soit 4 ns.
Data Path Delay: 0.669ns (logic 0.382ns (57.100%) route 0.287ns (42.900%))
Le délai du chemin de données (Data Path Delay) est la somme de tous les délais situés après la ligne horizontale dans le premier calcul (c’est-à-dire les délais du chemin de données).
Dans cette ligne, le délai est aussi décomposé entre logique et routage. On voit ainsi le temps passé dans les éléments logiques et le temps passé dans les fils qui les relient. La règle empirique courante veut qu’environ 60 % du délai se trouve dans la logique et le reste dans le routage. Le chemin de cet exemple est donc une situation normale.
Si le délai de routage représente une part nettement plus grande, cela peut signaler un problème, surtout si le chemin n’arrive pas à respecter la contrainte. On en reparle sur la page suivante, dans la section consacrée à l’analyse du temps de maintien.
Logic Levels: 1 (LUT1=1)
Le chemin de données n’est constitué que d’une seule LUT, d’où un nombre de niveaux logiques égal à 1.
Clock Path Skew: -0.048ns (DCD - SCD + CPR)
Destination Clock Delay (DCD): 2.646ns = ( 6.646 - 4.000 )
Source Clock Delay (SCD): 3.221ns
Clock Pessimism Removal (CPR): 0.527ns
Le Clock Path Skew est le décalage entre l’arrivée du même front d’horloge sur les deux bascules. C’est un pire cas calculé, qui inclut le fait que des délais maximaux sont utilisés pour un chemin d’horloge et des délais minimaux pour l’autre. Voir plus bas la section « Clock pessimism removal », qui explique le calcul derrière ces lignes.
Clock Uncertainty: 0.035ns ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
Total System Jitter (TSJ): 0.071ns
Total Input Jitter (TIJ): 0.000ns
Discrete Jitter (DJ): 0.000ns
Phase Error (PE): 0.000ns
Voir la section « Clock uncertainty » plus bas. Ces lignes montrent comment l’incertitude d’horloge a été calculée. Le résultat de ce calcul, 0,035 ns, est irréaliste, trop optimiste. Cela vient du fait qu’aucune gigue (jitter) n’a été spécifiée dans la contrainte temporelle ; l’outil a donc supposé que la gigue était nulle. De plus, l’horloge externe est utilisée directement (c’est-à-dire sans PLL à l’intérieur du FPGA), donc il n’y a presque aucune source de gigue à prendre en compte.
Même s’il est fautif de ne pas préciser la gigue de l’horloge externe dans la contrainte, c’est pourtant ainsi que l’on procède en général. C’est rarement une source de problèmes, car la gigue est en général faible par rapport aux autres quantités prises en compte dans le calcul.
Clock Net Delay (Source): 1.389ns (routing 0.002ns, distribution 1.387ns) Clock Net Delay (Destination): 1.218ns (routing 0.002ns, distribution 1.216ns)
Ce sont les délais du signal d’horloge lui-même, entre la sortie du buffer d’horloge et l’entrée d’horloge de chacune des bascules. Dans cet exemple, ces nombres n’apportent pas beaucoup d’information.
Analyse de timing multi-corner
Le délai de chaque élément logique dépend de quelques paramètres inconnus, par exemple la température et la tension d’alimentation. Le terme « process » (procédé de fabrication) est aussi utilisé pour parler des imprécisions qui interviennent pendant la fabrication du FPGA. Même si chaque FPGA est testé afin de garantir sa conformité à la fiche technique, il demeure une incertitude quant au comportement de chaque élément logique.
Les outils FPGA réalisent l’analyse de timing pour chaque chemin dans quelques scénarios extrêmes, appelés « corners ». Par exemple, un scénario peut être la température minimale autorisée, combinée au process le plus rapide (c’est-à-dire quand le FPGA a été fabriqué avec de faibles délais). Un second scénario peut être la température maximale avec le process le plus rapide. Les troisième et quatrième scénarios répètent ces combinaisons avec le process le plus lent.
Ainsi, dans cet exemple, l’analyse de timing est effectuée pour les conditions extrêmes de deux paramètres : la température et le process. C’est ce qu’on appelle une analyse de timing à quatre corners. Mais ce n’est qu’une des nombreuses manières d’effectuer une analyse multi-corner. Chaque outil FPGA effectue cette analyse à sa manière.
Mais quels que soient les corners que les outils choisissent d’examiner, c’est toujours le pire cas qui est considéré comme le résultat de l’analyse. Autrement dit, les outils calculent la marge pour chaque corner, et c’est la marge la plus faible qui compte.
Les outils sont programmés pour effectuer l’analyse multi-corner appropriée pour chaque FPGA ; il n’est donc pas nécessaire de comprendre ce sujet en profondeur. En revanche, à la lecture d’un rapport de timing, il est important de vérifier s’il concerne un seul corner ou s’il s’agit de la synthèse de tous les corners (autrement dit le pire cas). Une confusion est possible, en particulier avec Quartus.
Le retrait du pessimisme d’horloge et l’incertitude d’horloge sont abordés ensuite. Ce sont des sujets relativement avancés. Si les détails fins du calcul de timing ne vous intéressent pas, vous pouvez passer directement à la page suivante de la série.
Retrait du pessimisme d’horloge
Comme, par coïncidence, les deux bascules se trouvent dans la même slice, il est possible de comparer les calculs des délais des chemins d’horloge (c’est-à-dire le temps jusqu’à ce que le front atteigne la slice). Dans le second calcul, ce temps est de 2,646 ns, car le calcul commence à 4 ns et se termine à 6,646 ns, soit 6,646 − 4 = 2,646 ns. Dans le calcul précédent, le résultat était de 3,221 ns. La différence est de 0,575 ns.
Cette différence vient du fait que les délais maximaux sont utilisés dans le premier calcul et les délais minimaux dans le second. L’écart entre délais minimaux et délais maximaux traduit le fait que les délais ne sont pas connus avec précision, en raison des variations naturelles du procédé de fabrication. Ainsi, si le chemin d’horloge vers la première bascule est complètement différent de celui vers la deuxième bascule, il faut considérer le pire cas. Ce pire cas est celui où tous les délais du premier chemin sont au maximum autorisé et tous les délais du second chemin au minimum autorisé. C’est ce qu’on appelle le pessimisme d’horloge (clock pessimism).
Notons que cela n’a rien à voir avec la température ni avec les différences entre deux FPGA physiques : les deux calculs sont faits pour la même température et le même procédé de fabrication. La différence vient de la tolérance de chaque délai du segment, qui reste dans la spécification du FPGA.
Mais pourquoi tient-on compte du pessimisme d’horloge lorsque le chemin d’horloge est identique dans les deux calculs ? La réponse est qu’il est erroné de le faire. C’est pourquoi il y a une ligne intitulée « clock pessimism » dans le chemin d’horloge de destination. Cette ligne ajoute 0,527 ns au délai afin de compenser cette erreur. Cette ligne devrait en réalité s’intituler « clock pessimism removal » (retrait du pessimisme d’horloge, CPR).
L’idée derrière le retrait du pessimisme d’horloge est donc d’éliminer les différences inutiles entre délai minimal et délai maximal sur les portions du chemin d’horloge qui sont communes aux deux calculs. L’outil compare les chemins d’horloge des deux calculs et trouve le segment commun aux deux. La somme de toutes les différences de délais de ce segment commun est le pessimisme d’horloge à retirer.
Comme mentionné plus haut, la différence entre les chemins d’horloge était de 0,575 ns. Mais le pessimisme d’horloge appliqué n’est que de 0,527 ns. La réduction est donc plus faible de 0,048 ns. La raison est qu’à l’intérieur de la slice, une petite portion du chemin d’horloge n’est pas commune aux deux calculs : un fil interne va vers la première bascule, un autre vers la seconde. Les délais de ces deux fils peuvent être différents.
Incertitude d’horloge
Dans le calcul, 0,035 ns ont été retranchés du chemin d’horloge. Cela rend l’analyse plus stricte.
L’incertitude d’horloge représente tout ce qui est aléatoire dans le temps séparant deux fronts d’horloge. Cet aléa est appelé gigue d’horloge (jitter) et provient de diverses sources de bruit et du comportement aléatoire de l’électronique.
La réduction de 0,035 ns reflète le fait que, même si la période d’horloge est définie à 4 ns par la contrainte (create_clock), cette période est en réalité aléatoire. L’intervalle entre deux fronts peut donc être plus court. De combien ? Dans ce calcul, on a supposé que l’intervalle entre deux fronts ne sera jamais inférieur à 3,965 ns (4 − 0,035 = 3,965 ns).
Cette hypothèse est-elle justifiée ? C’est une question difficile, car l’estimation de la gigue d’horloge est un sujet compliqué qui dépasse largement le cadre de cette discussion sur les contraintes de timing. Il est toutefois recommandé d’étudier ce sujet plus en détail, car la gigue d’horloge peut être à l’origine de divers problèmes dans une conception logique, indépendamment des contraintes.
Ceci conclut la première des deux pages consacrées à la contrainte de période d’horloge. Il y a encore à apprendre sur la page suivante...