Forum: FPGA, VHDL & Co. Auf externes (asymmetrisches) Signal synchronisieren?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Peter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Vorgeschichte

Vor kurzem ist mir die Bildröhre in einem alten Steuergerät verreckt. 
Ersatz nicht ohne Weiteres zu bekommen.
Freundlicher Weise hat der Steuerrechner einen externen 
Bildschirmausgang. Leider in einem etwas ungünstigen Format, sodass man 
einen modernen Bildschirm damit nicht so ohne weiteres beglücken kann 
(50Hz vertikal, ~21kHz horizontal, RGB jeweils digital wie es aussieht, 
mit 64ns als kleinsten Puls den ich ausmachen konnte (wohl ~ 1 Pixel))
Da dachte ich mir: die Perfekte Ausrede um sich mal wieder etwas mit 
FPGAs zu beschäftigen. ;-) Kann vom Konzept her ja nicht so schwierig 
sein das Bild einzulesen und an einen Bildschirm auszugeben.
Also gesagt getan, für eins von den niedlichen kleinen Artix 7 Boards 
von Trenz ein Board mit VGA Buchse gebastelt und losgelegt.
Ein paar Stunden später hatte ich den Umstieg von ISE (lang ist's her) 
auf Vivado seelisch überstanden und die erste blinke-Demo laufen.
Einen Tag später lief dann auch mein proof-of-concept:

/Vorgeschichte

Zwei Zustandsautomaten, ein Framebuffer aus BRAMs für 800x600x1bit (bzw 
sogar zwei mittlerweile ^^)
Eingangsseitig alles zwischen den H-Sync Impulsen einlesen, Zeile 
speichern, wiederholen bis V-SYNC...
Ausgangsseitig ein einfacher VGA Controller der das Ganze wieder mit 
brauchbarem Timing ausgibt.
Und tatsache, vom Konzept her war es auch nicht so wild. Aber der Teufel 
steckt wie immer im Detail. ;-)
Und zwar zittern die Pixel um einen Pixel horizontal. (manchmal sogar 
als diagonales Muster erkennbar, aber nicht überall) Ich nehme an das 
liegt daran, dass ich weder die genaue Pixelfrequenz kenne noch die 
Ausgabe und mein Einlesen synchron sind.
(Ausgabe von mit Testmuster vorgeladenem BRAM zeigt kein Flackern)
Erste Idee wäre jetzt, meinen Pixeltakt zum Einlesen irgendwie auf die 
Flanke des H-Sync Signals des Steuerrechners zu synchronisieren. Wenn 
die in einer festen Beziehung zueinander stehen kann man den Rest ja 
ausprobieren bis es passt.
Die Frage ist nur, wie würde man das angehen? Hat der FPGA Boardmittel, 
die ich dafür benutzen kann? Wenn nicht, nach welchen Konzept könnte man 
das erreichen?
Oder ist ein ganz anderer Weg vielversprechender?

Ich freue mich über Ideen!
Danke :-)

Peter

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Viel wichtiger als die Bestimmung der Pulsbreite eines Einzelpulses 
(~64ns) wäre es, ebenso auch breitere Pulse zu vermessen und 
nachzurechnen, ob diese exakten Vielfachen entsprechen. Ggf. lohnt auch 
ein Blick auf die Elektronik des Steuergeräts, um die dort eingebauten 
Quarzoszillatoren zu identifizieren. Wenn es sich wirklich um ein 
uraltes Gerät handelt, dürften da noch keine allzu modernen PLLs verbaut 
sein, die beliebige Takte ineinander "umrechnen".

Weiterhin solltest Du vorzugsweise eine deutliche Überabtastung des 
HSYNC-Signals betreiben und den Pixeltakt daran ausrichten, ggf. mit 
experimenteller Bestimmung eines sinnvollen Versatzes um Bruchteile des 
Pixeltaktes. Um Synthesezeit einzusparen, kann es sinnvoll sein, diesen 
Versatz per DIP-Schalter o.ä. am FPGA von außen einstellbar zu machen.

von Weltbester FPGA-Pongo (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
>Auf externes (asymmetrisches) Signal synchronisieren?
Was ist denn in Deinem Sprachgebrauch ein "asymmetrisches" Signal?

Peter schrieb:
> Erste Idee wäre jetzt, meinen Pixeltakt zum Einlesen irgendwie auf die
> Flanke des H-Sync Signals des Steuerrechners zu synchronisieren.

Das wäre in der Tat eine gute Idee, weil DAS!!!! die ureigenste Idee 
beim frame buffering ist, nämlich vollsynchron zu arbeiten.

Da kannst natürlich deine internen Takte auch auf den Schlafrythmus von 
Sigmar Gabriel, die Mondphasen von Marsmond Europa oder den Busfahrplan 
von Wipperfürt synchronisieren, aber dann zappelt das Bild weiter.

von Peter (Gast)


Bewertung
1 lesenswert
nicht lesenswert
@Andreas
Ahh, gute Idee, danke!
Ich werde mal genauer in die Kiste gucken.
Ein schönes 80er Bauteilgrab, 2x Platinen ~A3 Format, alles THT 
natürlich.
Da wird sich bestimmt was finden.
Und HSYNC überabtasten / Takt verschieben ist auch in absehbarer Zeit 
ausprobiert.

@ Weltbester ... (was bitte ist ein Pongo? :-))
Asymmetrisch im Sinne von on-time >> off-time.
Ich wusste nicht ob das relevant ist, deswegen wollte ich es 
vorsichtshalber erwähnen. ;-)

Danke für die Bestätigung meiner glorreichen Idee!
Sozi-Sigmars Schlafzyklus war der erste, offensichtliche Gedanke.
Immerhin sollte es ja eine besondere Beziehung zwischen den Beiden geben 
- auf der einen Seite der Lenker der Arbeiterpartei, auf der anderen 
Seite das Werkzeug des Facharbeiters.
Könnte er sie nicht auch führen, die Maschine, mit gleicher Konsistenz, 
Konsequenz und Nachhaltigkeit?
Ich habe mich dann letztlich lieber doch für HSYNC entschieden.
Falls du mich in die richtige Richtung stupsen möchtest, tu dir keinen 
Zwang an. ;-)

Peter

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
@Peter (Gast)

>Und zwar zittern die Pixel um einen Pixel horizontal. (manchmal sogar
>als diagonales Muster erkennbar, aber nicht überall) Ich nehme an das
>liegt daran, dass ich weder die genaue Pixelfrequenz kenne noch die
>Ausgabe und mein Einlesen synchron sind.

So ist es. Das klassische Problem bei unsynchronisierter Abtastung, 
genauer, dein Abtasttakt vom FPGA ist nicht phasenstarr zum Pixeltakt 
deiner Quelle.
Gute Digitalmonitore etc. haben eine "echte" PLL, die sich phasenstarr 
auf den H-Sync synchroniesiert und damit einen phasenstarren Pixeltakt 
erzeugt. Dann zittert auch nix mehr.

>Die Frage ist nur, wie würde man das angehen? Hat der FPGA Boardmittel,
>die ich dafür benutzen kann? Wenn nicht, nach welchen Konzept könnte man
>das erreichen?

Hmm, mit viel Firepower könnte man das schaffen, Stichwort volldigitale 
PLL. Darüber hab ich mal ne Diplomarbeit geschrieben ;-)

Man nehme einen tierisch hohen Takt, sagen wir 100-200 MHz und 
synchronisiere sich auf die Flanke von H-Sync. Als Oszillator nimmt man 
einen DCO (digital controlled oscillator), je nach Anforderung einen 
sehr einfach gestrickten (wie im originalen 74HC297) oder etwas cleverer 
auf DDS Basis. Phasenvergleicher, Schleifenfilter, fertig ist die 
volldigitale PLL.
Mit etwas Glück und feststehendem Pixeltakt kommt man auch etwas 
einfacher ans Ziel, letztendlich muss man ja nur die Flanke mit 
möglichst hoher Zeitauflösung synchronisieren und dann mit festem, 
geteiltem Takt, abtasten. Wenn der Takt deutlich über der Pixelfrequenz 
liegt (64ns = 15,625 MHz), kann man mit Subpixel Zeitauflösung die 
Abtastphase festlegen und damit praktisch jitterfrei abtasten. Ich sag 
mal Faktor 4-10 sollte reichen, macht max. 160 MHz, das ist kein Thema 
für ein modernes FPGA.

von Peter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danke für die Antwort!
So ähnlich habe ich mir das vorgestellt, probiere ich aus wenn ich 
wieder wach bin. ;-)
Der MMCM des Artix haben anscheinend ziemlich coole features, vom 
manuellen Verschieben der Phase im Betrieb bis hin zu externem feedback 
im PLL Modus. Hätte ja sein können dass man das damit schon 
abfrühstücken kann und das jeder weiß nur ich nicht. (Und dann im 
stillen Kämmerlein das Rad neu erfinde...in kantig, und unwuchtig, nach 
langer Arbeit ;-))
Ich probiere das erst einmal so und hebe mir das Erkunden des MMCM für 
die nächsten verregneten Sonntage auf. :-)

Peter

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
@Peter (Gast)

>Der MMCM des Artix haben anscheinend ziemlich coole features, vom
>manuellen Verschieben der Phase im Betrieb bis hin zu externem feedback
>im PLL Modus. Hätte ja sein können dass man das damit schon
>abfrühstücken kann und das jeder weiß nur ich nicht.

Nun ja, soweit mir bekannt ist, können die diversen PLLs, DLLs etc. 
nicht aus derartig niedrige Frequenzen wie 15 kHz synchronisieren, da 
geht das Leben eher bei 5 MHz los. Darum muss man das selber stricken.

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> etztendlich muss man ja nur die Flanke mit
> möglichst hoher Zeitauflösung synchronisieren und dann mit festem,
> geteiltem Takt, abtasten.
Das wird man bei einem Takt dieser Grössenordnung nicht einfach genau 
genug hinbekommen. Ich habe für eine andere APP einen selbstanpassenden 
Quarzteiler geschrieben, der in der Lage ist, einen Teiler bis auf ein 
Digital genau anzupassen. Das braucht(e) man, wenn die Frequenz nicht 
genau genug bekannt ist und sich ändern kann. Die exakte Frequenz wird 
im FPGA durch Verschieben der IO-Delays vollzogen, die einen Takt 
dynamisch um z.B. 1/(128+k) einstellen kann. Man bekommt z.B. aus einem 
festen 27.00xxx MHz-Quarz genau die 27.yyyy MHz raus, deren Teilung 
langfristig synchron zu dem echten HSYNCH ist, dessen 27MHz-Quelle man 
nicht direkt sieht. Der Rest geht asynchron auf Takteebene mit FiFos.

Einfacher und für den hiesigen Zweck auch noch ausreichen wäre ein 
Abtasten, das asynchron auf Datenebene liefe, also Zeilenweises 
übernehmen und völlig unsynchronisiertes Ausgeben. Damit ist die Ausgabe 
immer taktstabil, es kommt nur zu Datenbrüchen, wenn die die Zeilen sich 
"sehen". Bei Displayanwendungen ist das aber unerheblich.


Falk B. schrieb:
> Nun ja, soweit mir bekannt ist, können die diversen PLLs, DLLs etc.
> nicht aus derartig niedrige Frequenzen wie 15 kHz synchronisieren,
Von einer so geringen Frequenz ausgehend nach "oben" zu gehen, würde 
auch gewaltigen Jitter produzieren. Besser ist es, eine möglichst hohe 
Frequenz runterzuteilen und "unten" zu synchen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.