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.
Angehängte Dateien:
-
logic.png
170 KB
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:
1 | current_address := memory_offset + ((current_row / 7) * 160 + (current_column + 1) / 7) * 2; |
2 | else
|
3 | current_address := ((current_row / 7) * 160 + (current_column + 1) / 7) * 2; |
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.
:
Bearbeitet durch Moderator
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.
P.S. Was ist denn an dem if falling_edge(gb_clk) falsch? Das ist genau noch der Teil, mit dem es am besten funktioniert!
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!
P.S. Habe jetzt auch vsync und hsync auf diese Art einsynchronisert und damit ein absolut stabiles Bild. Vielen vielen Dank!
ladida schrieb: > Ganz verstehe ich es noch nicht Ganz einfach: das Stichwort hinter dem Ganzen seltsamen Verhalten heißt Register-Duplication. Und dann ist dir das da passiert, ohne dass du es wahrgenommen hast: http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html Und zwar so wie im Beitrag "Re: Zeitkritisches Einsynchronisieren asynchroner Signale" beschrieben...
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...
Poste mal den aktuellen Stand damit wir keine Ratschläge erteilen die nicht mehr passen.
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...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.