FIFOs mit asynchronen Eingangs- und Ausgangs-Taktraten

Anbieter zum Thema

vSync Circuits ltd

vSync Circuits Ltd.

MES Electronic Connect GmbH & Co. KG

Cadlog Group

IBR Leiterplatten GmbH & Co. KG

Kerne mit unterschiedlichen Taktfrequenzen in einem FPGA oder ASIC können Probleme erzeugen, die das ganze Design in Mitleidenschaft ziehen. Dieser Artikel zeigt hierfür praktische Lösungsansätze auf.

FIFOs mit asynchronen Taktraten werden häufig für die Datensynchronisation mit hoher Datenrate in FPGA- und ASIC-Designs verwendet. Ein fehlerhaft ausgelegter FIFO kann schwere Synchronisationsfehler auslösen, die ohne geeignete CDC-Verifizierung (Clock Domain Crossing) womöglich erst während der Validierungsphase im Labor oder gar später entdeckt werden. Wir betrachten hier Design-Kernpunkte, die bei der Entwicklung von FIFOs für diese Art von Systemen weiterhelfen.

Bild 1 zeigt die vereinfachte Darstellung einer FIFO-Architektur mit zwei asynchronen Taktraten. Der FIFO enthält einen internen Speicherpuffer, der entweder aus Flip-Flops oder einem Speicherkern besteht. Der Schreib-Port (WR_PORT) ist für das Write User Interface (WR_EN / WR_FULL) zuständig; er liegt in der WR-CLK Clock Domain und verwaltet einen zyklischen Schreibzeiger auf den Speicherpuffer. Auf der anderen Seite sorgt der Lese-Port (RD_PORT) für das Read User Interface (RD_EN / RD_EMPTY); er liegt in der RD-CLK Clock Domain und verwaltet ebenfalls einen zyklischen Lesezeiger auf den Speicherpuffer.

Bildergalerie

Durch den Vergleich von Schreib- und Lesezeiger erfolgt die Einstellung der Datenflußkontrolle des FIFO – Full und Empty Flags. Der Vergleich erfolgt separat in den einzelnen Ports; dazu sind die Schreib- und Lesezeiger mit den Port Clock Domains zu synchronisieren. Für eine geringere Synchronisationslatenz und Speichertiefe werden die Zeiger Gray-codiert und durchlaufen danach die Mehrfachbit-N-Flop-Synchronizer

Ausgangsregister des Grey-Codierers

Der Gray-Codierer ist eine rein kombinatorische Schaltungslogik. Hierin wird ein Binärzählwert B ein- und ein Gray-codierter Wert G ausgegeben. Beim Inkrementieren des Binärzählers kann es vorkommen, dass sich mehrere Bits im Wert B ändern. Die Gray-Codierung stellt sicher, dass sich bei jedem zyklischen B-Inkrement nur ein einziges Bit innerhalb des G-Werts ändert. Diese Funktion ermöglicht die Verwendung von N-Flop-Synchronizern mit einer geringen Synchronisationslatenz von nur ~N Zyklen. N wird entsprechend der gewünschten MTBF eingestellt. Der Synchronizer stellt sicher, dass nur gültige Zeigerwerte weitergegeben werden, solange sich immer nur ein einzelnes Bit am Synchronizer-Eingang ändert.

Der Gray-Codierer arbeitet kombinatorisch. An seinem Ausgang können während der Logik-Stabilisierung (bis zur Gatterlaufzeit) Glitches auftreten. Ändert sich etwa der Binäreingang B von "01" auf "10", treten am Ausgang G womöglich Glitches "01" → "00" → "11" auf; dabei ändert sich mehr als ein Bit gleichzeitig. Wenn der Ausgang des Gray-Codierers direkt mit dem N-Flop Synchronizer-Eingang verbunden ist, kann es zu Synchronisierungsfehlern kommen. Tritt der Glitch in der Nähe der Taktflanke auf bzw. ändern sich dort gleichzeitig mehrere Bits, könnte der Synchronizer einen falschen Wert latchen, der weder dem vorigen noch dem neuen Wert von G entspricht. Z.B: könnten die im Synchronizer gelatchten Daten "00" oder "10" sein - keine gültigen alten und auch keine gültigen neue Werte (die Änderung "00" → "11" am Synchronizer-Eingang könnte zu allen vier Möglichkeiten führen). Der falsche Wert wird über den Synchronizer weitergegeben. Dies verursacht einen Funktionsfehler, da die Empty- /Full Flags falsch gesetzt werden. In der Regel hat dies konstruktionsbedingte Ausfälle zur Folge.

Um Funktionsfehler zu vermeiden, muss der Ausgang des Gray-Codierers mithilfe des Takts des codierten Binärzeigers registriert werden. Damit wird der Glitch in der kombinatorischen Logik auf den Taktzyklus beschränkt und wird nicht zum N-Flop Sync-Eingang weitergeführt. Durch die Registrierung des Codierer-Ausgangs wird sichergestellt, dass sich am N-Flop Sync-Eingang innerhalb einer bestimmten Zeit immer nur ein einziges Bit ändert. Die eingehenden Daten werden in einen internen FIFO-Speicherpuffer geschrieben.

Berücksichtigung der Speicherschreiblatenz

Große Puffer werden gewöhnlich mittels Speicher-Cores von Technologieanbietern (FPGAs, ASIC-Bibliotheken etc.) implementiert. Bei steigender Flanke der Memory Write Clock (WR_CLK) tastet der Core die Schreibfreigabe-, Adress- (WR_PNT) und Datensignale ab, und die Speicherschreiboperation wird ausgeführt. Die Zeit, die er zum Latchen der Daten benötigt, hängt vom eingesetzten Speicher-Core ab. Bei manchen wird die Schreiboperation erst irgendwo zwischen der fallenden und steigenden Flanke der Write Clock ausgeführt, wie in Bild 2 gezeigt. Wenn hier die Read Clock (RD_CLK) schneller ist als die Write Clock, kann die Synchronisation des Schreibzeigers (WR_PNT) mit RD_CLK sowie das nachfolgende Lesen aus dem Speicherpuffer erfolgen, noch bevor die Daten im Speicher sind. In diesem Fall überträgt der FIFO ungültige Daten, und dies führt zu einem Funktionsfehler. Die Einführung eines zusätzlichen Registers für WR_PNT, der den Beginn der WR_PNT-Synchronisation um einen WR_CLK-Zyklus verzögert, löst das Problem (Bild 3).

Datenausgang auf der Speicher-Leseseite

Ist ein Speicherpuffer als Registerbank unter Verwendung von Flip-Flops implementiert, liegt er vollständig in der Write Clock Domain. Dies führt zu einem CDC zwischen den Pufferflipflops (WR_CLK) und der leseseitigen Logik (RD_CLK) gezeigt. Wenn das FIFO-Design keine Abtaststufe für den Datenpfad (RD_DATA) hast, ist die Datenausgabe des Puffers direkt außerhalb des FIFO mit der Benutzerlogik verbunden. Für einen Benutzer Design, der Daten und Steuerung nicht vermischt, kann dies jedoch keine Schwierigkeiten verursachen aber wenn eine Benutzersteuerlogik von den vom FIFO ausgegebenen Daten abhängt, kann die asynchrone RD_CLK-Störungsnatur der FIFO-Datenausgabe zur Metastabilität führen in Benutzerlogik. Dies wiederum kann zu einem vollständigen Funktionsausfall führen.

Eine bessere Praxis für einen FIFO-Entwurf wäre die Registrierung der Datenausgabe des FIFO im FIFO-Design selbst. Das stellt sicher, dass die Daten nicht als Kontrolle verwendet werden. Dann befindet sich die FIFO-Datenausgabe in der RD_CLK-Domäne, was keine Probleme hinsichtlich der folgenden Steuer- / Daten-Benutzerlogik verursacht.

Takterzeugung: Vier Möglichkeiten, um ein Taktsignal zu generieren

Takterzeugung

Programmierbare Takt-ICs mit integriertem Quarz

* Reuven Dobkin ist CTO von vSync Circuits und promovierter Elektrotechniker des Technion Israel Institute of Technology.

* Übersetzung mit freundlicher Unterstützung durch Sabine Pagler.

(ID:45397181)