OK, c’est quoi ?
Cette page est la partie « exemple » d’un autre article, qui explique la signification de set_input_delay et de set_output_delay dans les contraintes temporelles (timing constraints) SDC.
Comme dans cet autre article, les contraintes temporelles utilisées pour les exemples ci-dessous sont :
create_clock -name theclk -period 20 [get_ports test_clk] set_output_delay -clock theclk -max 8 [get_ports test_out] set_output_delay -clock theclk -min -3 [get_ports test_out] set_input_delay -clock theclk -max 4 [get_ports test_in] set_input_delay -clock theclk -min 2 [get_ports test_in]
Analyse de set_input_delay -max (setup)
Slack (MET) : 15.664ns (required time - arrival time)
Source: test_in
(input port clocked by theclk {rise@0.000ns fall@10.000ns period=20.000ns})
Destination: test_samp_reg/D
(rising edge-triggered cell FDRE clocked by theclk {rise@0.000ns fall@10.000ns period=20.000ns})
Path Group: theclk
Path Type: Setup (Max at Fast Process Corner)
Requirement: 20.000ns (theclk rise@20.000ns - theclk rise@0.000ns)
Data Path Delay: 2.465ns (logic 0.291ns (11.797%) route 2.175ns (88.203%))
Logic Levels: 1 (IBUF=1)
Input Delay: 4.000ns
Clock Path Skew: 2.162ns (DCD - SCD + CPR)
Destination Clock Delay (DCD): 2.162ns = ( 22.162 - 20.000 )
Source Clock Delay (SCD): 0.000ns
Clock Pessimism Removal (CPR): 0.000ns
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
Location Delay type Incr(ns) Path(ns) Netlist Resource(s)
------------------------------------------------------------------- -------------------
(clock theclk rise edge) 0.000 0.000 r
input delay 4.000 4.000
AE20 0.000 4.000 r test_in (IN)
net (fo=0) 0.000 4.000 test_in
AE20 IBUF (Prop_ibuf_I_O) 0.291 4.291 r test_in_IBUF_inst/O
net (fo=1, routed) 2.175 6.465 test_in_IBUF
SLICE_X0Y1 FDRE r test_samp_reg/D
------------------------------------------------------------------- -------------------
(clock theclk rise edge) 20.000 20.000 r
AE23 0.000 20.000 r test_clk (IN)
net (fo=0) 0.000 20.000 test_clk
AE23 IBUF (Prop_ibuf_I_O) 0.077 20.077 r test_clk_IBUF_inst/O
net (fo=1, routed) 1.278 21.355 test_clk_IBUF
BUFGCTRL_X0Y4 BUFG (Prop_bufg_I_O) 0.026 21.381 r test_clk_IBUF_BUFG_inst/O
net (fo=2, routed) 0.781 22.162 test_clk_IBUF_BUFG
SLICE_X0Y1 FDRE r test_samp_reg/C
clock pessimism 0.000 22.162
clock uncertainty -0.035 22.126
SLICE_X0Y1 FDRE (Setup_fdre_C_D) 0.003 22.129 test_samp_reg
-------------------------------------------------------------------
required time 22.129
arrival time -6.465
-------------------------------------------------------------------
slack 15.664
Cette analyse commence à l’instant zéro. Elle ajoute ensuite les 4 ns (clock-to-output) spécifiées dans la contrainte de délai d’entrée maximal, puis poursuit sur ce chemin de données (data path). Les délais des éléments logiques utilisés sont ceux de la combinaison la plus rapide possible du procédé, de la tension et de la température. En y ajoutant le délai de chemin de données propre au FPGA (2,465 ns), le délai total du chemin de données s’établit à 6,465 ns.
Le chemin d’horloge (clock path) est ensuite calculé, en partant du front d’horloge suivant, à 20 ns. Là encore, les délais retenus correspondent à la combinaison la plus rapide possible. L’horloge voyage depuis la broche d’entrée jusqu’à la bascule (sans compensation du délai du réseau d’horloge, puisqu’aucune PLL n’est impliquée). Ce calcul prend aussi en compte la gigue estimée (jitter), au travers de l’« incertitude d’horloge » (clock uncertainty). Au final, le chemin d’horloge se termine à 22,129 ns, soit 15,664 ns après l’arrivée des données sur la bascule. C’est la marge (slack) de cette contrainte.
Cette analyse montre que la valeur à reporter dans une contrainte set_input_delay -max est le délai clock-to-output maximal du composant externe qui pilote la broche d’entrée (+ le délai de propagation des pistes du circuit imprimé). On arrive à cette conclusion parce que cette valeur sert de point de départ au chemin de données. Remarquez la mention « Max » dans le « Path Type » ci-dessus.
Analyse de set_input_delay -min (hold)
Min Delay Paths -------------------------------------------------------------------------------------- Slack (VIOLATED) : -0.045ns (arrival time - required time) Source: test_in (input port clocked by theclk {rise@0.000ns fall@10.000ns period=20.000ns}) Destination: test_samp_reg/D (rising edge-triggered cell FDRE clocked by theclk {rise@0.000ns fall@10.000ns period=20.000ns}) Path Group: theclk Path Type: Hold (Min at Slow Process Corner) Requirement: 0.000ns (theclk rise@0.000ns - theclk rise@0.000ns) Data Path Delay: 3.443ns (logic 0.626ns (18.194%) route 2.817ns (81.806%)) Logic Levels: 1 (IBUF=1) Input Delay: 2.000ns Clock Path Skew: 5.351ns (DCD - SCD - CPR) Destination Clock Delay (DCD): 5.351ns Source Clock Delay (SCD): 0.000ns Clock Pessimism Removal (CPR): -0.000ns 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 Location Delay type Incr(ns) Path(ns) Netlist Resource(s) ------------------------------------------------------------------- ------------------- (clock theclk rise edge) 0.000 0.000 r input delay 2.000 2.000 AE20 0.000 2.000 r test_in (IN) net (fo=0) 0.000 2.000 test_in AE20 IBUF (Prop_ibuf_I_O) 0.626 2.626 r test_in_IBUF_inst/O net (fo=1, routed) 2.817 5.443 test_in_IBUF SLICE_X0Y1 FDRE r test_samp_reg/D ------------------------------------------------------------------- ------------------- (clock theclk rise edge) 0.000 0.000 r AE23 0.000 0.000 r test_clk (IN) net (fo=0) 0.000 0.000 test_clk AE23 IBUF (Prop_ibuf_I_O) 0.734 0.734 r test_clk_IBUF_inst/O net (fo=1, routed) 2.651 3.385 test_clk_IBUF BUFGCTRL_X0Y4 BUFG (Prop_bufg_I_O) 0.093 3.478 r test_clk_IBUF_BUFG_inst/O net (fo=2, routed) 1.873 5.351 test_clk_IBUF_BUFG SLICE_X0Y1 FDRE r test_samp_reg/C clock pessimism 0.000 5.351 clock uncertainty 0.035 5.387 SLICE_X0Y1 FDRE (Hold_fdre_C_D) 0.101 5.488 test_samp_reg ------------------------------------------------------------------- required time -5.488 arrival time 5.443 ------------------------------------------------------------------- slack -0.045
Cette analyse commence à l’instant zéro. Elle ajoute ensuite les 2 ns (clock-to-output) spécifiées dans la contrainte de délai d’entrée minimal, puis continue sur ce chemin de données. Les délais des éléments logiques utilisés sont cette fois ceux de la combinaison la plus lente possible du procédé, de la tension et de la température. Avec le délai propre au FPGA (3,443 ns), le délai total du chemin de données atteint 5,443 ns. Il n’est pas surprenant que le délai propre au FPGA soit plus grand que dans l’analyse rapide ci-dessus.
Le chemin d’horloge est ensuite calculé, maintenant avec la combinaison la plus lente possible. Ce calcul part du même front d’horloge, à 0 ns. Après tout, nous sommes dans un calcul de hold : il s’agit de savoir si les données n’ont pas changé à l’entrée de la bascule avant qu’elle ait eu le temps de les échantillonner.
Le signal d’horloge va de la broche d’entrée jusqu’à la bascule (sans compensation du délai du réseau d’horloge, puisqu’aucune PLL n’est impliquée). Ce calcul tient également compte de la gigue estimée, via l’« incertitude d’horloge ». Notez qu’elle a la même valeur que pour le calcul du setup, mais avec le signe inversé. C’est la même gigue, mais le pire cas se trouve dans le sens opposé.
Au total, le chemin d’horloge se termine à 5,488 ns, c’est-à-dire 0,045 ns trop tard (les données ont changé à 5,443 ns). La contrainte est donc violée, avec une marge négative de 0,045 ns.
Cette analyse montre que la valeur à reporter dans une contrainte set_input_delay -min est le délai clock-to-output minimal du composant externe qui pilote la broche d’entrée. Cette valeur sert en effet de point de départ au chemin de données. Remarquez la mention « Min » dans le « Path Type » ci-dessus.
Il peut paraître surprenant qu’un délai clock-to-output minimal de 2 ns puisse violer une contrainte de hold. Il ne faut pas prendre cela à la légère : comme toute contrainte temporelle non respectée, cela peut provoquer de vrais problèmes si on l’ignore.
Dans ce cas précis, la solution serait d’ajouter une PLL sur le chemin d’horloge afin de verrouiller l’horloge du réseau global sur l’horloge d’entrée. Concrètement, cela revient à avancer le front d’horloge de plusieurs nanosecondes, ce qui règle le problème sans ambiguïté.
Analyse de set_output_delay -max (setup)
Slack (MET) : 2.983ns (required time - arrival time)
Source: test_out_reg/C
(rising edge-triggered cell FDRE clocked by theclk {rise@0.000ns fall@10.000ns period=20.000ns})
Destination: test_out
(output port clocked by theclk {rise@0.000ns fall@10.000ns period=20.000ns})
Path Group: theclk
Path Type: Max at Slow Process Corner
Requirement: 20.000ns (theclk rise@20.000ns - theclk rise@0.000ns)
Data Path Delay: 3.631ns (logic 2.583ns (71.152%) route 1.047ns (28.848%))
Logic Levels: 1 (OBUF=1)
Output Delay: 8.000ns
Clock Path Skew: -5.351ns (DCD - SCD + CPR)
Destination Clock Delay (DCD): 0.000ns = ( 20.000 - 20.000 )
Source Clock Delay (SCD): 5.351ns
Clock Pessimism Removal (CPR): 0.000ns
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
Location Delay type Incr(ns) Path(ns) Netlist Resource(s)
------------------------------------------------------------------- -------------------
(clock theclk rise edge) 0.000 0.000 r
AE23 0.000 0.000 r test_clk (IN)
net (fo=0) 0.000 0.000 test_clk
AE23 IBUF (Prop_ibuf_I_O) 0.734 0.734 r test_clk_IBUF_inst/O
net (fo=1, routed) 2.651 3.385 test_clk_IBUF
BUFGCTRL_X0Y4 BUFG (Prop_bufg_I_O) 0.093 3.478 r test_clk_IBUF_BUFG_inst/O
net (fo=2, routed) 1.873 5.351 test_clk_IBUF_BUFG
SLICE_X0Y1 FDRE r test_out_reg/C
------------------------------------------------------------------- -------------------
SLICE_X0Y1 FDRE (Prop_fdre_C_Q) 0.223 5.574 r test_out_reg/Q
net (fo=1, routed) 1.047 6.622 test_out_OBUF
AK21 OBUF (Prop_obuf_I_O) 2.360 8.982 r test_out_OBUF_inst/O
net (fo=0) 0.000 8.982 test_out
AK21 r test_out (OUT)
------------------------------------------------------------------- -------------------
(clock theclk rise edge) 20.000 20.000 r
clock pessimism 0.000 20.000
clock uncertainty -0.035 19.965
output delay -8.000 11.965
-------------------------------------------------------------------
required time 11.965
arrival time -8.982
-------------------------------------------------------------------
slack 2.983
Puisque cette analyse vise à mesurer le délai de sortie, elle part du front d’horloge, le suit jusqu’à la bascule, puis le long du chemin de données. Le délai total ainsi obtenu est de 8,982 ns.
Remarquez que le « Path Type » ne précise pas qu’il s’agit d’un calcul de setup (pour éviter toute confusion ?), alors même que ce calcul prend en compte le front d’horloge suivant (à 20 ns) et non le même front (à 0 ns).
Ce calcul est effectué avec la combinaison la plus lente possible du procédé, de la tension et de la température (rappelons que le calcul de setup pour le délai d’entrée utilisait, lui, la combinaison la plus rapide). Le chemin d’horloge ressemble beaucoup à celui de l’analyse de hold faite pour le délai d’entrée. C’est tout à fait prévisible, car les deux calculs reposent sur le modèle lent.
Le délai total est comparé au moment du front d’horloge suivant, à 20 ns, diminué de la valeur donnée avec set_output_delay, puis diminué de la gigue estimée (0,035 ns dans l’exemple ci-dessus).
En résumé, les données atteignent un état logique stable à 8,982 ns, et elles doivent y rester jusqu’à environ 12 ns. On dispose donc d’une marge de presque 3 ns.
Ceci montre pourquoi la valeur utilisée avec set_output_delay -max doit être le temps de préparation (setup time) spécifié pour l’entrée du composant externe. Cette contrainte temporelle est vérifiée en calculant la différence entre le délai total jusqu’à des données valides en sortie et la position du front d’horloge suivant. Cette différence est l’objectif à atteindre. C’est exactement la définition du temps de préparation : combien de temps les données doivent rester stables avant le front d’horloge suivant.
Analyse de set_output_delay -min (hold)
Slack (MET) : 0.791ns (arrival time - required time)
Source: test_out_reg/C
(rising edge-triggered cell FDRE clocked by theclk {rise@0.000ns fall@10.000ns period=20.000ns})
Destination: test_out
(output port clocked by theclk {rise@0.000ns fall@10.000ns period=20.000ns})
Path Group: theclk
Path Type: Min at Fast Process Corner
Requirement: 0.000ns (theclk rise@0.000ns - theclk rise@0.000ns)
Data Path Delay: 1.665ns (logic 1.384ns (83.159%) route 0.280ns (16.841%))
Logic Levels: 1 (OBUF=1)
Output Delay: -3.000ns
Clock Path Skew: -2.162ns (DCD - SCD - CPR)
Destination Clock Delay (DCD): 0.000ns
Source Clock Delay (SCD): 2.162ns
Clock Pessimism Removal (CPR): -0.000ns
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
Location Delay type Incr(ns) Path(ns) Netlist Resource(s)
------------------------------------------------------------------- -------------------
(clock theclk rise edge) 0.000 0.000 r
AE23 0.000 0.000 r test_clk (IN)
net (fo=0) 0.000 0.000 test_clk
AE23 IBUF (Prop_ibuf_I_O) 0.077 0.077 r test_clk_IBUF_inst/O
net (fo=1, routed) 1.278 1.355 test_clk_IBUF
BUFGCTRL_X0Y4 BUFG (Prop_bufg_I_O) 0.026 1.381 r test_clk_IBUF_BUFG_inst/O
net (fo=2, routed) 0.781 2.162 test_clk_IBUF_BUFG
SLICE_X0Y1 FDRE r test_out_reg/C
------------------------------------------------------------------- -------------------
SLICE_X0Y1 FDRE (Prop_fdre_C_Q) 0.100 2.262 r test_out_reg/Q
net (fo=1, routed) 0.280 2.542 test_out_OBUF
AK21 OBUF (Prop_obuf_I_O) 1.284 3.826 r test_out_OBUF_inst/O
net (fo=0) 0.000 3.826 test_out
AK21 r test_out (OUT)
------------------------------------------------------------------- -------------------
(clock theclk rise edge) 0.000 0.000 r
clock pessimism 0.000 0.000
clock uncertainty 0.035 0.035
output delay 3.000 3.035
-------------------------------------------------------------------
required time -3.035
arrival time 3.826
-------------------------------------------------------------------
slack 0.791
Cette analyse ressemble à celle du délai de sortie maximal, sauf qu’elle se fait par rapport au même front d’horloge (et non au front suivant). De plus, le calcul utilise la combinaison la plus rapide possible du procédé, de la tension et de la température.
Comme tout à l’heure, le chemin d’horloge est très proche de celui de l’analyse du setup pour le délai d’entrée. C’est prévisible : les deux calculs utilisent le modèle rapide.
Comme dans le calcul de set_output_delay -max, le chemin de données prolonge le chemin d’horloge jusqu’à ce que la sortie soit stable. D’après ce calcul, cela se produit à 3,826 ns (remarquez la différence par rapport au modèle lent).
Ce délai est comparé au moment du même front d’horloge, à 0 ns, diminué du délai de sortie. Rappelons que le délai de sortie minimal de la contrainte temporelle est négatif (-3 ns), ce qui explique qu’il apparaisse comme une valeur positive dans le calcul.
La gigue estimée, 0,035 ns, est également ajoutée (je ne comprends pas très bien pourquoi la gigue intervient dans ce calcul, puisqu’on se trouve sur le même cycle d’horloge).
Conclusion : les données sont restées stables jusqu’à 3,826 ns, et elles doivent le rester jusqu’à 3,035 ns. C’est bon, avec une marge de 0,791 ns.
Ceci montre pourquoi la valeur utilisée avec set_output_delay -min est le temps de maintien (hold time) spécifié pour l’entrée du composant externe, avec un signe inversé. Cette contrainte est vérifiée en exigeant que le délai total soit plus grand que cette valeur donnée. Autrement dit, les données doivent rester stables pendant cette durée après l’horloge. C’est la définition du temps de maintien.