Hallo,
ich habe ein Problem an meinem Hobby Projekt hier. Leider mache ich VHDL
nicht professionell, setzt deswegen bitte kein allzugroßes Verständnis
voraus und basht mich nicht wegen Unwissenheit. :-)
Ich konvertiere das LCD Signal eines Gameboys und gebe es per
VGA/XGA/whatever aus. Das VGA Signal funktioniert gut und ist sehr
sauber.
Nun muss ich ja das Gameboy Signal "capturen" und konvertieren. Die GB
CLK hat 4MHz, synchronisiert werden die Daten des GB auf fallende
Flanke. Bei steigender Flanke von VSYNC des Gb (dauert eine ganze Zeile
lang) oder bei steigender Flanke von HSYNC des GB (kommt mit einem aus
der Reihen tanzenden Clock pulse und dauert bis zu ersten "richtigen"
Pixelflanke) muss auch nochmal synchronisiert werden.
Mein angehängtes VHDL funktioniert - irgendwie. Es sammelt immer einen
ganzen Frame und schreibt ihn abwechselnd an eine von zwei Memory
Locations (Block Ram), wo dann der Ausgabe Prozess liest.
Leider zittert die Ausgabe manchmal. Das Bild ist im Prinzip benutzbar
aber es zuckt halt rum und einzelne Zeilen ruckeln manchmal merklich von
links nach rechts.
Ich vermute, dass ich die HSYNC Synchronisierung falsch mache und
deswegen bitte ich jemand, der mit so etwas mehr Erfahrung hat, mal
prinzipiell über den Code zu schauen und mir zu sagen, wie man so etwas
richtig macht.
Achja - es handelt sich um eine Spartan 6 und ISE sagt, dass es die
Timingconstraints nicht erfüllen kann. Das verwundert mich. Ich habe
einen clockMuliplier der das alles auf 130MHz laufen lässt.
ladida schrieb:>> Achja - es handelt sich um eine Spartan 6 und ISE sagt, dass es die> Timingconstraints nicht erfüllen kann. Das verwundert mich. Ich habe> einen clockMuliplier der das alles auf 130MHz laufen lässt.
Da gibt es sicher einen ausführlicheren Report, z.B. welche Signale
betroffen sind.
Ich wette deine Probleme hängen mit der shared variable flip_buffer
zusammen, die aus 2 verschieden ASYNCHRONEN Clock Domains gesetzt wird.
Danke für die Hilfe, aber der FLIP Buffer ist es nicht, dass Bild zuckt
genauso (kaum ein Unterschied, ist eher schlechter), ohne den Buffer.
Ich vermute der HSYNC ist der Übeltäter. Dieser line_counter muss die
Pixel pro Reihe zählen, sonst ruckelt das Bild ganz deutlich und
permanent. Das sollte ja nicht nötig sein, wenn man auf HSYNC
synchronisiert. Es dürften ja keine Clock Flanken mehr kommen wenn die
Reihe mal geschrieben ist.
Alle meine Versuche das ohne den line_counter (ist ja eigentlich der
pixel pro line counter) zu machen ergaben sehr schlechte Resultate, als
ob der Monitor an Epilepsie leidern würde.
Vielleicht liegt's auch am Aufbau auf dem Breadboard? Kann da die
Signalqualität so merklich abnehmen?
ladida schrieb:> Ich habe einen clockMuliplier der das alles auf 130MHz laufen lässt.
Fast alles... : if falling_edge(gb_clk) then
Und das hier ist auch spannend:
Geteilt durch 7? Das gibt eine Monsterlogik, da wundert mich, dass
> ISE sagt, dass es die Timingconstraints nicht erfüllen kann.
Dir ist klar, wie aufwändig dieser kombinatorische Teiler ist?
Lies mal den Beitrag "Rechnen mit unsigned vs. signed und einer division"
Mit Lerneffekt: mach mal einen kleinen Dreizeiler mit Division und sieh
dir den RTL-Schaltplan an.
Abhilfe:
Ich würde den gb_clk überabtasten und als einfaches Eingangssignal
betrachten. Und ddie Divisionen müssen raus! Das geht mit einem Zähler
garantiert einfacher.
Also das mit dem Überabtasten mit 130MHz habe ich erfolglos versucht,
leider. Das ging leider gar nicht und wieso weiss ich nicht :-(
Habe dabei so eine Logik wie beim VSYNC verwendet, also "manuelle"
Flankenerkennung.
Ich werde das aber nochmal probieren und sonst einen Counter für die
Ausgabe verwenden. Danke für die Hinweise.
ladida schrieb:> Also das mit dem Überabtasten mit 130MHz habe ich erfolglos versucht,> leider. Das ging leider gar nicht und wieso weiss ich nicht :-(>> Habe dabei so eine Logik wie beim VSYNC verwendet, also "manuelle"> Flankenerkennung.
Das ist ok, aber hast du auch eine Syncstufe davor?
Eine 4 MHz Clock mir 133 MHz abzutasten ist trivial wenn man es rictig
macht.
Grundlagen zum einsynchroniseren von asynchronen Signalen findest du
hier:
http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren
Wow, danke!
Ich habe jetzt die Flankenerkennung laut Lothar Miller eingebaut und das
Abtasten geht jetzt problemlos!
Frage mich ja nur, was ich da vorher falsch gemacht habe. Ganz verstehe
ich es noch nicht, aber ich werde das Dokument nochmal aufmerksam lesen.
Danke dafür! Super!
Danke auch dir, Lothar.
Deine Website ist sehr hilfreich, da kann man wirklich viel lernen.
Eine letzte Frage hätte ich noch: Ich glaube, dass meine
Speicherzugriffe noch suboptimal sind.
Wir synchronisiere ich die Zugriffe am besten mit dem Rest der Logik?
Soll ich hier nochmal eine zweite Clock erzeugen, die höher getaktet ist
und immer die korrekten Addressen anlegt?
Ich habe nämlich das Gefühl, dass das Signal für RGB manchmal nicht
schnell genug anliegt.
Bei Full HD habe ich auch ganz komische Geistereffekte. Gelbe Pixel auf
schwarzem Grund ziehen da noch bis zu 5 Pixel lang weiße Schlieren nach.
Ich frage mich ernsthaft, ob da meine RGB Ausgabe schnell genug schaltet
und die Flanken schnell genug kommen.
Der Super Mario z.B. wird (nur in seinem Umrissen), leicht transparent
und weiss in FullHD 10 Pixel weiter nochmal gerendet.
ladida schrieb:> Bei Full HD habe ich auch ganz komische Geistereffekte. Gelbe Pixel auf> schwarzem Grund ziehen da noch bis zu 5 Pixel lang weiße Schlieren nach.
Miss doch mal mit einem einfachen statischen Testbild die
Signalqualität...
Hallo,
hier ist der aktuelle Stand. Ich habe diese Double Buffering entfernt.
Die multiplied_clk ist auf 193.750 MHz. Diese Artefakte fallen in
niedrigen Auflösungen nicht auf, also dort ist das "Ghosting" auch
vorhanden, nur kaum sichtbar.
Ich habe mal noch den VgaOut mit angehängt.
Ich mache mal ein Foto, wenn der Akku für meine Kamera wieder aufgeladen
ist.
Wie sind die VGA Ausgänge beschaltet?
Eine Pixel Clock von 193 MHz ist sehr hoch, da werden einfache
Widerstandsnetzwerke u.U. schon problematisch.
Und ohne Widerstandsnetzwerk übersteuerst du den VGA Eingang des
Monitors.
> Vielleicht liegt's auch am Aufbau auf dem Breadboard? Kann da die> Signalqualität so merklich abnehmen?
und
> Eine Pixel Clock von 193 MHz ist sehr hoch, da werden einfache> Widerstandsnetzwerke u.U. schon problematisch.
Nen Video-DAC und ne Geätzte Leiterkarte wäre schon nicht schlecht. So
ein Ghosting hatte ich auch mal mit nem billig VGA Kabel.
uwe schrieb:> So ein Ghosting hatte ich auch mal mit nem billig VGA Kabel.
Solche Reflektionen kommen gern von falsch angepassten und nicht
terminierten Signalleitungen...
logic.png
(170 KB)
