OK, worum geht es hier?
Diese Seite ist der Beispielteil eines anderen Beitrags, in dem erklärt wird, was set_input_delay und set_output_delay in SDC-Timing-Vorgaben (englisch: timing constraints) bedeuten.
Entsprechend diesem anderen Beitrag gelten für die folgenden Beispiele diese Timing-Vorgaben:
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 von 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
Diese Analyse beginnt bei 0 ns. Dazu wird der Wert von 4 ns (Clock-to-Output) addiert, der als maximale Eingangsverzögerung (max input delay) vorgegeben ist; danach läuft der Datenpfad weiter. Die Verzögerungswerte der Logikelemente entsprechen der schnellstmöglichen Kombination aus Prozess, Spannung und Temperatur. Zusammen mit der Verzögerung des FPGA-eigenen Datenpfads von 2,465 ns ergibt sich eine Gesamtverzögerung des Datenpfads von 6,465 ns.
Anschließend wird der Taktpfad berechnet, ausgehend von der folgenden Taktflanke bei 20 ns. Auch hier werden die Verzögerungswerte für die schnellstmögliche Kombination gewählt. Der Takt läuft vom Eingangspin zum Flipflop – ohne Kompensation der Taktnetz-Verzögerung, denn es ist kein PLL beteiligt. Die Rechnung berücksichtigt außerdem den geschätzten Jitter (englisch: jitter) über die „Clock Uncertainty“ beziehungsweise Taktunsicherheit. Insgesamt endet der Taktpfad bei 22,129 ns – also 15,664 ns nach dem Eintreffen des Datums am Flipflop. Das ist der Slack (englisch: slack; also die Zeitmarge) der Timing-Vorgabe.
Diese Analyse zeigt: Der Wert, den man in die Timing-Vorgabe set_input_delay -max einträgt, muss die maximale Clock-to-Output-Zeit des externen Bausteins sein, der den Eingangspin treibt – zuzüglich der Leiterbahnverzögerung auf der Platine. Diese Schlussfolgerung ergibt sich daraus, dass dieser Wert als Startzeitpunkt des Datenpfads verwendet wird. Beachte den Bestandteil „Max“ im obigen Pfadtyp (Path Type).
Analyse von 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
Diese Analyse beginnt ebenfalls bei 0 ns. Dazu addiert man die in der Timing-Vorgabe für die minimale Eingangsverzögerung (min input delay) angegebenen 2 ns (Clock-to-Output) und führt den Datenpfad von dort weiter. Die Verzögerungswerte der Logikelemente entsprechen nun der langsamstmöglichen Kombination aus Prozess, Spannung und Temperatur. Zusammen mit der FPGA-eigenen Datenpfadverzögerung von 3,443 ns ergibt sich eine Gesamtverzögerung des Datenpfads von 5,443 ns. Dass die FPGA-interne Verzögerung hier größer ausfällt als bei der schnellen Analyse oben, ist keine Überraschung.
Danach wird der Taktpfad berechnet, diesmal mit der langsamstmöglichen Kombination. Die Rechnung startet bei derselben Taktflanke bei 0 ns. Schließlich ist es eine Haltezeit-Analyse, es geht also um die Frage, ob sich das Datum am Flipflop-Eingang bereits geändert hat, bevor das Flipflop es abtasten konnte.
Der Takt läuft vom Eingangspin zum Flipflop, wieder ohne Kompensation der Verzögerung durch das Taktnetz (clock network delay), weil keine PLL beteiligt ist. Berücksichtigt wird auch der geschätzte Jitter über die „Clock Uncertainty“. Beachte, dass der Wert derselbe ist wie bei der Setup-Analyse, nur mit umgekehrtem Vorzeichen. Es ist derselbe Jitter, aber der Worst Case liegt in der entgegengesetzten Richtung.
Der Taktpfad endet also insgesamt bei 5,488 ns – das ist 0,045 ns zu spät (das Datum änderte sich bei 5,443 ns). Damit ist die Timing-Vorgabe verletzt, mit einem negativen Slack von 0,045 ns.
Diese Analyse zeigt: Der Wert für set_input_delay -min muss die minimale Clock-to-Output-Zeit des externen Bausteins sein, der den Eingangspin treibt. Auch das folgt daraus, dass dieser Wert als Startzeitpunkt des Datenpfads verwendet wird. Achte auf den Bestandteil „Min“ im obigen Pfadtyp (Path Type).
Es mag überraschen, dass eine minimale Clock-to-Output-Zeit von nur 2 ns eine Hold-Vorgabe verletzen kann. Das sollte man nicht auf die leichte Schulter nehmen – wie jede verletzte Timing-Vorgabe kann es zu echten Problemen führen, wenn man es ignoriert.
Die Lösung wäre in diesem Fall, eine PLL in den Taktpfad aufzunehmen, die den Takt des globalen Taktnetzes auf den Eingangstakt einrasten lässt. Dadurch wird der Takt praktisch einige Nanosekunden früher gezogen, und das Problem ist mit Sicherheit gelöst.
Analyse von 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
Da es bei dieser Analyse darum geht, die Ausgangsverzögerung zu beurteilen, startet sie an der Taktflanke, folgt ihr zum Flipflop und danach durch den Datenpfad. In Summe ergibt sich die Gesamtverzögerung, die hier 8,982 ns beträgt.
Beachte: Der Pfadtyp (Path Type) sagt hier nicht ausdrücklich, dass es sich um eine Setup-Berechnung handelt (um Verwirrung zu vermeiden?), obwohl die folgende Taktflanke bei 20 ns einbezogen wird – und nicht dieselbe Taktflanke bei 0 ns.
Die Berechnung erfolgt mit der langsamstmöglichen Kombination aus Prozess, Spannung und Temperatur (zur Erinnerung: Die Setup-Analyse des Eingangs lief mit der schnellsten Kombination). Der Taktpfad ähnelt stark dem Taktpfad der Hold-Analyse für die Eingangsverzögerung. Das ist zu erwarten, denn beide Rechnungen basieren auf dem langsamen Modell.
Die Gesamtverzögerung wird mit dem Zeitpunkt der folgenden Taktflanke bei 20 ns verglichen, abzüglich des mit set_output_delay angegebenen Werts und abzüglich des geschätzten Jitters (im Beispiel oben 0,035 ns).
Kurz gesagt: Das Datum erreicht bei 8,982 ns einen stabilen Logikzustand und muss bis etwa 12 ns stabil bleiben – es bleibt also ein Slack von fast 3 ns.
Das zeigt, warum der Wert für set_output_delay -max die Setup-Zeit sein muss, die für den Eingang des externen Bausteins spezifiziert ist. Diese Timing-Vorgabe wird geprüft, indem die Differenz zwischen der Gesamtverzögerung bis zum gültigen Datum am Ausgang und dem Zeitpunkt der folgenden Taktflanke gebildet wird. Diese Differenz ist das Ziel, das erreicht werden muss. Genau das ist die Definition der Setup-Zeit: Wie lange das Datum vor der nächsten Taktflanke stabil bleiben muss.
Analyse von 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
Diese Analyse ähnelt der für die maximale Ausgangsverzögerung (max output delay), nur wird sie gegen dieselbe Taktflanke gerechnet statt gegen die folgende. Auch hier wird die schnellstmögliche Kombination aus Prozess, Spannung und Temperatur verwendet.
Wie schon zuvor ähnelt der Taktpfad stark dem Taktpfad der Setup-Analyse für die Eingangsverzögerung. Auch das ist zu erwarten, denn beide Rechnungen basieren auf dem schnellen Modell.
Wie bei der Berechnung für set_output_delay -max wird der Datenpfad im Anschluss an den Taktpfad verfolgt, bis der Ausgang stabil ist. Das ist hier bei 3,826 ns der Fall (man beachte den Unterschied zum langsamen Modell).
Diese Zeit wird mit dem Zeitpunkt derselben Taktflanke bei 0 ns verglichen, abzüglich der Ausgangsverzögerung. Zur Erinnerung: Die minimale Ausgangsverzögerung (min output delay) in der Timing-Vorgabe ist negativ (-3 ns); deshalb erscheint sie in der Rechnung als positive Zahl.
Zusätzlich wird der geschätzte Jitter von 0,035 ns addiert (ich verstehe selbst nicht ganz, warum der Jitter bei dieser Rechnung berücksichtigt wird, wo es doch um denselben Taktzyklus geht).
Zusammengefasst: Das Datum bleibt bis 3,826 ns stabil und muss bis 3,035 ns stabil bleiben. Das passt – der Slack beträgt 0,791 ns.
Das zeigt, warum der Wert bei set_output_delay -min die Haltezeit (hold time) des Eingangs des externen Bausteins ist – mit umgekehrtem Vorzeichen. Die Prüfung dieser Timing-Vorgabe läuft darauf hinaus, dass die Gesamtverzögerung größer sein muss als dieser angegebene Wert. Anders gesagt: Das Datum muss nach der Taktflanke noch so lange stabil bleiben. Das ist die Definition der Haltezeit.