01signal: I/O-Timing-Vorgaben in SDC-Syntax

Diese Seite gehört zu einer Serie von Seiten über Timing. Die vorherigen Seiten haben die Theorie hinter Timing-Berechnungen erklärt, das Schreiben mehrerer Timing-Vorgaben (timing constraints) gezeigt und die Prinzipien des Timing-Closure besprochen. Die vorherige Seite hat einige grundlegende Prinzipien der I/O-Timing-Vorgaben erläutert. Diese Seite macht mit den praktischen Aspekten dieses Themas weiter.

Einführung

I/O-Timing-Vorgaben haben den Zweck, eine zuverlässige Schnittstelle mit der Außenwelt sicherzustellen: Sie garantieren, dass jedes Signal aus der Außenwelt zuverlässig am betreffenden Flipflop im FPGA ankommt. Ebenso stellen sie sicher, dass jedes Signal vom FPGA zur Außenwelt zuverlässig am Flipflop der externen Komponente ankommt.

I/O-Timing-Vorgaben sind die schwierigste Art von Timing-Vorgaben: Einige der Timing-Parameter hängen von den externen elektronischen Komponenten auf der Platine ab. Meist müssen die Datenblätter dieser externen Komponenten gelesen werden, um die richtigen Timing-Anforderungen zu bestimmen. Oft ist eine Berechnung mit Papier und Bleistift nötig, um die korrekte Timing-Vorgabe zu erhalten.

Es ist verlockend, diese komplizierte Aufgabe zu überspringen und eine einfache Alternative zu bevorzugen: Versuch und Irrtum. Diese Abkürzung besteht darin, die Tools machen zu lassen, was sie wollen, und zu sehen, ob es funktioniert. Wenn es ein Problem mit einem Eingangsport gibt, verwendet man die entgegengesetzte Taktflanke am Flipflop, das das Eingangssignal empfängt. Wenn ein Ausgang nicht richtig funktioniert, verwendet man die entgegengesetzte Taktflanke am Ausgangs-Flipflop. Auf diese Weise bringt man die Elektronik meist schnell und einfach zum Laufen.

Das Problem bei diesem Vorgehen ist, dass sich das Timing-Verhalten mit der Temperatur ändert. Es gibt außerdem Unsicherheiten wegen des Herstellungsprozesses von Halbleiterkomponenten. Das gilt sowohl für das FPGA als auch für die externe Elektronik. Unsachgemäße Timing-Vorgaben können also zu einem „Black-Magic-Modus“ führen. Das gilt für alle Timing-Vorgaben, kommt aber bei I/O-Timing-Vorgaben häufiger vor.

Das Schlimmste am Überspringen der Papier-und-Bleistift-Berechnung ist, dass es manchmal wegen des Platinenlayouts unmöglich ist, die Timing-Anforderungen zu garantieren. Wenn eine solche Situation während des Platinenentwurfs entdeckt wird, gibt es oft eine einfache Lösung (die Verdrahtung zum FPGA ändern oder die Taktverteilung neu überdenken). Wird ein solcher Fehler jedoch erst nach der Produktion der Platine entdeckt, gibt es möglicherweise keine Möglichkeit, ihn zu beheben. Mit anderen Worten: Es wird unmöglich zu garantieren, dass die Elektronik zuverlässig funktioniert.

Inhalt dieser Seite

Diese Seite beschreibt die grundlegenden Timing-Vorgaben für I/O-Ports. Die hier gezeigte Syntax ist SDC, die von Vivado und Quartus sowie anderen FPGA-Tools verwendet wird.

Diese Seite beginnt mit den Timing-Vorgaben, die speziell für I/O gedacht sind: set_input_delay und set_output_delay. Die Bedeutung dieser Vorgaben wird erklärt. Danach folgt ein Verweis auf zwei separate Seiten, die Beispiele für Timing-Reports von Vivado und Quartus zeigen.

Es ist auch möglich, Timing-Vorgaben mit set_max_delay und set_min_delay zu definieren. Diese Befehle sind in manchen Szenarien besser geeignet. Wir haben sie bereits kennengelernt, und zwar für Pfade innerhalb des FPGAs. Ihre Bedeutung als I/O-Timing-Vorgaben wird weiter unten ebenfalls erklärt.

Diese Seite behandelt nur die technischen Aspekte dieser I/O-Timing-Vorgaben. Für den theoretischen Teil siehe die vorherige Seite, die auch zeigt, wie man False Paths (false paths) für I/O-Ports definiert.

Bedeutung von set_input_delay und set_output_delay

Diese beiden Befehle eignen sich, wenn die Schnittstelle zur externen Komponente system-synchron ist. Kurz gesagt:

set_input_delay -clock … -max … : Die maximale Takt-zu-Ausgang-Verzögerung (clock-to-output delay) der externen Komponente, die mit dem Eingangsport verbunden ist, plus die Leiterbahnverzögerung auf der Platine.
set_input_delay -clock … -min … : Die minimale Takt-zu-Ausgang-Verzögerung der externen Komponente, die mit dem Eingangsport verbunden ist. Wenn das Datenblatt diese Information nicht hergibt, wählt man null (nur für den Fall, dass eine zukünftige Revision dieser Komponente mit einem wirklich schnellen Prozess gefertigt wird).
set_output_delay -clock … -max … : Die t_su der externen Komponente, die das Ausgangssignal empfängt, plus die Leiterbahnverzögerung auf der Platine.
set_output_delay -clock … -min … : Minus t_hold der externen Komponente, die das Ausgangssignal empfängt. Beachten Sie das Minuszeichen. Wenn die Haltezeit zum Beispiel 1 ns beträgt, setzen Sie diese Vorgabe auf −1.

Es ist wichtig zu beachten, dass diese Definitionen nur unter zwei Bedingungen korrekt sind:

Die Schnittstelle ist system-synchron.
Der create_clock-Befehl, der den Takt definiert, bezieht sich mit einem get_ports-Befehl auf das Taktsignal (statt etwa mit get_pins auf ein anderes Signal innerhalb des FPGAs).

Diese beiden Bedingungen sind notwendig, damit die Taktverzögerungen korrekt berechnet werden.

Beachten Sie außerdem: Wenn weder -min noch -max verwendet wird, wird der Befehl so interpretiert, als gäbe es zwei Befehle: einen mit -min und einen zweiten mit -max. Das wollen Sie wahrscheinlich nicht.

Die Definitionen dieser Befehle sind ein wenig verwirrend: set_input_delay definiert, wann das Datensignal nach einer Taktflanke seinen Wert ändern darf. set_output_delay definiert dagegen, wann eine Taktflanke erlaubt ist, nachdem das Datensignal seinen Wert geändert hat. Vermutlich ist der Gedanke hinter diesen Definitionen, dass die Zahlen aus dem Datenblatt direkt in den Timing-Vorgaben verwendet werden können.

Die Befehle set_input_delay und set_output_delay haben mehrere Optionen, die hier nicht behandelt werden. Insbesondere kann die fallende Taktflanke als Zeitreferenz gewählt werden. Dazu siehe die Dokumentation des jeweiligen Tools.

Immer sowohl min als auch max verwenden

Es mag unnötig erscheinen, für jede Timing-Vorgabe sowohl -min als auch -max zu verlangen. Wenn zum Beispiel die t_setup der externen Komponente 8 ns beträgt, was ist dann an diesem Befehl falsch?

set_output_delay -clock theclk 8 [get_ports test_out]

Das definiert die Setup-Zeit korrekt. Die Haltezeit wird dabei jedoch unbeabsichtigt als −8 ns definiert. Das erlaubt es dem Ausgangsport, seinen Wert 8 ns vor der Taktflanke zu ändern. Aber wen kümmert das? Das könnte doch nicht passieren, oder?

Nun, es kann tatsächlich passieren. Ich habe bereits besprochen, wie man mit einer PLL den internen Takt aus einem Takt an einem Eingangspin erzeugt (also dem Takt, der auf der Platine sichtbar ist). Dadurch kann die PLL den internen Takt des FPGAs mit dem Eingangstakt ausrichten. Die PLL tut das, indem sie den Takt leicht verschiebt, um die Verzögerung des Taktverteilungsnetzwerks auszugleichen.

Tatsächlich können die FPGA-Tools den Takt auch etwas früher als den Takt auf der Platine legen, um eine Timing-Vorgabe zu erfüllen: Wenn der Takt im FPGA vor den externen Takt verschoben wird, wird die von der externen Komponente wahrgenommene Takt-zu-Ausgang-Verzögerung kleiner. Das liegt daran, dass das Flipflop im FPGA mit dem internen Takt synchron ist, das sichtbare Timing sich aber auf den externen Takt bezieht.

Wenn der interne Takt des FPGAs jedoch früher liegt als der Takt auf der Platine, kann sich der Ausgang des FPGAs vor der Taktflanke des externen Takts ändern. Das kann zu einer Verletzung der Haltezeit t_hold an der Komponente führen, die diese Ausgänge empfängt.

Wenn der set_output_delay-Befehl die Haltezeit als −8 ns definiert, bedeutet das nicht, dass der Ausgang seinen Wert 8 ns vor der Taktflanke ändern wird. Es erlaubt den Tools aber, den internen Takt so zu verschieben, dass die t_hold-Anforderung verletzt wird. Die korrekte Verwendung von set_output_delay mit -min verhindert das.

Korrekturen wegen Leiterbahnverzögerung

Es ist wichtig, sich daran zu erinnern, dass die Tools die Leiterbahnverzögerung (trace delay) auf der Platine nicht berücksichtigen. Die Tools haben diese Information nicht. Sie nehmen daher an, dass diese Verzögerung bei den Timing-Berechnungen für set_input_delay und set_output_delay null ist. Die Korrektur besteht darin, die Leiterbahnverzögerung zu den Werten aus dem Datenblatt für Takt-zu-Ausgang-Verzögerung und t_su zu addieren.

Möglicherweise muss auch der Taktversatz (clock skew) berücksichtigt werden: Auf einer perfekten Platine kommt der Takt bei allen Komponenten mit derselben Verzögerung an. Im echten Leben gibt es einen möglichen Taktversatz zwischen dem FPGA und der externen Komponente. Ein solcher Taktversatz wird in den Timing-Berechnungen der Tools nicht berücksichtigt.

Wenn der Takt also früher am FPGA ankommt (relativ zur externen Komponente), sind folgende Korrekturen nötig:

Für set_input_delay -clock … -max … : Den Taktversatz zum Verzögerungswert des Befehls addieren (das ist ähnlich wie eine größere Takt-zu-Ausgang-Verzögerung der externen Komponente).
Für set_output_delay -clock … -min … : Den Taktversatz vom Verzögerungswert des Befehls abziehen, also negativer machen (das ist ähnlich wie eine größere t_hold der externen Komponente).

Wenn der Takt dagegen später am FPGA ankommt, sind folgende Korrekturen nötig:

Für set_input_delay -clock … -min … : Den Taktversatz vom Verzögerungswert des Befehls abziehen (das ist ähnlich wie eine kleinere Takt-zu-Ausgang-Verzögerung der externen Komponente). Wenn das Datenblatt der externen Komponente keinen Wert für die minimale Takt-zu-Ausgang-Verzögerung angibt, verwenden Sie den negativen Taktversatz als Wert in diesem Befehl.
Für set_output_delay -clock … -max … : Den Taktversatz zum Verzögerungswert des Befehls addieren (das ist ähnlich wie eine größere Leiterbahnverzögerung auf der Platine).

Beachten Sie, dass der Timing-Report einen Taktversatz anzeigen kann, der nicht null ist, unabhängig von den hier beschriebenen Korrekturen. Der im Timing-Report erscheinende Taktversatz bezieht sich jedoch auf die Taktverzögerungen innerhalb des FPGAs, nicht auf der Platine.

Beispiele für Timing-Reports

Die Beispiele basieren auf folgendem Verilog-Code:

module top(
    input test_clk,
    input test_in,
    output reg test_out
);

   reg test_samp;

   always @(posedge test_clk)
     begin
	test_samp <= test_in;
	test_out <= test_samp;
     end
endmodule

@test_clk ist der Eingangstakt, @test_in ist ein Eingangspin und @test_out ist ein Ausgangspin. Beachten Sie, dass keine PLL verwendet wird, um den internen Takt mit dem Takt auf der Platine auszurichten. Daher gibt es eine erhebliche Taktverzögerung.

Die Timing-Vorgaben lauten wie folgt:

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]

Da die Timing-Reports ziemlich lang sind, werden sie auf separaten Seiten gezeigt:

Hier klicken für Quartus’ Timing-Analyse
Hier klicken für Vivados Timing-Analyse

Verwendung von set_max_delay und set_min_delay

Wenn die Schnittstelle zur externen Komponente quell-synchron ist, ist die Verwendung von set_input_delay und set_output_delay weniger naheliegend. set_max_delay und set_min_delay sind für diese Situation besser geeignet. Auf einer früheren Seite wurden diese beiden Befehle nur als Ergänzungen oder Anpassungen (Timing-Ausnahmen) zu Taktperioden-Vorgaben erwähnt. Alle Pfade waren intern: Sie begannen und endeten an einem sequentiellen Element. Wenn diese Befehle als I/O-Timing-Vorgaben verwendet werden, ist entweder der Anfang oder das Ende des Pfads ein I/O-Port. Wie wird die Timing-Analyse in dieser Situation durchgeführt?

Die Wahrheit ist, dass es oft zwecklos ist, sich in die Timing-Analyse dieser Befehle zu vertiefen: Ihr Zweck ist es meist, das Verhalten der Tools einzuschränken, indem man Timing-Vorgaben schreibt, die die Tools kaum erfüllen können. Die Zahlen in diesen Timing-Vorgaben werden daher durch wiederholte Versuche gefunden, die Vorgaben strenger zu machen. Bei dieser Vorgehensweise hat die Timing-Analyse selbst keine Bedeutung.

Dennoch ist es eine gute Idee, die Berechnungen hinter set_max_delay und set_min_delay zu verstehen:

Zur Erinnerung von früher: Eine Timing-Analyse hat zwei Teile. Der erste Teil ist der Quellpfad (source path): Er berechnet die Zeit von einer Taktflanke (am externen Taktpin) bis zu einem aktualisierten und gültigen Wert am Dateneingang des zweiten Flipflops. Dieser Teil ist die Summe von drei Elementen:

Die Zeit, die die Taktflanke zum ersten Flipflop braucht (der Taktpfad)
Die Zeit, die dieses Flipflop braucht, um seinen Wert zu aktualisieren
Die Zeit, die dieser neue Wert zum zweiten Flipflop braucht

Der zweite Teil ist der Zielpfad (destination path), der nur aus der Zeit besteht, die die Taktflanke zum zweiten Flipflop braucht. Wir wissen bereits, wann der Eingang dieses Flipflops aktualisiert wird (aus dem Quellpfad). Die Zeitdifferenz kann also mit der geforderten t_su oder t_hold verglichen werden, je nachdem, was zutrifft.

Das galt für zwei sequentielle Elemente. Was passiert, wenn eine der Seiten ein I/O-Port ist? Für die Timing-Analyse wird der Port so behandelt, als wäre er ein gedachtes Flipflop. Die Taktpfadverzögerung zu diesem Flipflop ist null.

Betrachten wir die übliche Situation, in der der Takt mit einem create_clock-Befehl definiert ist, der sich auf get_ports stützt (wie in fast allen meiner Beispiele). Eine Taktpfadverzögerung von null bedeutet, dass der Takteingang dieses gedachten Flipflops direkt mit dem Taktpin verbunden ist. Es gibt also keine Verzögerung zwischen dem Taktpin und diesem gedachten Flipflop.

Alle Timing-Parameter dieses Flipflops sind null: die t_su, die t_hold und die Takt-zu-Ausgang-Verzögerung. Das entspricht keiner realistischen elektronischen Komponente, gibt set_max_delay und set_min_delay aber eine Bedeutung, wenn sie mit einem Ausgangsport verwendet werden: die Takt-zu-Ausgang-Verzögerung des Ports. Zum Beispiel:

set_max_delay -to [get_ports test_out] 7
set_min_delay -to [get_ports test_out] 0

Diese beiden Timing-Vorgaben verlangen, dass die Takt-zu-Ausgang-Verzögerung von @test_out zwischen 0 ns und 7 ns liegt.

Warum das so ist, erkläre ich hier: Zur Erinnerung: Normalerweise ähnelt ein set_max_delay-Befehl einer Perioden-Vorgabe für Pfade zwischen bestimmten Flipflops. Was passiert also mit dem Taktpfad zum Ziel (Destination Clock Path)? Die Berechnung beginnt zum Zeitpunkt der zweiten Taktflanke, also bei 7 ns. Aber die Taktpfadverzögerung zum zweiten Flipflop ist null, und auch die t_su dieses Flipflops ist null. Das Ergebnis der Berechnung des Ziel-Taktpfads ist also einfach 7 ns. Das ist der maximal zulässige Wert für den Quellpfad, der wie üblich berechnet wird: Quell-Taktpfad plus Datenpfad. Zusammenfassend lautet die Anforderung, dass der Datenausgang 7 ns nach der ersten Taktflanke gültig ist. Das ist genau die Definition der Takt-zu-Ausgang-Verzögerung des Ausgangsports. Wenn der create_clock-Befehl für den betreffenden Takt auf get_ports basierte, ist diese Takt-zu-Ausgang-Verzögerung relativ zum Takt auf der Platine.

Siehe das Beispiel für Timing-Reports mit Vivado.

Beachten Sie, dass set_output_delay sich auf die t_su oder t_hold der externen Komponente bezieht. set_max_delay definiert dagegen die Takt-zu-Ausgang-Verzögerung des Ausgangsports des FPGAs. Der Hauptunterschied zwischen diesen beiden Optionen ist also, worauf der Fokus liegt.

Bei einem Eingangsport gibt es keine intuitive Erklärung dafür, was set_max_delay und set_min_delay bedeuten: Der Quellpfad besteht aus der Verzögerung zwischen dem Eingangspin und dem Dateneingang des Flipflops, das das Eingangssignal empfängt. Der Ziel-Taktpfad beginnt zu dem Zeitpunkt, der im Timing-Vorgabe-Befehl angegeben ist. Zu dieser Zeit wird die Taktpfadverzögerung addiert. Das sind bedeutungslose Berechnungen (siehe die Timing-Reports). Natürlicher ist die Verwendung von set_input_delay, das sich auf die Takt-zu-Ausgang-Verzögerung der externen Komponente bezieht.

Beachten Sie, dass die Timing-Analyse, die für set_max_delay und set_min_delay durchgeführt wird, nicht von der Taktperiode abhängt. Wenn also die Taktfrequenz geändert wird, werden dieselben Zahlen verwendet, während die Tools diese Vorgaben durchsetzen. Im Gegensatz dazu hängen die Berechnungen für set_input_delay und set_output_delay von der Taktfrequenz ab.

Eine Abhängigkeit der I/O-Timing-Vorgaben von der Taktfrequenz kann je nach den Umständen ein Vorteil oder ein Nachteil sein. Wenn die Timing-Vorgaben auf der Basis der Timing-Parameter der externen Komponente geschrieben werden (und die Schnittstelle system-synchron ist), ist es wahrscheinlich besser, sich auf set_input_delay und set_output_delay zu verlassen: Diese Vorgaben bleiben auch bei einer Änderung der Taktfrequenz korrekt. Wenn die Timing-Vorgaben jedoch die Tools zu bestimmten Entscheidungen zwingen sollen (z.B. zur Verwendung von IOB-Registern), sind set_max_delay und set_min_delay wahrscheinlich besser geeignet.

Verwendung von -datapath_only

Eine mögliche Motivation für eine Timing-Vorgabe besteht darin sicherzustellen, dass die FPGA-Tools alles tun, um die geringstmögliche Verzögerung zum oder vom I/O-Port zu erreichen. Das bedeutet normalerweise die Verwendung des IOB-Registers. Es kann auch bedeuten, das Einfügen einer zusätzlichen Verzögerung zwischen einem Eingangsport und dem Flipflop zu vermeiden (die Tools tun das möglicherweise, um die t_hold-Anforderung mit besserer Marge zu erfüllen).

Wenn eine Timing-Vorgabe für diesen Zweck verwendet wird, gibt es keine bestimmte Verzögerung, die das Ziel ist. Die Idee ist, die Tools daran zu hindern, etwas anderes zu tun, als das bestmögliche Ergebnis zu erreichen. Wenn die FPGA-Tools -datapath_only unterstützen, ist es besser, set_max_delay mit dieser Option zu verwenden. Dadurch wird der Taktpfad vollständig aus der Berechnung entfernt, sodass nur die Verzögerung zwischen dem I/O-Port und dem Flipflop berücksichtigt wird. Auf diese Weise entspricht die Anforderung der Timing-Vorgabe genau ihrem Zweck: die Verzögerung zwischen dem Flipflop und dem I/O-Pin zu steuern.

Ein einfaches Beispiel für Vivado:

set_max_delay -datapath_only -from [get_ports test_in] 2
set_max_delay -datapath_only -from [all_registers] \
   -to [get_ports test_out] 3

Aber was ist der Zweck des Teils „-from [all_registers]“? Warum braucht es ein „-from"? Die kurze Antwort ist, dass Vivado sich weigerte, diesen Befehl ohne einen „-from"-Teil zu akzeptieren. Für den Befehl bezüglich des Eingangsports gab es keine ähnliche Anforderung.

Die Timing-Reports mit datapath_only stehen am Ende von der Seite mit den Beispielen.

Zusammenfassung

set_input_delay und set_output_delay werden oft als die bevorzugten Befehle für I/O-Timing-Vorgaben betrachtet. In der Tat ist das meist die richtige Wahl, wenn die Schnittstelle system-synchron ist. In anderen Szenarien kann es sich lohnen, stattdessen set_max_delay und set_min_delay zu verwenden, weil sie die geforderten Einschränkungen am Timing des I/O-Ports besser widerspiegeln können.

Mit dieser Seite endet diese Serie von Seiten über Timing. Aber es gibt noch eine letzte Seite, die viele der Themen in einer Weise zusammenfasst, die sich gut zum Überprüfen eines bestehenden Designs eignet.