Diese Seite gehört zu einer Serie von Seiten über Timing. Die vorherige Seite hat die Grundlagen der Theorie hinter Timing-Vorgaben (timing constraints) behandelt. Der nächste Schritt ist, zu sehen, wie diese Theorie angewendet wird.
Überblick
Diese Seite stellt die wichtigste Timing-Vorgabe vor, mit der die Frequenz eines Takts festgelegt wird. Danach folgt ein ausführliches Beispiel für die Analyse eines Pfads (path) im Timing-Report.
Die Details der Analyse im Timing-Report mögen wie ein fortgeschrittenes Thema wirken, sind es aber nicht: Timing-Vorgaben haben den Zweck, die Timing-Analyse des Tools für das Design zu steuern und die genauen Anforderungen festzulegen, die erfüllt werden müssen. Um Timing-Vorgaben zu verstehen, muss man sich also mit der Timing-Analyse beschäftigen. Und die Timing-Analyse wird in den Timing-Reports sichtbar.
Außerdem reicht es nicht, einfach Timing-Vorgaben zu schreiben. Wichtig ist, verifizieren zu können, dass diese Vorgaben auf dem Design korrekt funktionieren. Eine solche Überprüfung ist nur mit einem tiefen Verständnis des Timing-Reports möglich. Ohne ein solches Verständnis passiert es leicht, dass man sich auf Timing-Vorgaben verlässt, die ihren Zweck nicht erfüllen – und sich dann wundert, warum das Logikdesign nicht richtig arbeitet.
Alle FPGA-Tools erzeugen Timing-Reports als Textdateien, und genau solche Reports sind hier gezeigt. Die Tools bieten daneben auch grafische Oberflächen zur Darstellung derselben Informationen. Diese grafische Oberfläche ist manchmal hilfreich und manchmal verwirrend. Deshalb ist die Arbeit mit den Text-Reports ein wichtiger erster Schritt.
Die Perioden-Vorgabe
Die nützlichste Timing-Vorgabe ist die Taktperioden-Vorgabe: Sie teilt dem Tool die Frequenz eines Taktsignals mit.
Angenommen, das Logikdesign besteht zum Beispiel nur aus diesem Verilog-Modul:
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
Aus dem Verilog geht eindeutig hervor, dass @clk als Takt verwendet wird und dass dieses Signal ein externer Port ist (also mit einem physischen Pin des FPGAs verbunden ist).
Wenn die Frequenz von @clk 250 MHz beträgt (4 ns), wird eine Timing-Vorgabe wie die folgende benötigt:
create_clock -period 4 -name clk [get_ports clk]
Dieser Befehl bedeutet Folgendes: „Am I/O-Port gibt es einen Takt namens @clk. Die Taktperiode dieses Takts beträgt 4 ns. Wenn andere Timing-Vorgaben später auf diesen Takt Bezug nehmen, verwenden sie dafür den Namen ‚clk‘.“
Hinweise:
- Der Wert des Parameters „period“ sollte die tatsächliche Taktperiode des Takts sein. Man sollte keinen kleineren Wert aus „zusätzlicher Sicherheit“ wählen (also kein Overconstraining). Dafür gibt es keinen Grund. Wenn ein solches Vorgehen helfen würde, liegt ein anderes Problem vor, das gelöst werden muss.
- Wenn ein asynchroner Reset (asynchronous reset) verwendet wird, schützt create_clock das Flipflop unter Umständen nicht vor Verletzungen seiner Timing-Anforderungen an diesem Reset-Signal. Dies wird auf einer anderen Seite erklärt.
Timing-Analyse
Wir schauen uns nun Vivados Timing-Analyse für die Setup-Anforderung des Pfads an, der bei @foo_reg beginnt und bei @bar endet. Mit anderen Worten: Das ist der Pfad, der sich aus diesem Verilog-Ausdruck ergibt:
bar <= !foo_reg;
Die hier gezeigte Timing-Analyse besteht aus drei Teilen, die im Timing-Report in dieser Reihenfolge erscheinen:
- Ein Kopfbereich, der die Zusammenfassung der Timing-Analyse des Pfads sowie einige Zusatzinformationen enthält.
- Eine Berechnung der Zeit, die von einer Taktflanke vergeht, bis am Eingang des zweiten Flipflops (im Beispiel @bar) ein stabiler Logikzustand anliegt.
- Eine Berechnung, die ermittelt, wann der Eingang des zweiten Flipflops stabil sein muss, um die Timing-Anforderung zu erfüllen.
Diese drei Teile werden unten getrennt gezeigt und beschrieben. Man beachte, dass es im Timing-Report keine sichtbare Trennung zwischen diesen Teilen gibt. Insbesondere ist es dem Report nicht ohne Weiteres anzusehen, wo der zweite Teil endet und der dritte Teil beginnt. Es ist Sache des Lesers, den Beginn des dritten Teils anhand seines Inhalts zu erkennen.
Auch wenn hier Vivados Timing-Report gezeigt wird, verwenden Quartus und einige andere FPGA-Tools dieselbe Methodik. Die Informationen in den Timing-Reports anderer Tools sind meist etwas anders dargestellt. Die Theorie hinter diesen Reports ist jedoch dieselbe. Daher ist dieses Beispiel auch für andere FPGA-Tools hilfreich.
Wir überspringen den ersten Teil des Reports und kommen darauf zurück, nachdem wir die ersten beiden Teile besprochen haben. In dieser Reihenfolge lässt sich der Report leichter erklären. Aber zunächst ein paar allgemeine Worte.
Die Strategie der Timing-Analyse
Anders als die einfache statische Timing-Analyse, die auf der vorherigen Seite gezeigt wurde, berücksichtigt eine echte Timing-Analyse auch die Unvollkommenheiten des Takts. Dazu beginnt die Verzögerungsberechnung am Ursprung des Takts, zum Beispiel am physischen Eingangspin des Takts. Das unterscheidet sich von der einfachen Berechnung der Datenpfadverzögerung (wie sie auf der vorherigen Seite gezeigt wurde), die nur die Verzögerung des Datenpfads berücksichtigt.
Das theoretische Gedankenexperiment sieht also so aus: Eine Stoppuhr wird zusammen mit einer Taktflanke am Taktursprung gestartet. Man lässt diese Stoppuhr weiterlaufen, während die Taktflanke zum ersten Flipflop wandert und es auslöst. Die Zeit wird weitergemessen, während dieses Flipflop seinen Ausgang aktualisiert. Man folgt dem aktualisierten Signal bis zu seinem Ziel. Die Stoppuhr wird angehalten, wenn dieses Signal das zweite Flipflop erreicht.
Im nächsten Schritt wird geprüft, ob das Ergebnis gut ist. Für die tsu-Anforderung bedeutet das, dass das Signal früh genug relativ zur nächsten Taktflanke angekommen ist.
Aber das ist eine Taktflanke am zweiten Flipflop. Wann wird sie dort eintreffen?
Um das herauszufinden, wird die Stoppuhr erneut gestartet, zusammen mit der nächsten Taktflanke am Taktursprung. Die Stoppuhr wird angehalten, wenn diese zweite Taktflanke das zweite Flipflop erreicht. Der Startpunkt ist also derselbe, aber die Taktflanke ist später, und das Ziel der Taktflanke ist ein anderes.
Nach diesem Gedankenexperiment wissen wir, wann die Taktflanke am zweiten Flipflop ankommt. Um die tsu-Anforderung zu erfüllen, muss der Eingang dieses Flipflops relativ zu dieser Taktflanke früh genug stabil sein.
Die Stoppuhr des ersten Gedankenexperiments zeigt, wann die Daten am zweiten Flipflop stabil sind. Die Stoppuhr des zweiten Experiments zeigt, wann die Taktflanke am selben Flipflop ankommt. Es bleibt nur, diese beiden Zahlen zu vergleichen und zu prüfen, ob die Differenz größer ist, als es tsu verlangt.
Mit dieser Methode können Unsicherheiten des Takts berücksichtigt werden, weil sie erlaubt, in beiden Gedankenexperimenten den jeweils ungünstigsten Fall anzunehmen. Bei einer Setup-Zeit-Berechnung werden im ersten Experiment alle Verzögerungen mit ihrem oberen Grenzwert verwendet. Dadurch zeigt die Berechnung den spätestmöglichen Zeitpunkt, zu dem das Signal am Eingang des zweiten Flipflops ankommen kann. Im zweiten Experiment werden dagegen alle Verzögerungen mit ihrem unteren Grenzwert verwendet. Das Ergebnis ist der frühestmögliche Zeitpunkt, zu dem die zweite Taktflanke am zweiten Flipflop eintreffen kann.
Die Berechnung erfolgt also für das Szenario, in dem das Signal so spät wie möglich ankommt und die Taktflanke so früh wie möglich. Wenn die Setup-Anforderung unter diesen Bedingungen erfüllt ist, besteht kein Zweifel, dass sie immer erfüllt ist.
Bei einer Haltezeit-Berechnung ist es umgekehrt: minimale Verzögerungen im ersten Experiment und maximale Verzögerungen im zweiten Experiment.
Die Berechnung des Quellpfads
Wie bereits erwähnt, wird der erste Teil des Timing-Reports später gezeigt. Wir betrachten nun den zweiten Teil der Timing-Analyse: die Berechnung des Quellpfads. Sie besteht aus zwei Abschnitten:
- Der Quell-Taktpfad beginnt an der steigenden Flanke des Takteingangspins des FPGAs und endet, wenn diese steigende Flanke den Takteingang von @foo_reg erreicht.
- Der Datenpfad setzt die Reise fort, bis das Signal am Dateneingang von @bar mit dem neuen Wert aktualisiert ist. Dieser Abschnitt entspricht der einfachen statischen Timing-Analyse, die auf der vorherigen Seite gezeigt wurde.
Zusammen berechnen diese beiden Abschnitte die Zeit von der steigenden Taktflanke am externen Taktpin des FPGAs, bis die Daten das zweite Flipflop erreichen.
Das ist der relevante Teil des Timing-Reports:
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
------------------------------------------------------------------- -------------------
Jede Zeile in diesem Teil repräsentiert ein Logikelement oder eine Leitung. Wenn der „Delay type“ den Wert „net“ hat, gehört die Zeile zu einer Leitung. Alle Verzögerungen dieser Art sind Routing-Verzögerungen, also die Zeit, die ein Signal braucht, um von einem Logikelement zum nächsten zu gelangen.
Die Spalte „Incr“ zeigt, wie viel Verzögerung jedes Element auf dem Pfad beiträgt. Die Spalte „Path“ zeigt die bis dahin aufsummierte Gesamtverzögerung.
Die horizontale Linie in der Mitte markiert das Ende des Quell-Taktpfads und den Beginn des Datenpfads. Schauen wir uns nun die Verzögerungen dieser beiden Pfade genauer an.
Die ersten sieben Verzögerungen betreffen den Eingangspin, nämlich AG12 (das ist die physische Position dieses Pins). Laut diesem Report tragen der Eingangspin und die zugehörige Logik insgesamt 1,731 ns Verzögerung bei.
Der globale Taktpuffer trägt weitere 0,101 ns von seinem Eingang zu seinem Ausgang bei. Danach folgt die Routing-Verzögerung des globalen Takts, eine relativ große Zahl: 1,389 ns. Das ist die Zeit, die das Taktsignal braucht, um den Takteingang von @foo_reg zu erreichen. Der Grund für diese große Verzögerung ist, dass ein globaler Taktpuffer und ein Taktbaum verwendet werden, um dieses Signal zu verteilen. Diese Routing-Ressourcen sind dafür gedacht, einen Takt mit derselben Verzögerung an große Teile des FPGAs zu verteilen. Daher entsteht eine große Verzögerung, selbst wenn der Takt nur wenige Ziele erreicht, wie in diesem Beispiel (der Fan-out des Takts beträgt nur 3).
An diesem Punkt ist der Takt schließlich in der Slice angekommen, die das Flipflop enthält, hier SLICE_X49Y58. Damit endet der Quell-Taktpfad. Die horizontale Linie im Report markiert den Beginn des Datenpfads. Im Beispiel der vorherigen Seite beginnt hier die einfache statische Timing-Analyse.
In der Spalte „Netlist Resources“ rechts steht in der Zeile über der horizontalen Linie „foo_reg_reg/C“, und direkt nach dieser Zeile „foo_reg_reg/Q“. Die Zeile nach der horizontalen Linie ist also eindeutig die Takt-zu-Ausgangs-Verzögerung des Flipflops von @foo_reg (von C nach Q). Diese Verzögerung beträgt 0,138 ns. „FDRE“ bedeutet Flipflop mit Dateneingang, Reset und Enable (Flip-flop with Data, Reset and Enable).
Danach folgen eine Routing-Verzögerung zur LUT (0,241 ns), die Ausbreitungsverzögerung innerhalb der LUT (0,244 ns) und die Routing-Verzögerung zum zweiten Flipflop (0,046 ns). Die Routing-Verzögerungen sind außergewöhnlich klein, weil alles in eine einzige Slice gepackt ist.
Zusammengefasst: Die Taktflanke brauchte 3,221 ns vom externen Pin zum Takteingang des ersten Flipflops. Danach vergingen weitere 0,669 ns, bis das aktualisierte Signal am Eingang des zweiten Flipflops ankam (3,890 − 3,221 = 0,669 ns). Insgesamt betrug die Zeit von der Taktflanke am externen Pin bis zu einem stabilen Signal am endgültigen Ziel (dem Dateneingang des zweiten Flipflops) 3,890 ns (höchstens; es handelt sich um eine Worst-Case-Berechnung).
Es ist also an der Zeit zu fragen, ob das früh genug war. Ist die Setup-Anforderung erfüllt?
Der Taktpfad zum Ziel
Der Zweck dieser zweiten Berechnung ist herauszufinden, wie schnell die Taktflanke vom externen Pin zum Takteingang des zweiten Flipflops gelangen kann.
Man beachte, dass das Ziel des Taktpfads das zweite Flipflop ist. Das darf nicht mit dem Taktpfad der vorherigen Berechnung verwechselt werden, dessen Ziel das erste Flipflop war.
Es gibt weitere bemerkenswerte Unterschiede:
- Es wird nur der Taktpfad berechnet. Mit anderen Worten: Im Vergleich zur vorherigen Berechnung wird nur der Abschnitt bis zur horizontalen Linie berücksichtigt.
- Die gedankliche Stoppuhr startet bei 4 ns und nicht bei null. Der Grund ist, dass diese Berechnung feststellen soll, ob das Datensignal früh genug ankommt, um die Setup-Anforderung zu erfüllen. Dementsprechend beginnt die Berechnung an der zweiten Taktflanke, die laut der Timing-Vorgabe für clk (also dem oben gezeigten create_clock-Befehl) bei 4 ns liegt.
- Die Verzögerungen der einzelnen Komponenten in diesem Abschnitt sind kleiner. Das ist in diesem speziellen Beispiel leicht zu sehen, weil beide Flipflops in derselben Slice liegen, sodass die Taktpfade in beiden Berechnungen exakt gleich sind (das ist normalerweise nicht der Fall). Weiter unten dazu mehr.
- Die letzten drei Zeilen dieser Berechnung (Clock-Pessimismus, Clock-Uncertainty und Setup_DFF2_SLICEL_C_D) sind keine Logikbausteine, sondern Timing-Parameter.
Der dritte Teil der Timing-Analyse (der Taktpfad zum Ziel) sieht so aus:
(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
Die Tools haben @foo_reg und @bar in dieselbe Slice gelegt. Daher ist der Taktpfad in dieser Analyse in diesem speziellen Fall derselbe wie in der ersten Analyse. Entsprechend sieht man leicht, dass die Reihenfolge der Logikelemente bis zur horizontalen Linie exakt der vorherigen Analyse entspricht. Nach dieser Folge gibt es zwei Timing-Parameter, die die Berechnung korrigieren: Clock-Pessimismus und Clock-Uncertainty (Taktunsicherheit). Diese werden weiter unten auf dieser Seite getrennt besprochen.
In der Zeile unmittelbar vor der letzten Zeile dieser Berechnung steht der früheste Zeitpunkt, zu dem die zweite Taktflanke ankommen kann: 7,138 ns nach der ersten Taktflanke. Die Setup-Anforderung verlangt, dass das Datensignal vor dieser Taktflanke stabil ist. tsu gibt an, um wie viel. Um den spätesten Zeitpunkt zu erhalten, zu dem die Daten stabil sein müssen, wird tsu von der Ankunftszeit des Takts abgezogen.
Im obigen Beispiel ist tsu negativ und beträgt −0,067 ns. Das Endergebnis ist daher 7,138 − (−0,067) = 7,205 ns. Anders ausgedrückt müssen die Daten am zweiten Flipflop spätestens 7,205 ns nach der ersten Taktflanke stabil sein.
Im vorherigen Rechengang war das Ergebnis, dass die Daten nach dieser Taktflanke im schlechtesten Fall nach 3,890 ns stabil sind. Das ist also gut genug, mit einer Marge: Die Differenz zwischen der Anforderung und dem Garantierten beträgt 7,205 − 3,890 = 3,315 ns. Mit anderen Worten: Die Zeitmarge (slack) beträgt 3,315 ns.
Zusammenfassung der Timing-Analyse
Jetzt ist es Zeit, zum ersten Teil des Timing-Reports des Pfads zurückzukehren. Dieser Teil steht vor den oben gezeigten Berechnungen und fasst die wichtigsten Ergebnisse zusammen. Außerdem erläutert dieser Kopfbereich einige Werte, die in der Berechnung vorkommen.
Man sollte sich also merken, dass eine Timing-Analyse eines Pfads so beginnt:
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)
Dieser Teil enthält viele verschiedene Informationen, daher gehe ich sie einzeln durch. Beginnen wir mit der ersten Zeile:
Slack (MET) : 3.315ns (required time - arrival time)
Das bedeutet, dass die Timing-Vorgabe erfüllt wurde (met) und dass noch Zeit übrig war – die Zeitmarge (Slack) – in Höhe von 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})
Diese Zeilen sagen, welcher Datenpfad untersucht wird. Definiert wird das durch den Startpunkt und den Endpunkt dieses Pfads (Source und Destination). Der Datenpfad beginnt an foo_reg_reg/C, also dem Takteingang von @foo_reg. Dieser Pfad endet am Dateneingang von bar_reg__0/D.
Außerdem wird „clk“ erwähnt und seine Signalform beschrieben. „clk“ bezieht sich auf den Namen, der dem Takt mit create_clock gegeben wurde. In diesem Beispiel ist „clk“ auch der Name des Taktsignals. Wenn im Parameter „-name“ der Timing-Vorgabe ein anderer Name verwendet wird, erscheint dieser Name im Timing-Report, unabhängig vom Namen des Signals. Das gilt für alle Stellen, an denen „clk“ in diesem Beispiel des Timing-Reports vorkommt.
Path Group: clk
Die Pfadgruppe (Path Group) ist hier „clk“. Das bedeutet, dass der Grund für die Untersuchung dieses Pfads die gleichnamige Timing-Vorgabe ist.
Path Type: Setup (Max at Slow Process Corner)
Der Pfadtyp (Path Type) ist Setup. Das bedeutet, dass die Setup-Anforderung untersucht wird. „Max at Slow Process Corner“ bedeutet, dass für den Datenpfad (die erste Berechnung) die maximalen Verzögerungen verwendet wurden. Was „Corner“ in diesem Zusammenhang bedeutet, wird weiter unten erklärt.
Requirement: 4.000ns (clk rise@4.000ns - clk rise@0.000ns)
Zur Erinnerung: Für jedes der beiden oben beschriebenen Gedankenexperimente wird eine gedankliche Stoppuhr gestartet. Die „Requirement“ ist der Zeitunterschied zwischen den Startzeitpunkten dieser Stoppuhren. In diesem Fall ist das die von der Timing-Vorgabe verlangte Taktperiode, also 4 ns.
Data Path Delay: 0.669ns (logic 0.382ns (57.100%) route 0.287ns (42.900%))
Die „Data Path Delay“ ist die Summe aller Verzögerungen nach der horizontalen Linie in der ersten Berechnung (also der Verzögerungen des Datenpfads).
In dieser Zeile wird die Verzögerung außerdem getrennt nach Logik und Routing ausgewiesen. So sieht man, wie viel Zeit auf Logikelemente entfällt und wie viel Zeit auf den Leitungen zwischen diesen Logikelementen verbraucht wird. Als Faustregel gilt, dass ungefähr 60 % der Verzögerung auf Logik entfallen sollten und der Rest auf das Routing. Der Pfad in diesem Beispiel zeigt also die normale Situation.
Wenn der Routing-Anteil deutlich größer wird, kann das auf ein Problem hindeuten, insbesondere wenn der Pfad die Timing-Vorgabe nicht erfüllt. Mehr dazu auf der nächsten Seite im Abschnitt über die Analyse von thold.
Logic Levels: 1 (LUT1=1)
Der Datenpfad besteht aus einer einzigen LUT, daher ist die Anzahl der Logikstufen (Logic Levels) 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
Der Clock Path Skew ist der Zeitunterschied zwischen dem Eintreffen derselben Taktflanke an den beiden Flipflops. Es handelt sich um einen berechneten Worst Case, der einschließt, dass auf dem einen Taktpfad die maximalen und auf dem anderen Taktpfad die minimalen Verzögerungen verwendet wurden. Der Abschnitt „Clock-Pessimismus-Entfernung“ weiter unten erklärt die Arithmetik hinter diesen Zeilen.
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
Siehe den Abschnitt „Clock-Uncertainty“ weiter unten. Diese Zeilen zeigen, wie die Clock-Uncertainty berechnet wurde. Das Ergebnis dieser Berechnung, 0,035 ns, ist unrealistisch optimistisch. Das liegt daran, dass in der Timing-Vorgabe kein Jitter angegeben wurde, sodass die Tools einen Jitter von null angenommen haben. Außerdem wird der externe Takt direkt verwendet (also ohne PLL im FPGA), sodass es fast keine Jitterquelle zu berücksichtigen gibt.
Auch wenn es ein Fehler ist, den Jitter des externen Takts nicht in der Timing-Vorgabe anzugeben, wird es üblicherweise so gehandhabt. Das ist selten eine Ursache für Probleme, weil der Jitter im Vergleich zu den anderen Größen, die in die Timing-Berechnung eingehen, meist klein ist.
Clock Net Delay (Source): 1.389ns (routing 0.002ns, distribution 1.387ns) Clock Net Delay (Destination): 1.218ns (routing 0.002ns, distribution 1.216ns)
Das sind die Verzögerungen des Taktsignals selbst, vom Ausgang des Taktpuffers bis zu den Takteingängen der jeweiligen Flipflops. In diesem Beispiel lässt sich aus diesen Zahlen nicht viel herauslesen.
Multi-Corner-Timing-Analyse
Die Verzögerung aller Logikelemente hängt von einigen unbekannten Parametern ab, zum Beispiel von der Temperatur und der Versorgungsspannung. Außerdem wird der Begriff „Prozess“ (process) für Ungenauigkeiten bei der Herstellung des FPGAs verwendet. Auch wenn jedes FPGA getestet wird, um sicherzustellen, dass es dem Datenblatt entspricht, gibt es dennoch eine gewisse Unsicherheit über das Verhalten jedes Logikelements.
Die FPGA-Tools führen die Timing-Analyse für jeden Pfad in einigen extremen Szenarien aus, die als „Corner“ (Prozessecken) bezeichnet werden. Ein Szenario könnte zum Beispiel die niedrigste zulässige Temperatur zusammen mit dem schnellsten Prozess sein (also wenn das FPGA zufällig mit geringen Verzögerungen hergestellt wurde). Ein zweites Szenario könnte die höchste zulässige Temperatur zusammen mit dem schnellsten Prozess sein. Das dritte und das vierte Szenario wiederholen das mit dem langsamsten Prozess.
In diesem Beispiel wird die Timing-Analyse also für die Extrembedingungen zweier Parameter ausgeführt: Temperatur und Prozess. Man nennt das eine Vier-Corner-Timing-Analyse. Aber das ist nur eine von vielen Möglichkeiten, eine Multi-Corner-Timing-Analyse durchzuführen. Jedes FPGA-Tool führt die Timing-Analyse auf eine etwas andere Art aus.
Unabhängig davon, welche Corner die Tools zu untersuchen wählen, gilt immer der schlechteste Fall als Ergebnis der Timing-Analyse. Mit anderen Worten: Die Tools berechnen die Zeitmarge (Slack) für jeden Corner, und es zählt die niedrigste Zeitmarge.
Die Tools sind so programmiert, dass sie für jedes FPGA die passende Multi-Corner-Timing-Analyse durchführen. Man braucht dieses Thema also nicht besonders tief zu verstehen. Beim Lesen eines Timing-Reports ist es jedoch wichtig zu prüfen, ob er sich auf einen einzelnen Corner bezieht oder ob er die Zusammenfassung aller Corner (also den schlechtesten Fall) darstellt. Es gibt eine Verwechslungsgefahr, insbesondere bei Quartus.
Als Nächstes werden die Clock-Pessimismus-Entfernung und die Clock-Uncertainty besprochen. Das sind relativ fortgeschrittene Themen. Wenn Sie sich nicht für die feineren Details der Timing-Berechnung interessieren, können Sie getrost zur nächsten Seite dieser Serie springen.
Clock-Pessimismus-Entfernung
Durch den Zufall, dass beide Flipflops in derselben Slice liegen, lassen sich die Berechnungen der Taktpfadverzögerungen (also der Zeit bis die Taktflanke die Slice erreicht) direkt vergleichen. In der zweiten Berechnung beträgt diese Zeit 2,646 ns, weil die Berechnung bei 4 ns beginnt und bei 6,646 ns endet; also 6,646 − 4 = 2,646 ns. In der vorherigen Berechnung war das Ergebnis 3,221 ns. Die Differenz beträgt 0,575 ns.
Der Grund für diese Differenz ist, dass in der ersten Berechnung die maximalen Verzögerungen und in der zweiten Berechnung die minimalen Verzögerungen verwendet wurden. Die Differenz zwischen minimalen und maximalen Verzögerungen steht dafür, dass die Verzögerungen wegen natürlicher Ungenauigkeiten im Herstellungsprozess nicht exakt bekannt sind. Wenn also der Taktpfad zum ersten Flipflop völlig anders ist als der Taktpfad zum zweiten Flipflop, muss der schlechteste Fall angenommen werden. Dieser schlechteste Fall tritt ein, wenn alle Verzögerungen des ersten Pfads maximal und alle Verzögerungen des zweiten Pfads minimal sind. Das nennt man Clock-Pessimismus.
Man beachte, dass das nichts mit der Temperatur oder mit Unterschieden zwischen physischen FPGAs zu tun hat: Beide Berechnungen gelten für dieselbe Temperatur und denselben Herstellungsprozess. Die Differenz entsteht, weil jede Verzögerung in dem Abschnitt eine Toleranz innerhalb der FPGA-Spezifikation hat.
Aber warum wird der Clock-Pessimismus in die Berechnung einbezogen, wenn der Taktpfad in beiden Berechnungen identisch ist? Die Antwort ist: Das wäre ein Fehler. Deshalb gibt es im Taktpfad zum Ziel eine Zeile mit dem Titel „clock pessimism“. Diese Zeile addiert 0,527 ns zur Verzögerung, um diesen Fehler auszugleichen. Der Titel sollte eigentlich „clock pessimism removal“ (CPR) lauten, also „Entfernung des Clock-Pessimismus“.
Die Idee hinter der Clock-Pessimismus-Entfernung ist also, unnötige Differenzen zwischen der minimalen und der maximalen Verzögerung in den Teilen des Taktpfads zu beseitigen, die in beiden Berechnungen gleich sind. Die Tools vergleichen die Taktpfade beider Berechnungen und finden den Abschnitt, der beiden Pfaden gemeinsam ist. Die Summe aller Verzögerungsdifferenzen in diesem gemeinsamen Abschnitt ist der Clock-Pessimismus, der entfernt werden muss.
Wie oben erwähnt, betrug die Differenz zwischen den Taktpfaden 0,575 ns. Der angewendete Clock-Pessimismus betrug aber nur 0,527 ns. Die Reduktion war also um 0,048 ns kleiner. Der Grund ist, dass es innerhalb der Slice einen kleinen Abschnitt des Taktpfads gibt, der nicht beiden Berechnungen gemeinsam ist: Eine Leitung in der Slice führt zum ersten Flipflop, eine zweite Leitung zum zweiten Flipflop. Die Verzögerungen dieser beiden Leitungen können unterschiedlich sein.
Clock-Uncertainty
In der Timing-Berechnung wurden 0,035 ns von der Berechnung des Taktpfads abgezogen. Das macht die Timing-Berechnung strenger.
Die Clock-Uncertainty berücksichtigt alles, was an der Zeit zwischen zwei Taktflanken zufällig ist. Diese Zufälligkeit nennt man Taktjitter (jitter). Sie ist das Ergebnis verschiedener Rauschquellen und zufälligen Verhaltens der Elektronik.
Der Abzug von 0,035 ns in der Berechnung trägt der Tatsache Rechnung, dass die Taktperiode in der Timing-Vorgabe zwar mit 4 ns festgelegt ist (create_clock), die tatsächliche Periode aber zufällig schwankt. Dadurch kann die Zeit zwischen zwei Taktflanken kürzer sein. Wie viel kürzer? In dieser Berechnung wurde angenommen, dass die Zeit zwischen zwei Taktflanken niemals weniger als 3,965 ns beträgt (4 − 0,035 = 3,965 ns).
Ist diese Annahme begründet? Das ist eine schwierige Frage, denn die Abschätzung von Taktjitter ist ein kompliziertes Thema, das weit über den Rahmen dieser Diskussion über Timing-Vorgaben hinausgeht. Es ist trotzdem empfehlenswert, sich damit weiter zu beschäftigen, denn Taktjitter kann unabhängig von Timing-Vorgaben die Quelle verschiedener Probleme in einem Logikdesign sein.
Damit endet die erste von zwei Seiten über die Taktperioden-Vorgabe. Auf der nächsten Seite gibt es mehr dazu zu lernen...