Einführung
Diese Seite behandelt source-synchrone Dateneingänge (englisch: source-synchronous inputs): Diese Technik bedeutet, dass die Dateneingänge synchron zu einem Takt sind, den die externe Komponente parallel zu diesen Eingängen erzeugt.
Diese Methode wird oft schlicht deshalb verwendet, weil die externe Komponente nun einmal so arbeitet. Ein weiterer guter Grund ist, dass die Datenquelle physisch weit vom FPGA entfernt liegt. Möglich ist auch, dass sich ein Kabel oder ein Steckverbinder zwischen dem FPGA und der Gegenseite befindet. Ein Beispiel dafür ist eine Digitalkamera, die Pixeldaten sendet.
Eine mögliche Schwierigkeit bei einem source-synchronen Takt (englisch: source synchronous clock) besteht darin, dass er möglicherweise nicht durchgehend aktiv ist. Das Taktsignal kann zudem durch eine lose physische Verbindung oder übermäßiges Rauschen beeinträchtigt sein. Es kommt auch vor, dass der Takt keine konstante Taktperiode hat oder der Jitter (englisch: jitter) übermäßig hoch ist. Das passiert häufig, wenn die Quelle der Daten (und damit auch des Takts) ein I/O-Peripheriegerät eines Mikroprozessors ist.
Beachten Sie, dass es eine separate Seite gibt, die die Beziehungen zwischen Takt und Daten allgemein behandelt.
Umgang mit einem instabilen Takt
Der wichtigste Grundsatz bei source-synchronen Eingängen lautet, dass der Takt nicht direkt mit Logikelementen im FPGA verbunden werden sollte. Der innerhalb des FPGAs verwendete Takt sollte vielmehr ein sauberer Takt sein, der von einer PLL im FPGA erzeugt wird.
Wenn ein externer Takt direkt mit der Logik im FPGA verbunden wird, kann es zu seltsamen Problemen kommen: Ein schlechter Takt erzeugt unerwartete Verhaltensweisen, die nicht wie ein Problem mit dem Takt aussehen. Übermäßiger Jitter und Störimpulse (Glitches) können die Timing-Anforderungen verletzen, die den zuverlässigen Betrieb des Designs gewährleisten. Die Folge ist, dass praktisch alles passieren kann, einschließlich Situationen, die laut Verilog-Code unmöglich sind. Es ist daher leicht, fälschlich anzunehmen, das Problem sei ein Fehler im FPGA-Design.
Es liegt nahe, fälschlich anzunehmen, dass Probleme mit einem Takt lediglich zum Verlust von Taktzyklen führen und dadurch einige Datenelemente fehlen. Wenn ein schlechter Takt jedoch andere Probleme verursacht, konzentrieren sich die Lösungsversuche oft auf die Teile des Logikdesigns, die am ehesten damit zusammenhängen. Das kann viel Zeit kosten.
Die einzige Situation, in der ein externer Takt direkt von der Logikstruktur verwendet werden kann, ist, wenn dieser Takt garantiert stabil und sauber ist. Wenn dieser Takt beim Start des FPGAs nicht stabil ist, muss dieser Umstand behandelt werden: Solange der Takt instabil ist, muss an die Logik, die auf diesen Takt angewiesen ist, ein Reset angelegt werden.
Mögliche Strategien
Es gibt im Wesentlichen vier mögliche Strategien für die Synchronisation mit dem externen Takt. Diese Strategien werden unten in beliebiger Reihenfolge besprochen.
Strategie #1: 01-Signal-Abtastung
Diese Strategie ist die robusteste Methode für source-synchrone Eingänge. Wenn sich der externe Takt nicht richtig verhält, hat die 01-Signal-Abtastung (englisch: 01-signal sampling) einen klaren Vorteil gegenüber jeder anderen Methode. Allerdings ist diese Methode nur dann sinnvoll, wenn die Frequenz des Takts der Datenquelle relativ niedrig ist.
Diese Methode wird auf einer eigenen Seite gesondert besprochen.
Strategie #2: Verwendung einer PLL
Bei dieser Strategie wird der externe Takt an den Eingang einer PLL auf dem FPGA gelegt. Der Ausgangstakt dieser PLL versorgt die Logikelemente. An diese Logikelemente wird ein Reset-Signal angelegt, solange die PLL nicht gelockt hat. Diese Lösung stellt sicher, dass die Logikelemente mit einem stabilen Takt arbeiten: Wenn der Ausgangstakt der PLL nicht stabil ist, werden die Logikelemente durch den Reset in einem definierten Zustand gehalten.
Die PLL erleichtert es außerdem, die Timing-Constraints einzuhalten, verglichen mit einer direkten Verbindung des externen Takts: Die PLL kompensiert die Verzögerung zwischen dem Takt-Pin und dem internen Takt des FPGAs.
Allerdings ist zu beachten, dass Unzulänglichkeiten des externen Takts zu übermäßigem Jitter am Ausgang der PLL führen können. Der Lock-Detektor der PLL meldet möglicherweise weiterhin einen ordnungsgemäßen Betrieb, obwohl der erzeugte Takt ungewöhnlich verrauscht ist. Dafür gibt es keine einfache Lösung. Eine Möglichkeit besteht darin, die Timing-Constraints für die Logik, die vom Ausgang der PLL abhängt, anzupassen. So kann etwa der angenommene Jitter des Takts in den Timing-Constraints auf einen Wert erhöht werden, den die PLL vermutlich nicht überschreiten wird (weil es sonst zu einem Verlust des Lock käme).
Diese Strategie weist eine Ähnlichkeit mit dem systemsynchronen Takt (englisch: system synchronous clock) auf: In beiden Szenarien wird der externe Takt mit einer PLL verbunden, und der Ausgang dieser PLL wird innerhalb des FPGAs verwendet. Die Timing-Constraints werden daher auf dieselbe Weise geschrieben wie für einen systemsynchronen Takt.
Beachten Sie, dass die PLL ihren Ausgangstakt normalerweise so auf den externen Takt ausrichtet, dass dies für einen systemsynchronen Takt optimal ist. Die optimale Ausrichtung für einen source-synchronen Takt kann geringfügig anders sein. In beiden Fällen sind die Takte nicht exakt zueinander ausgerichtet. Vielmehr gibt es einen gewollten kleinen zeitlichen Versatz zwischen den Taktflanken. Dieser zeitliche Versatz erleichtert es, die Timing-Anforderungen der I/O-Register zu erfüllen. Manche PLLs können so konfiguriert werden, dass die Takte für eine optimale Leistung mit einem source-synchronen Takt ausgerichtet werden.
Diese Strategie ist im Vergleich zu den anderen hier aufgeführten Strategien am einfachsten zu implementieren. Sie eignet sich für relativ hohe Taktfrequenzen. Bei Frequenzen nahe dem Maximum, das der I/O unterstützt, wird diese Strategie wahrscheinlich nicht funktionieren.
Strategie #3: Phasenverschiebung
Diese Strategie, also die Phasenverschiebung (englisch: phase shifting), wird in der Regel dann gewählt, wenn die Datenrate nahe an dem Maximum liegt, das das FPGA unterstützen kann.
Die üblichen Verfahren zur Sicherstellung der Timing-Anforderungen funktionieren bei solchen Datenraten nicht mehr: Die Timing-Constraints werden unerreichbar. Eine zuverlässige Abtastung der Datensignale ist dennoch möglich.
Das Problem mit Timing-Constraints besteht darin, die Timing-Anforderungen über eine Berechnung sicherzustellen: Eine solche Berechnung enthält mehrere unsichere Parameter, etwa Fertigungsunterschiede des FPGAs. Wenn diese Parameter berücksichtigt werden, liefern die Berechnungen kein Timing, das eine zuverlässige Abtastung gewährleistet. Bei sehr hoher Datenrate gibt es keinen Timing-Spielraum, den man für diese Unsicherheiten opfern könnte.
Bei einem konkreten FPGA-Baustein sind diese Parameter jedoch konstant. Die Lösung besteht daher darin, das korrekte Timing zu suchen, während das FPGA arbeitet. In der Praxis bedeutet das, dass ein Zustandsautomat (englisch: state machine) innerhalb des FPGAs die Verzögerung zwischen dem Datentakt und dem Abtastzeitpunkt einstellt. Es wird also ein adaptiver Mechanismus verwendet, um das optimale Timing zu finden, anstatt sich auf Berechnungen zu verlassen. Dieser Mechanismus wird Phasenverschiebung genannt.
Diese Strategie wird häufig bei den Datensignalen von DDR-SDRAM-Speichern verwendet. Bei dieser Anwendung wird stets angestrebt, eine möglichst hohe Datenrate zu erreichen. Daher werden die Fähigkeiten der I/O-Ports bis an ihre Grenzen ausgereizt. Dementsprechend ist die Phasenverschiebung der einzige Weg, um eine zuverlässige Abtastung der Dateneingänge sicherzustellen: Nachdem der DDR-Speicher initialisiert wurde, wird eine bestimmte Datenfolge in den Speicher geschrieben (die Datensignale zum Speicher sind source-synchrone Ausgänge, sodass es beim Timing keine Schwierigkeiten gibt). Das FPGA liest danach wiederholt aus demselben Bereich des DDR-Speichers. Ein Zustandsautomat findet das optimale Timing, indem er die Verzögerung der Abtastung schrittweise verändert. Die erwarteten Eingangsdaten sind bekannt, weil es dieselbe Datenfolge ist, die zuvor geschrieben wurde. Der Zustandsautomat kann daher leicht bewerten, wie zuverlässig die Daten sind, und das optimale Timing ermitteln.
Ein interessantes Merkmal dieses Mechanismus ist, dass der vom DDR-Baustein gelieferte Datentakt ignoriert werden kann: Der DDR-Speicher ist mit dem Takt synchronisiert, den das FPGA erzeugt. Dieser Takt ist Teil der source-synchronen Ausgänge, die der DDR-Speicher empfängt. Es ist daher gewährleistet, dass der Datentakt der source-synchronen Eingänge exakt dieselbe Frequenz hat wie der vom FPGA erzeugte Takt. Der Phasenverschiebungsmechanismus kann sich daher auf den internen Takt stützen statt auf den Takt, der zusammen mit den Daten ankommt. Es spielt keine Rolle, dass zwischen diesen beiden Takten eine unbekannte Verzögerung liegt: Der Zustandsautomat findet das optimale Timing unabhängig von dieser Verzögerung.
Tatsächlich ist dies die übliche Implementierung dieses Mechanismus bei DDR-Speichern: Obwohl DDR-Speicher einen source-synchronen Takt besitzen (Daten-Strobe genannt), ignoriert die übliche Implementierung der Phasenverschiebung dieses Signal. Der Grund ist, dass es wichtiger ist, einen zuverlässigen Empfang der Datensignale sicherzustellen, als mit dem Strobe ausgerichtet zu sein.
Die Verwendung der Phasenverschiebung kann also die Notwendigkeit eines Datentakts beseitigen. Stattdessen kann ein interner Takt verwendet werden, sofern garantiert ist, dass seine Frequenz exakt der Datenrate entspricht.
Bei dieser Strategie haben die Timing-Constraints denselben Zweck wie bei normalen IOB-Registern.
Strategie #4: Den Takt direkt verwenden
Diese Strategie erscheint auf den ersten Blick als die einfachste: Der externe Takt wird direkt mit Flip-Flops im FPGA verbunden. Etwa so:
module top (
input data_clk,
input [7:0] data
);
reg [7:0] data_samp;
always @(posedge data_clk)
begin
data_samp <= data;
[ ... ]
end
Wie oben erwähnt, ist diese Strategie normalerweise keine gute Idee. Der Hauptgrund ist, dass bei einem Störimpuls (Glitch) auf @data_clk die gesamte Logik, die von diesem Takt abhängt, unvorhersehbar wird.
Es kann sinnvoll sein, einen externen Takt auf diese Weise zu verwenden, wenn garantiert ist, dass er sauber und stabil ist. Aber selbst wenn das garantiert ist, kann es schwierig sein, die Timing-Anforderungen zu erfüllen, weil zwischen dem Takt-Pin und den Flip-Flops eine Verzögerung liegt. Manche FPGAs verfügen über spezielle Taktressourcen, um diese Verzögerung zu verringern. Dies kann erfordern, einen dedizierten Takt-Eingangspin zu verwenden und die I/O-Ports auf bestimmte Bereiche des FPGAs einzuschränken.
Wenn der Takt direkt verwendet wird, werden die Timing-Constraints auf dieselbe Weise geschrieben wie für einen systemsynchronen Takt.
Die naheliegende Alternative zu dieser Strategie ist, wie oben vorgeschlagen, eine PLL zu verwenden. Wenn der Datentakt nicht stabil ist, sollte die 01-Signal-Abtastung in Betracht gezogen werden.
Zusammenfassung
Es ist kein Zufall, dass die 01-Signal-Abtastung auf dieser Seite zuerst genannt wurde und diese Strategie auf einer separaten Seite beschrieben wird: Sie ist die am meisten empfohlene Methode, sofern die Datenrate nicht höher ist, als es diese Methode erlaubt.
Wenn andere Strategien in Betracht gezogen werden, ist es wichtig, auf die Stabilität des Datentakts zu achten. Weicht ein Takt von seinem zulässigen Verhalten ab (also von der Taktperiode und dem maximalen Jitter), kann dies zu einer dauerhaften und nicht behebbaren Fehlfunktion der betreffenden Logik führen. Nur ein Reset bringt die Logik zurück in den normalen Betrieb.
Die Verwendung einer PLL zur Erzeugung eines zuverlässigen Takts verbessert die Situation erheblich: Der Ausgang der PLL ist zuverlässig, solange ihr Lock-Detektor dies meldet. Andernfalls sollte an diese Logik ein Reset angelegt werden.