Timing ist alles

Diese Seite ist die erste in einer Serie von Seiten zum Thema Timing.

Der Lohn ist innere Ruhe

Das Thema Timing, insbesondere die Timing-Constraints (timing constraints), ist eine große Herausforderung für den FPGA-Entwickler. Es ist nicht nur so, dass Timing schwer zu verstehen ist. Die eigentliche Herausforderung besteht darin, der Versuchung zu widerstehen, dieses Thema bei der Arbeit an einem FPGA-Design komplett zu ignorieren, weil doch alles funktioniert. Man tappt nur allzu leicht in die Falle, mit dem Design zufrieden zu sein, solange kein sichtbares Problem auftritt.

Es ist nicht ungewöhnlich, FPGA-Entwickler sagen zu hören, dass ihnen bewusst ist, dass ihr Design in Bezug auf das Timing zu wünschen übrig lässt – aber was soll’s, die Elektronik funktioniert wie ein Uhrwerk. Und tatsächlich kann es wie Zeitverschwendung erscheinen, das Timing ordentlich zu machen. Ein Manager, der unbedingt neue Funktionen entwickeln will, freut sich vermutlich nicht über ein paar Wochen ohne sichtbaren Fortschritt im Projekt. Eine gründliche Untersuchung des Timings kann zudem Probleme aufdecken, die unter Umständen schwer zu lösen sind. Für Außenstehende sieht das möglicherweise so aus, als würde man Probleme erfinden, die gar nicht existieren, um dann wertvolle Zeit mit deren Lösung zu verschwenden.

Die Wahrheit ist, dass sich die Strategie, das Timing zu ignorieren, kurzfristig oft auszahlt. Aber ziemlich häufig führt das Fehlen der gebotenen Sorgfalt bei diesem Thema zu den ärgerlichsten Problemen, und die tauchen meist in den unpassendsten Momenten auf. So kann die Elektronik beispielsweise während der Abnahmetests nur einmal in mehreren Stunden ausfallen, vielleicht wenn das System im vollen Temperaturbereich getestet wird. Oder noch schlimmer: Kundenbeschwerden treffen erst mehrere Jahre nach der Produkteinführung ein. Nach hektischen Bemühungen, die Ursache zu ergründen, stellt sich heraus, dass die FPGAs in diesen Produkten aus einer anderen Produktionscharge stammen. Obwohl alle FPGAs die Anforderungen des Datenblatts erfüllen, führten Unterschiede im Silizium dazu, dass sich die neuen FPGAs geringfügig anders verhalten.

FPGAs haben sich wegen solcher Vorfälle einen schlechten Ruf erworben. Wenn das Timing aber ordentlich gemacht ist, kann man ziemlich sicher sein, dass derartige Dinge nicht passieren. FPGAs sind äußerst zuverlässig, wenn das Design korrekt erstellt wurde.

Tu dir also einen Gefallen, nimm dir die Zeit, das Thema Timing zu lernen, und setze dieses Wissen anschließend immer vollständig ein. Das erspart dir die ständige Angst, dass etwas Unerwartetes mit dem Design passiert, sobald du irgendetwas änderst. Du ersparst dir außerdem die endlose Jagd nach Fehlern, die auftauchen und wieder verschwinden. Und vor allem wirst du dich daran gewöhnen, das FPGA als eine zuverlässige und absolut solide Komponente zu betrachten.

Die Bedeutung der Timing-Constraints

Die Logik in einem FPGA kann nur dann zuverlässig arbeiten, wenn die Timing-Anforderungen an jedem einzelnen synchronen Element im FPGA-Design erfüllt sind. Um das sicherzustellen, müssen alle möglichen Pfade (paths) untersucht werden. Selbst bei einem einfachen Logik-Design ist es unmöglich, all diese Berechnungen von Hand durchzuführen.

Es ist daher Aufgabe der Tools, sicherzustellen, dass alle Timing-Anforderungen erfüllt werden. Dazu müssen die Tools alle Informationen erhalten haben, die für die nötigen Berechnungen gebraucht werden. Sie müssen beispielsweise die Frequenzen aller Taktsignale kennen und wissen, wie sich externe Komponenten zeitlich verhalten. Diese Informationen erhalten die Tools über Timing-Constraints, die üblicherweise aus einer Textdatei mit einer speziellen Syntax bestehen.

Wenn die Timing-Constraints falsch geschrieben sind oder nicht alle notwendigen Informationen abdecken, haben die Tools keine Möglichkeit, den zuverlässigen Betrieb des Logik-Designs sicherzustellen. Die Tools verlassen sich auf die Informationen, die sie in den Timing-Constraints bekommen. Sind diese Informationen also falsch oder unvollständig, gilt das auch für die Timing-Berechnungen der Tools. Schlecht geschriebene Timing-Constraints sind ein häufiger Grund für unzuverlässiges Verhalten des FPGAs.

Die ungeschriebene Vereinbarung mit den Tools lautet also: Wir sagen den Tools alles, was sie über das Timing wissen müssen, und die Tools sorgen dafür, dass es im Design keine Timing-Verletzungen gibt.

Manchmal gelingt es den Tools aber nicht, Timing-Verletzungen zu vermeiden. In dem Fall gibt es eine Warnmeldung der Tools, die genau das sagt. Das ist nur eine Warnung und kein Fehler, also erzeugen die FPGA-Tools weiterhin eine Bitstrom-Datei (bitstream), die ins FPGA geladen werden kann. Deshalb ist es wichtig, stets zu prüfen, dass die Tools bestätigen, dass die Timing-Constraints erfüllt wurden. Diese Bestätigung hat normalerweise die Form einer Meldung wie „All timing constraints are met“.

Aber es geht nicht nur um Timing-Constraints

Die ungeschriebene Vereinbarung zwischen dir und der FPGA-Software ist eigentlich noch umfassender: Du hältst dich an einige Regeln, wie das FPGA-Design auszusehen hat, und die Tools sorgen dafür, dass das FPGA nicht versagt. Wenn du die Regeln brichst, schlagen die Tools zurück.

Das Timing richtig hinzubekommen, ist ein wesentlicher Teil dieser Regeln. Und Timing ist nicht nur eine Frage des Schreibens von Timing-Constraints. Es gibt drei getrennte Aspekte, die man im Blick haben sollte.

Der erste Aspekt ist das Logik-Design selbst, also der Verilog- (oder VHDL-) Code. Es gibt natürlich die offensichtliche Anforderung, dass die Logik „schnell“ genug sein muss (oder genauer: Das Logik-Design muss es dem Takt erlauben, mit der gewünschten Frequenz zu laufen). Darüber hinaus gibt es mehrere weitere Dinge, die man beachten sollte:

• Die grundlegenden Regeln für ordentliches Verilog (oder VHDL) müssen eingehalten werden, insbesondere das RTL-Paradigma. Andernfalls sind die Tools nicht in der Lage, die Timing-Constraints auf der Logik durchzusetzen, die der Synthesizer (synthesizer) erzeugt.
• Für Taktdomänen-Übergänge (clock domain crossings) werden geeignete Techniken verwendet (weitere Informationen hier).
• Die Taktsignale müssen so organisiert sein, dass keine Verwirrung entsteht. Insbesondere ist es wichtig, unbeabsichtigte Taktdomänen-Übergänge zu vermeiden.

Der zweite Aspekt ist das Schreiben von Timing-Constraints. Manchmal ist dieser Teil wirklich einfach, manchmal erfordert er sorgfältige Arbeit. Ein häufiger Fehler ist es, Timing-Constraints aus einem anderen Design zu kopieren (insbesondere nur eine Perioden-Constraint) und zu glauben, damit sei die Arbeit erledigt.

Der dritte Aspekt besteht darin, die Timing-Reports zu erzeugen und zu lesen, um sicherzustellen, dass die Tools ihren Zweck erfüllt haben und das Design zuverlässig funktioniert. Das ist der schwierigste Teil, vor allem weil diese Aufgabe ein Verständnis dafür erfordert, wie das FPGA im Inneren arbeitet: Die Timing-Reports sind in den kleinsten Bausteinen des FPGAs formuliert. Ohne ein solches Verständnis des FPGAs ist es daher schwierig, aus diesen Reports einen brauchbaren Schluss zu ziehen.

Normalerweise liest man die Timing-Reports, um ein Problem zu lösen, insbesondere wenn die Tools die Anforderungen aus den Timing-Constraints nicht erfüllen. Den Prozess, ein solches Problem zu lösen, nennt man Timing-Closure (timing closure). Das häufigste Problem ist, dass die Frequenz eines Takts für das Logik-Design zu hoch ist (man kann genauso gut sagen, die Logik ist für den Takt zu langsam).

Wie bereits erwähnt, ist es sehr zu empfehlen, das Timing des FPGA-Designs gelegentlich zu überprüfen, selbst wenn die Timing-Constraints erfüllt sind und alles einwandfrei funktioniert. Das bedeutet insbesondere, die Timing-Reports zu prüfen, aber auch zu verifizieren, dass die Timing-Constraints die Anforderungen der Logik wirklich widerspiegeln. Die Schwierigkeit liegt darin, dass eine solche Überprüfung kurzfristig keine Belohnung bringt: Sie erfordert Zeit und Mühe und endet entweder ohne Ergebnis oder mit der Entdeckung eines Problems. Wenn die Überprüfung also erfolgreich war, bedeutet das eigentlich mehr Arbeit, die ein Problem löst, das niemand sieht.

Wie diese Seiten zum Timing aufgebaut sind

Diese Seiten konzentrieren sich auf den zweiten und dritten Aspekt der ungeschriebenen Vereinbarung zwischen dir und den FPGA-Tools: das Schreiben von Timing-Constraints und das Lesen der Timing-Reports. Diese Fähigkeiten erfordern sowohl theoretisches Wissen als auch praktisches Handwerkszeug.

Die praktischen Aspekte der Timing-Constraints sind verhältnismäßig leicht zu lernen. Der schwierige Teil ist es, ihre genaue Bedeutung und ihre Auswirkung auf das Design zu verstehen. Die nächste Seite dieser Serie behandelt die grundlegenden theoretischen Konzepte. Auf den Seiten danach wird die Theorie anhand einiger Beispiele von Timing-Reports weitergeführt. Die ganze Geschichte steckt in den kleinen Details der Timing-Analyse.

Die beiden Seiten nach der nächsten Seite behandeln die wichtigste und nützlichste Timing-Constraint: die Perioden-Constraint. Diese beiden Seiten enthalten eine ausführliche Diskussion der Timing-Reports, weil diese so wichtig sind.

Die nächsten beiden Seiten behandeln Timing-Closure. Vielleicht ist es für dieses Thema etwas früh, aber es erklärt den Zweck der folgenden Themen: Fünf Seiten über Timing-Constraints (in der SDC-Syntax), die sich auf die Logikstruktur (logic fabric) beziehen. Danach folgen zwei Seiten über I/O-Timing-Constraints.

Die letzte Seite dieser Serie ist der Überprüfung eines bestehenden Designs gewidmet. Auf dieser Seite gibt es nichts Neues. Sie wiederholt vielmehr die bereits behandelten Themen, diesmal jedoch als eine Liste von Punkten, die man untersuchen sollte.

Die Themen sind in einer Reihenfolge dargestellt, die es ermöglicht, diese Seitenreihe von Anfang bis Ende zu lesen. Aber alle Themen hängen miteinander zusammen, daher gibt es viele Querverweise zwischen den Seiten.

Am besten machst du hier mit der nächsten Seite weiter. Es schadet nie, einen Blick in die Timing-Theorie zu werfen.