FPGA - „sehr nahe“ Uhr vom Signal synchronisieren

Dies ist eher eine Lernfrage, ich kann das Problem lösen, aber es wäre gut zu wissen, wie es geht - kann eine Uhr aus einem Signal rekonstruiert werden, und ist es einfacher, wenn die Frequenz der Uhr im Grunde bekannt ist?

Ich verwende ein Terasic DE10 Lite-Board und spiegele Videos von einem Mac SE/30 (512 x 342 x 1 bpp) auf einem VGA-Display. Mac-Verbindungen sind vsync, hsync und Pixel von der analogen Platine, der Pegel wird auf 3,3 V konvertiert und dann mit den GPIOs der FPGA-Platine verbunden. Bei 1024 x 768 passt es ziemlich gut, wenn die Pixel verdoppelt werden. Ein VGA-Ausgang bei 60 Hz ist nicht schwer, ein ALTPLL-IP-Block bei 65 MHz macht es nur noch eine Frage des Zählens der vorderen/hinteren Veranda und der Synchronisierungsimpulse.

Das Kopieren des Mac-Signals ist etwas schwieriger. Ich endete mit einem @always auf einem ALTPLL-Takt, der mit 15,67 MHz lief (und experimentierte mit mult/div-Zahlen, um zu versuchen, es so nah wie möglich zu bekommen), der Pixelausgaberate des Mac. Ich kann die Taktrate auf diese Weise nicht genau anpassen . Dies zählt die vertikale Leerperiode herunter, zählt dann für jede Zeile, bis Pixel beginnen, und tastet jedes Pixel ab. Pixel werden in eine Platte aus Dual-Port-RAM geschrieben, die aus einem anderen IP-Block besteht, und von der VGA-Routine ausgegeben.

Das funktioniert und ist perfekt lesbar. Aber es ist hässlich, da es aufgrund der leicht nicht übereinstimmenden Uhren zu Abtastfehlern kommt. Wenn ich statt des ALTPLL-Taktes CPUCLK vom PDS-Anschluss des Macs nehme und damit die Pixel takte, ist alles so ruhig wie möglich. Unter Verwendung des FPGA-Taktes sind die Pixel instabil und ändern sich zufällig, wo sie es nicht sollten.

Die Frage ist, was tun Sie, wenn Sie die Systemuhr nicht nehmen können? Ich denke, es muss eine Möglichkeit geben, Frequenz und Phasenverschiebung basierend auf der Eingabe dynamisch anzupassen, aber ich weiß nicht, wo ich suchen soll.

(Diese Frage wurde bei Stack Overflow nicht beantwortet, passt hier vielleicht besser)

Antworten (2)

Keine zwei Uhren werden jemals perfekt zusammenpassen. Das Verfahren zum Bestimmen der wahren Taktfrequenz aus den Daten wird "Taktwiederherstellung" genannt.

Wenn Sie die nominelle Bitrate kennen, besteht eine einfache Methode, die keine Verwendung eines PLL/DCM-Blocks erfordert, darin, die Daten zu überabtasten und nach Flanken zu suchen. Normalerweise müssten Sie mindestens um das 4-fache der Bitrate überabtasten. So funktioniert es...

  1. Erstellen Sie in Ihrem Teil eine Uhr mit der 4-fachen Bitrate. Bei einer Bitrate von 65 MHz ist dies ein Takt von 260 MHz.

  2. Bei Verwendung des 260-MHz-Takts werden die eingehenden Bits doppelt oder dreifach registriert, um Probleme mit der Metastabilität zu vermeiden. Diese Art von Problemen kann auftreten, wenn sich ein Eingangssignal sehr nahe an einer Taktflanke ändert. Dies tritt fast garantiert auf, wenn Daten mit einem anderen Takt abgetastet werden, aus dem die Daten generiert wurden.

  3. Führen Sie optional zwei zusätzliche Registrierungsphasen durch und führen Sie eine 2-von-3-Mehrheitsabstimmung über die letzten drei Phasen durch. Dadurch wird die falsche Erkennung von Kanten aufgrund von Rauschen reduziert, was im nächsten Schritt wichtig wird, da Sie Kanten in den Daten verwenden, um die Taktrate zu ermitteln.

  4. Machen Sie einen freilaufenden Zwei-Bit-Zähler, der von 0 bis 3 zählt und dann auf 0 zurückrollt. Der Zähler wird durch den 260-MHz-Takt getaktet.

  5. Immer wenn Sie bei den Eingangsdaten einen Übergang von 0 auf 1 oder 1 auf 0 sehen, gehen Sie davon aus, dass Sie sich an einer Taktflanke befinden, und setzen Sie den Zähler auf 1 zurück (cnt <= "01").

  6. Immer wenn der Zähler einen Wert von 2 hat (cnt = "10"), verwenden Sie die Ausgabe Ihrer Mehrheitsstimme als Ihre Eingabeprobe. Und wenn Sie eine Pixelzählung führen, erhöhen Sie diese ebenfalls.

Ich habe die obige Methode persönlich verwendet, um die Uhr für serielle Daten bis zu 100 Mbit / s erfolgreich wiederherzustellen.

Je nachdem, ob die eingehenden Daten etwas schneller oder langsamer als Ihre Uhr sind, überspringt der Zähler einen Tick oder hält einen zusätzlichen Tick, um die Zählrate an die Daten anzupassen.

Bei einer langsameren Datenrate sehen Sie so etwas wie...
...0,1,2,3,0,1,2,3, 0,1,1,2,3 ,0,1,2,3, 0,1,2,3...

Für eine schnellere Datenrate sehen Sie so etwas wie...
...0,1,2,3,0,1,2,3, 1,2,3 ,0,1,2,3,0,1, 2,3...

Es gibt eine andere Methode, bei der Sie das 4-fache Oversampling mit zwei Takten durchführen können, die dieselbe Rate wie Ihr Pixeltakt haben, aber um 90 Grad phasenverschoben sind. Durch das Sampling in vier Register (eines beim Steigen und eines beim Fallen für jeden Takt) können Sie den gleichen Effekt erzielen wie mit dem Zähler-basierten Setup oben. Die maximal möglichen Pixelraten sind bei dieser Methode höher, aber die Logik ist etwas komplexer.

Das Problem bei der Taktwiederherstellung über unverriegeltes Oversampling besteht darin, dass häufige Übergänge erforderlich sind, da die Genauigkeit, mit der die Breite eines übergangsfreien Bereichs gemessen werden kann, durch den Fehler beim Anpassen der unabhängigen Takte begrenzt ist. Als solches würde dies wahrscheinlich gut für eine Scanline funktionieren, die Text enthält. Aber waren das in einer leeren Zeile mit nur ein oder zwei Pixeln eines dekorativen Begrenzungsrahmens auf jeder Seite 490 Pixel dazwischen oder 492? Selbst ein Bruchteil eines Prozentfehlers beim Anpassen der Uhr führt dazu, dass der rechte Rand von Zeilen ohne Text nicht mit dem rechten Rand von Zeilen übereinstimmt.
Aus diesem Grund wird ein praktisches System wie der Monitor, den es ersetzt, eine PLL auf ein Vielfaches der horizontalen Synchronisierungsfrequenz sperren und die Datenübergänge nur in einem statistischen Sinne analysieren, um die Anzahl der Punkttakte zwischen den Synchronisierungen und das Potenzial zu ermitteln Teiloffset des Syncs zur idealen Abtastposition für das erste Pixel. Vielleicht kann dieses entsperrte Oversampling im eingeschränkten Fall eines Videos mit einer einzigen Quelle und einem Video mit niedriger Auflösung und zwei Zuständen funktionieren; aber es ist nicht das, was in einer gewöhnlichen Produktlösung wie einem gleichmäßigen Graustufen-LCD-Monitor oder einer Aufnahmekarte enthalten ist. Das FPGA hat sicherlich eine PLL.
@ChrisStratton Für 768 Zeilen x 60 fps liegt die HSYNC-Frequenz wahrscheinlich bei etwa 46 kHz. Sie verwenden das Terasic DE10-Board mit dem 5CSXFC6D6F31C6N-FPGA. Die minimale PLL-Eingangsfrequenz auf diesem FPGA beträgt 5 MHz, was dem 100-fachen der HSYNC-Frequenz entspricht. Daher können sie HSYNC nicht direkt in die PLL einspeisen, und da es sich um ein COTS-Demoboard handelt, kann man nicht einfach externe PLL-Hardware hinzufügen, die die niedrigere Frequenz akzeptieren würde. Ich bin mir nicht sicher, wie sie die PLL in ihrem Fall zum Laufen bringen würden.
Das ist in der Tat ein kleines Rätsel für die PLL. Während Ihre Idee zur Wiederherstellung der Uhr möglicherweise lesbaren Text liefern kann, wird sie jedoch keine Ausrichtung ergeben, es sei denn, die freilaufende Uhr ist genau genug, dass das ursprüngliche Problem des falsch lesbaren Textes kein Problem gewesen wäre. Es kann notwendig sein, eine externe PLL hinzuzufügen, möglicherweise innen wieder zu multiplizieren. Tatsächlich haben diese Demo-Boards Header, die genau dafür ausgelegt sind, zusätzliche externe Schaltungen zu unterstützen.
@ChrisStratton Die gleiche Gegenidee könnte anstelle der Daten auf HSYNC angewendet werden, um das Problem mit leeren Daten zu beseitigen. Machen Sie einen 13-Bit-Zähler mit der 4-fachen Pixelfrequenz. Verwenden Sie diesen Zähler, um zu zählen, wie lange ein HSYNC auf ein Viertelpixel genau ist. Während jeder Abtastzeile wird der vorherige Zählwert verwendet, um den aktuellen Zählwert in einen Pixel-Offset umzuwandeln, der zum Abtasten und Speichern der Pixeldaten verwendet werden kann. Die Logik zum Bestimmen der Pixelposition aus den beiden Zählwerten ist nur eine Art Additions-/Subtraktionslogik. Es wird etwas schwieriger, das Timing einzuhalten, da wir jetzt größere Zähler bei hoher Frequenz haben würden.
Das könnte sich auf etwas eingrenzen: Ich denke, was Sie sagen, ist, eine Uhr mit dem 4-fachen der ungefähren Punktuhr laufen zu lassen und dann die gemessene Anzahl der Uhren zwischen den vorherigen Synchronisierungen im Vergleich zur erwarteten zu verwenden, um einen Fehleranteil zu ermitteln, der zum Hinzufügen führt / Ab und zu eine Viertelstunde fallen lassen. Glücklicherweise ist die Punktuhr des OP im Vergleich zu FPGA-Funktionen ziemlich langsam, sie können wahrscheinlich 8-10x erreichen.
@ChrisStratton Ich hatte ein bisschen darüber nachgedacht. Es scheint auch eine praktikable Option zu sein. Ich weiß, dass einige PLLs das dynamische Anstoßen der Phase unterstützen. Man würde im Grunde nur die PLL-Multiplikations- / Divisionszahlen finden, die einem Vielfachen von HSYNC am nächsten kommen, und dann die Oversampling-Zählerlogik (wie oben) verwenden, um die Phase zu verschieben. Das könnte einige Vorteile haben, da die anderen Teile des Designs einfacher werden, wenn man einen echten Pixeltakt hat, mit dem man außerhalb der PLL arbeiten kann.

Es wäre sinnvoll, ein wenig darüber nachzudenken, wie eine Videokarte eigentlich ihre Ausgangssignale erzeugt.

Siehe zum Beispiel eine XFree86-Modeline. Hier ist eines für 1024 x 768 @ 60 Hz (ohne Zeilensprung) von einem Online-Generator-Tool , die Details sind implementierungsspezifisch, aber die Idee gilt im Wesentlichen für alle Computer und Videomodi.

Dot Clock Frequency:     60.80 MHz 
Modeline "1024x768" 60.80  1024 1056 1128 1272   768  768  770  796

Sie haben einen Pixeltakt, einen Bereich mit aktivem Video, ein als Start und Ende definiertes Synchronisationssignal und eine Gesamtzahl von Takten in einer Zeilenperiode, in diesem Beispiel 1272. All dies wird in Einheiten von Pixeltakten ausgedrückt, die bedeutet, dass alles auf die Pixeluhr zurückgeht, und zwar auf digital konsistente Weise.

Für einen bestimmten Videomodus auf einem bestimmten Computer sind die Proportionen also stabil, es ist nur die Pixeltaktrate selbst, die mit Temperatur, Alterung usw. leicht driftet.

Wenn Sie also die Modeline-Nummern kennen könnten, könnten Sie Ihren eigenen Pixeltaktoszillator durch die richtige Anzahl von Takten teilen, damit das Synchronisierungssignal übereinstimmt (1272 im obigen Beispiel), und so eine PLL haben, die Ihren Pixeltakt sperrt an die Quellvideokarte. Sie müssen dann nur noch die richtige Anzahl von Pixeln bis zum linken Rand des aktiven Bereichs zählen.

Wie konnten Sie die Modelline-Nummern finden? Nun, Sie persönlich könnten sie wahrscheinlich nachschlagen.

Ich vermute, dass ein moderner pixeliger (LCD usw.) Monitor, der von einer analogen Quelle angesteuert wird, eine Art "Suche" durchführt, wenn Sie die Bildabstimmungstaste drücken. Es ist wahrscheinlich nicht schwer, die horizontale Auflösung zu erraten, und Sie können die Dauer des aktiven Videos messen. Dann können Sie das Verhältnis der gesamten horizontalen Periode zum aktiven Video messen und kennen daraus die ungefähre Gesamtzahl der Pixeltakte in einer Modeline - zB in meinem Beispiel 1272 im Zeitverhältnis zu den 1024. So sperren Sie Ihre PLL bei der Schätzung von 1272 (oder so ungefähr).

Sie versuchen dann verschiedene Zahlen darum herum und führen eine Art Vergleich durch, um zu sehen, wo Ihre abgetasteten Daten "am besten" erscheinen, wobei "am besten" so definiert werden kann, dass in der Nähe der höchste Durchschnitt der Pegeldifferenz von Pixel zu aufeinanderfolgendem Pixel angezeigt wird beiden Seiten des Bildschirms, was anzeigt, dass die Abtastung gut auf die Mitte der Pixelperioden ausgerichtet ist und die Zwischenübergänge zwischen ihnen nicht erfasst, und dies über den Bildschirm so, dass es sowohl in Phase als auch in Frequenz übereinstimmt. Oder vielleicht prüft es nur, ob die aktive Region genau die richtige Anzahl von Pixeltakten breit ist. Aber wenn Sie es sich leisten können, eine Uhr zu erzeugen, die etwa das 3- bis 6-fache der tatsächlichen Pixeluhr ist,

Wahrscheinlich ist diese Analyse etwas, das Sie mit Software auf einem Prozessorkern (intern oder extern zum FPGA) durchführen würden, der Register anstoßen darf, die Ihre Erfassungszustandsmaschine steuern, und Nicht-Echtzeitstatistiken in einem eingefrorenen Zeilenpuffer ausführen. zB wird die Erfassungshardware im Grunde genommen wie ein digitales Oszilloskop behandelt.

FPGA - „sehr nahe“ Uhr vom Signal synchronisieren
AntwortenHierDatenschutz-Bestimmungen1y, 0v