Die Validierung der Timing-Vorgaben

Diese Seite ist die letzte Seite einer Serie von Seiten über Timing. Die vorherigen Seiten haben die Theorie hinter Timing-Berechnungen erklärt, gezeigt, wie man mehrere Timing-Vorgaben (timing constraints) schreibt, und die Prinzipien des Timing-Closure besprochen.

Einführung

Ziemlich oft besteht die FPGA-Entwicklungstaktik darin, Funktionalität hinzuzufügen, zu reparieren, was nicht funktioniert, und das zu wiederholen. Es ist leicht, die Teile des Designs zu vernachlässigen, die möglicherweise falsch sind, aber noch kein sichtbares Problem darstellen.

Es ist entscheidend zu verstehen, dass ein FPGA-Design auch dann einwandfrei funktionieren kann, wenn Timing-Vorgaben falsch angewendet werden, und sogar, wenn sie nicht erfüllt werden. Der korrekte Umgang mit Timing-Vorgaben ist eine der wichtigsten Voraussetzungen für den stabilen und korrekten Betrieb des FPGAs. Wenn dieses Thema jedoch vernachlässigt wird, bedeutet das nicht unbedingt ein sofortiges Versagen. Vielmehr kann falsches Timing zu gelegentlichen Fehlfunktionen führen, die äußerst verwirrend sein können.

Diese Seite fasst viele der Vorschläge aus dieser Serie von Seiten über Timing-Vorgaben zusammen und wiederholt sie. Der Zweck ist, einige Themen hervorzuheben, die man im Hinterkopf behalten sollte, wenn man nach Problemen sucht, die auf unzureichendes Timing zurückzuführen sind. Man kann sich wünschen, die Weisheit zu haben, diese Themen gelegentlich um ihrer selbst willen zu überprüfen, aber im echten Leben tun die meisten von uns das, um ein Problem zu lösen, das ein wenig wie Zauberei wirkt.

Lesen Sie Ihren Timing-Report

Alle FPGA-Design-Tools erzeugen Timing-Reports. Der häufigste Grund, sie zu öffnen, ist, wenn die Tools die Timing-Vorgaben nicht erreichen: Dort findet man die fehlschlagenden Pfade (paths) und kann hoffentlich herausfinden, was man dagegen tun kann.

Es gibt jedoch einen nicht weniger wichtigen Grund, die Timing-Reports zu untersuchen: um zu verifizieren, dass die Timing-Vorgaben von den Tools wie beabsichtigt interpretiert und damit korrekt angewendet werden. Es ist eine gute Gewohnheit, diese Prüfung gelegentlich durchzuführen, insbesondere nach dem Hinzufügen neuer Timing-Vorgaben.

Da jedes FPGA-Design-Tool diese Reports in unterschiedlichen Strukturen und Formaten erzeugt, ist es nicht möglich, genau darauf einzugehen, was jeder Teil jedes Reports bedeutet. Diese Seite beschreibt daher die Prinzipien, die allen Tools gemeinsam sind. Die Formate und Fähigkeiten Ihrer eigenen Timing-Reports zu lernen, ist ohnehin eine gute Idee.

Ein weiterer möglicher Nutzen der Timing-Report-Prüfung besteht darin, dass sie eine falsche Verwendung von Logik aufdecken kann. Wenn das Design zum Beispiel falsch verwendete asynchrone Logik enthält oder von Takten abhängt, für die keine Timing-Vorgaben angewendet werden können, kann das im Timing-Report sichtbar werden: Weil es unmöglich ist, Timing-Vorgaben auf diese Logik anzuwenden, erscheint sie im Report möglicherweise als Pfade ohne Timing-Vorgabe (unconstrained paths).

Außerdem ist erwähnenswert, dass im Design enthaltene IP-Cores (IP cores) oft eigene Timing-Vorgaben beitragen, die die Tools zusätzlich zu den von Ihnen bereitgestellten hinzufügen. Es ist meist zwecklos, die Pfade zu prüfen, die mit diesen Vorgaben zusammenhängen, aber sie können den Timing-Report erheblich umfangreicher machen.

Interne Pfade ohne Timing-Vorgabe

Im Sinne dieser Diskussion ist ein synchrones Element ein Flipflop, Block-RAM, Schieberegister oder jedes andere Logikelement, das seinen Dateneingang abtastet und/oder seinen Datenausgang bei einer steigenden oder fallenden Flanke eines Takts ändert.

Alle Pfade, die vom Datenausgang eines synchronen Elements zum Dateneingang eines anderen synchronen Elements führen, müssen zeitlich erfasst sein, d.h. Timing-Vorgaben unterliegen. Die einzige Ausnahme besteht, wenn die Möglichkeit einer Timing-Verletzung am synchronen Element des Ziels ordnungsgemäß behandelt wird, wie bei unabhängigen Taktdomänen.

Mit anderen Worten: Der Pfad zu jedem synchronen Element muss zeitlich erfasst sein, es sei denn, es ist ein ausdrücklicher Resynchronisationsmechanismus vorhanden, der die Tatsache abdeckt, dass die Design-Tools keine Verantwortung für das Abtasten des Eingangssignals auf vorhersagbare Weise übernehmen.

Manchmal genügt eine Timing-Vorgabe in einer einzigen Zeile, die den Referenztakt definiert, und die FPGA-Tools übernehmen den Rest. In anderen Fällen ist mehr nötig. In wirklich schlimmen Fällen bleiben einige interne Pfade versehentlich ohne Timing-Vorgabe. Dafür gibt es mehrere mögliche Gründe, unter anderem:

• Vergessen, eine Timing-Vorgabe hinzuzufügen.
• Ein Pfad wird versehentlich als False Path definiert.
• Ein Pfad überquert Taktdomänen zwischen zusammenhängenden Takten (related clocks), aber die Tools behandeln sie als unabhängige Takte (unrelated clocks) (mehr dazu weiter unten).
• Die Timing-Vorgabe wird nicht durch ein Taktressourcen-Element propagiert. Wenn der Referenztakt zum Beispiel mit einer PLL des FPGAs verbunden ist, wird die Timing-Vorgabe normalerweise für den Eingangspin des FPGAs angegeben. Die Tools sollen dann automatisch Timing-Vorgaben für die Ausgangstakte der PLL erzeugen. Das tun sie meist, aber manchmal gibt es Überraschungen.
• Der Takt wird von Logik erzeugt (z.B. mit einem in der Logikstruktur implementierten Frequenzteiler) und ist nicht ausdrücklich von einer Timing-Vorgabe abgedeckt.

FPGA-Design-Tools unterstützen die Erstellung von Timing-Reports, die Pfade ohne Timing-Vorgabe (unconstrained paths) auflisten. Das sind Pfade, für die keine Timing-Vorgabe angewendet wurde. Grundsätzlich sollte diese Liste leer sein: Pfade, die keine Vorgaben benötigen, sollten in der Timing-Vorgabedatei ausdrücklich als False Paths definiert werden. Solche Vorgaben ändern funktional nichts an Pfaden, die ohnehin nicht zeitlich erfasst waren, ermöglichen aber, die Liste der Pfade ohne Timing-Vorgabe im Timing-Report leer zu halten. So lassen sich Pfade leicht erkennen, die versehentlich weggelassen wurden. Da die Anzahl der Pfade in dieser Liste begrenzt ist, können außerdem Pfade, die definitiv nicht in diese Liste gehören, verborgen bleiben, weil stattdessen harmlose Pfade aufgelistet werden.

Leider kann der Abschnitt für Pfade ohne Timing-Vorgabe in manchen Timing-Reports auch Pfade enthalten, die keinen Grund haben, von Timing-Vorgaben abgedeckt zu werden. Zum Beispiel der Pfad vom Ausgang eines Taktpuffers zum Eingang einer anderen Taktressource. Infolgedessen kann der Timing-Report viele Pfade als unconstrained auflisten, was völlig in Ordnung ist. Das macht es etwas schwieriger, die Situation aus dem Report abzuleiten, ist aber kein echtes Problem, da solche Pfade üblicherweise getrennt von Pfaden aufgelistet werden, die an einem Dateneingang eines Flipflops oder einem anderen synchronen Element enden. Es läuft also darauf hinaus, den Report sorgfältig zu lesen und darauf zu achten, was jede Gruppe aufgeführter Pfade bedeutet.

Der standardmäßig erzeugte Timing-Report ist manchmal nicht detailliert genug, um diese Informationen zu enthalten. Jedes vernünftige FPGA-Design-Tool erlaubt die Erstellung eines gezielten Timing-Reports, der Pfade ohne Timing-Vorgabe auflistet, sowie die Wahl, wie viele solcher Pfade für jede Gruppe aufgelistet werden sollen (10 ist eine vernünftige Zahl, auch wenn die betreffenden Listen vollständig leer sein sollten).

Pfade zwischen Taktdomänen

Timing-Vorgaben müssen auf internen Pfaden angewendet werden, deren Quelle und Ziel mit verschiedenen Takten synchron sind, wenn es zusammenhängende Takte (related clocks) sind (oder genauer: wenn die Logik sie als zusammenhängend behandelt). Andernfalls sollten sie nicht angewendet werden, denn diese unnötige Einschränkung kann hochwertige Routing-Ressourcen verschwenden und möglicherweise dazu führen, dass die Timing-Vorgaben nicht erreicht werden. Siehe diese Seite über zusammenhängende Takte vs. unabhängige Takte.

Jedes Werkzeugset hat seine eigene Methode, automatisch zu entscheiden, ob ein Taktpaar als zusammenhängend betrachtet wird. Tools, die in ihren Timing-Vorgabedateien die SDC-Syntax verwenden (z.B. Vivado und Quartus), haben einen set_clock_groups-Befehl, mit dem sich Gruppen zusammenhängender und unabhängiger Takte definieren lassen. Es gibt auch andere Methoden, die Tools dabei zu leiten, insbesondere durch False-Path-Timing-Vorgaben.

Die Frage ist also, wie man prüft, ob die Tools Takte als zusammenhängend betrachten oder nicht. Die leider unbefriedigende Antwort ist, dass jedes Werkzeugset eine andere Methode hat. Vivado zum Beispiel hat einen Clock Interaction Report mit einem Farbdiagramm, das die Situation für jedes Taktpaar zeigt:

• Die Pfade von einem Takt zum anderen wurden zeitlich erfasst (die Takte gelten also als zusammenhängende Takte).
• Die Pfade von einem Takt zum anderen wurden nicht zeitlich erfasst („User Ignored Paths“).
• Einige der Pfade wurden zeitlich erfasst.

Alternativ können benutzerdefinierte Timing-Reports verwendet werden, die auf bestimmte Pfadgruppen beschränkt sind, um diese Frage zu untersuchen. Die Pfade können anhand der beteiligten Takte ausgewählt werden. Dazu wählt man Pfade aus, die an Logikelementen beginnen, die mit dem einen Takt synchron sind, und an einem anderen Takt enden. Es kann auch nützlich sein, sich gezielt Gruppen von Pfaden anzusehen, von denen bekannt ist, dass sie an Taktdomänenübergängen beteiligt sind.

Auch wenn es schwierig sein mag: Es ist entscheidend, umfassend zu prüfen, auf welche Taktdomänenübergänge die Tools Vorgaben anwenden und ob diese korrekt sind. Gleichzeitig ist es eine Gelegenheit zu prüfen, ob das Logikdesign dort Resynchronisationslogik hat, wo sie benötigt wird. Es ist leicht, wegen Verwirrung darüber, welcher Takt mit welchem Signal verwendet wird, bei einem Taktdomänenübergang zu enden, der nicht sicher ist.

Es ist wichtig, diese Prüfung im Hinblick auf die Natur jedes Takts durchzuführen. Wenn zum Beispiel zwei Takte von verschiedenen Oszillatoren dieselbe beabsichtigte Frequenz haben und daher in der Timing-Vorgabedatei ähnlich definiert sind, könnten die Tools sie fälschlich als zusammenhängend betrachten und das Timing auf Pfaden berechnen, die von einem Takt zum anderen führen. Vorgaben auf solche Pfade anzuwenden ist bedeutungslos, da es keinerlei Garantie für die Phasenbeziehung zwischen den beiden Takten gibt. Für sich genommen erschweren unnötige Timing-Vorgaben nur das Erreichen des Timings, was ziemlich harmlos sein kann. Das eigentliche Problem ist, dass der Timing-Report uns zu der Annahme verleiten kann, die Takte seien tatsächlich zusammenhängend. Wenn man nur die Vorgaben und die Reports betrachtet, könnten die Pfade zwischen ihnen also sicher erscheinen (d.h. keinen Schutz gegen Timing-Verletzungen benötigend), obwohl sie es nicht sind: Die beiden Takte haben außer ungefähr derselben Frequenz nichts gemeinsam. Der einzige Weg, Fehler dieser Art zu vermeiden, ist zu verstehen, wie jeder Takt erzeugt wird.

Externe Pfade ohne Timing-Vorgabe

Timing-Vorgaben sollten immer auf Pfade angewendet werden, die an I/O-Pins beginnen oder an I/O-Pins enden. Es gibt eine separate Seite, die erklärt, wie das gemacht wird. Die einzige Ausnahme sind Takteingangspins und Pins mit einer speziellen Schnittstelle, z.B. Gigabit-Transceiver, direkt mit einem Hardware-Prozessor auf dem FPGA-Silizium verbundene Pins usw. Wenn die Schnittstelle sehr langsam ist, ist es auch verzeihlich, keine Timing-Vorgaben zu definieren. Zum Beispiel bei LEDs, Tastern und sogar I²C-Leitungen. Aber es ist viel besser, für solche Pins False-Path-Vorgaben zu vergeben, weil die Liste der I/O-Pins ohne Timing-Vorgabe im Timing-Report leer bleibt.

Oft scheint es bedeutungslos, Timing-Vorgaben auf externe Pfade anzuwenden. Zum Beispiel, wenn mehrere Ausgangspins alle mit demselben Takt synchron sind und das korrekte Timing dadurch gewährleistet ist, dass sie alle gleichzeitig umschalten. Eine übliche Methode, dieses gleichzeitige Umschalten zu implementieren, ist die Verwendung des IOB-Registers. Dieses Flipflop liefert die bestmögliche Takt-zu-Ausgang-Verzögerung und auch einen bemerkenswert geringen Taktversatz (clock skew) zwischen Ausgangspins.

Dies ist jedoch ein gutes Beispiel dafür, wann Timing-Vorgaben auf Ausgangspins wichtig sind: Wenn die Timing-Vorgaben eng gehalten werden, wird ein geringer Taktversatz zwischen diesen Pins sichergestellt. Bei Verwendung des IOB-Registers können enge Timing-Vorgaben ein Weg sein, die Tools zur Verwendung dieses Flipflops zu zwingen, oder sicherzustellen, dass es nicht unbemerkt bleibt, wenn die Tools das nicht tun: Wenn die Tools das Flipflop nicht wie gewünscht platzieren, scheitert das Timing.

Aus ähnlichen Gründen sollten auch enge Timing-Vorgaben auf Eingangspins angewendet werden.

Wenn Timing-Vorgaben für einen geringen Taktversatz zwischen mehreren Pins verwendet werden, ist es wichtig, die I/O-Pins nicht nur so weit einzuschränken, bis die gemeldete Zeitmarge (slack) nahezu null ist, sondern zu überprüfen, ob strengeres Timing zum Scheitern der Vorgabe führt. Der I/O-Signalpfad kann optionale Verzögerungsleitungen enthalten, die die Tools auf unerwartete Weise nutzen können. Quartus von Intel FPGA kann zum Beispiel eine Verzögerung im Eingangspfad hinzufügen, wenn ein Timing-Budget-Überschuss vorhanden ist. Die Wahl der Tools, das zu tun, kann weder gewünscht noch erwartet sein.

Falsche False Paths und anderweitig gelockertes Timing

Manchmal werden Timing-Vorgaben angewendet, sind aber zu großzügig. Das ist viel schwerer zu erkennen, da die betreffenden Pfade zeitlich erfasst sind, nur mit der falschen Anforderung.

Es gibt mehrere mögliche Gründe für solche Missgeschicke, unter anderem:

• False-Path-Vorgaben werden versehentlich auf Pfade angewendet, die sie nicht betreffen sollten, höchstwahrscheinlich wegen eines Fehlers im Ausdruck, der festlegt, welche Logikelemente abgedeckt sind.
• Gleiches Problem für andere spezifische Timing-Vorgaben, z.B. falsche Timing-Anforderungen für Multicycle-Pfade.
• Der Wert, der die gewünschte Zeitgröße angibt, ist in der Timing-Vorgabe falsch angegeben.
• Die FPGA-Design-Tools spielen einen gemeinen Trick. Zum Beispiel kann Quartus von Intel FPGA Pfaden eine falsche Taktfrequenz zuweisen, wenn die Anweisung „derive_pll_clocks“ nicht in der SDC-Datei steht.

Es gibt kein einfaches Rezept, um Probleme dieser Art zu finden. Den Timing-Report sorgfältig von oben bis unten zu lesen, ist sicherlich eine gute Idee. Selbst wenn der Report für jede Gruppe 10 Pfade anzeigt, gibt es keine Garantie, dass die problematischen Pfade zufällig dort erscheinen. Oder bei einer beliebigen Anzahl angezeigter Pfade.

Ein anderer Weg, das anzugehen, besteht darin, die geschriebenen Timing-Vorgaben zu überprüfen. Da SDC-Vorgaben in Tcl geschrieben sind, ist es möglich, die Ausdrücke auszuwerten, die in der Vorgabedatei die Logikelemente auswählen (mit „from“ und „to“), und die Liste der Endpunkte durchzulesen.

Wenn also zum Beispiel diese Zeile in einer Vivado-.xdc-Datei steht:

set_false_path -to [ get_pins -hier -filter {name =~ */pclk_i1_bufgctrl.pclk_i1/S*} ]

kann man das implementierte Design öffnen und die Ziele auflisten, auf die die False Paths angewendet werden:

puts [join [ get_pins -hier -filter {name =~ */pclk_i1_bufgctrl.pclk_i1/S*} ] "\n" ]

Die Tcl-Befehle („puts“ und „join“) sorgen dafür, dass jedes Element in einer eigenen Zeile aufgelistet wird, sodass die Ausgabe leicht zu lesen ist (sie kann sehr lang sein).

Diese Art der Überprüfung der Vorgaben ist wichtig, aber ebenso schwierig, weil sie echtes Nachdenken erfordert.

Zusammenfassung

Sicherzustellen, dass die Tools die korrekten Timing-Grenzen auf den verschiedenen Pfaden durchsetzen, ist eine knifflige Aufgabe. Es ist eine Kombination aus dem Wissen, was die Timing-Vorgabe-Anweisungen genau bedeuten, und dem Wissen, wie man Timing-Reports prüft, um die Chancen zu erhöhen, Fehler zu entdecken.

Aber mehr als alles andere geht es um die Selbstdisziplin, das Design zu prüfen und erneut zu prüfen, insbesondere wenn es einwandfrei zu funktionieren scheint.