mikrocontroller.net

Forum: FPGA, VHDL & Co. VGA Bild Interlaced


Autor: Martin S. (maklin)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe mit einem Spartan 3E eine VGA-Monitporansteuerung gebastelt. Es 
funktioniert so weit auch, allerdings kommt es zu Interlacing-Effekten 
(siehe Bild im Anhang). Hat jemand eine Idee, welche Modifikation am 
VGA-Signal das Problem beheben würde?

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> allerdings kommt es zu Interlacing-Effekten (siehe Bild im Anhang).
Wo ist da das fehlerhafte Interlacing zu sehen?
Bzw: wie sollte das Bild denn richtig aussehen?

> welche Modifikation am VGA-Signal das Problem beheben würde?
Kann man erst sagen, wenn man weiß was falsch ist...

Autor: Martin S. (maklin)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ok, das hätte ich noch dazuschreiben können:
Es handelt sich um ein normales Quadrat. Es ist mit Paint nachgemalt, 
wie es am Monitor aussieht, wobei die Ein-/Ausbuchtungen stochastisch 
sind (also wechseln und nicht fest diese Form haben müssen) und nur am 
rechten und linken Rand vorkommen.
Und die Farbe ist in echt nicht rot, sondern weiß, aber das ist ja 
egal...(Der Fehler ist Farbunabhängig).

Ich habe den Code angehängt. Im Code kommt zwar eine Bewegung des 
Quadrates auf dem Monitorschirm vor, diese ist jedoch nicht Schuld an 
diesem Phänomen. Es tritt auch bei stehendem Quadrat auf.

Verzeiht mir bitte für die zu wenigen Kommentare im Code.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>     if CLK25MHZ'event and CLK25MHZ='1' and CLK25MHZ'last_value='0'
Dafür gibt es die Funktion rising_edge()...
  CLK25MHZ_p: process(CLK)
  begin
    if CLK'event and CLK='1' and CLK'last_value='0'
      then CLK25MHZ<= not CLK25MHZ;
      else null;
    end if;
  end process CLK25MHZ_p;
:
    if CLK25MHZ'event and CLK25MHZ='1' and CLK25MHZ'last_value='0'
So werden keine Takte geteilt/erzeugt!

Hast du ein Constraint auf den 50MHz-Takt gesetzt?

Autor: Martin S. (maklin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da ich eher Anfänger in VHDL bin, habe ich mich natürlich bei einigen 
Sachen von anderen Projekten inspirieren lassen. Dort habe ich die 
Taktteiler-Variante gesehen. Sollte ich es sonst mit einer if-Abfrage 
gestalten? Die "wait until rising_edge()"-Version führt zu großem 
Ressourcenverbrauch bezüglich Slices und LUTs, weshalb ich die "if 
CLK'event and CLK='1' and CLK'last_value='0'"-Stratgie verwende.

>Hast du ein Constraint auf den 50MHz-Takt gesetzt?

Was bedeutet das für mich? Der 50MHZ-Takt ist ja doch ein Eingang (CLK), 
dort kann ich doch nichts vorgeben.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Die "wait until rising_edge()"-Version führt zu großem
> Ressourcenverbrauch bezüglich Slices und LUTs, weshalb ich die "if
> CLK'event and CLK='1' and CLK'last_value='0'"-Stratgie verwende.
Kannst du diese Behauptung beweisen?
Woher kommt diese Information?
Kannst du diese Behauptung an deinem Design begründen?
Sieh dir das mal an:
http://www.lothar-miller.de/s9y/archives/16-Takt-i...

Davon abgesehen...
Ich meinte damit:
     if rising_edge(CLK) then ...
statt
     if CLK'event and CLK='1' and CLK'last_value='0' then ...
Denn: was ist besser lesbar?
(Die Funktion rising_edge() macht genau das, was du lang und breit 
ausgeschrieben hast)

> von anderen Projekten inspirieren lassen. Dort habe ich die
> Taktteiler-Variante gesehen.
Ja, was man nicht alles so sieht. Da klatscht jeder Anfänger sein erstes 
Design ins Internet, und Jahre später geistern die immer noch rum... :-/
Wenn Taktteiler so gemacht werden, dann hast du evtl. ein ungünstiges 
lokales Routing auf dem Takt. Das kann alles mögliche mit sich 
bringen...

> Sollte ich es sonst mit einer if-Abfrage gestalten?
Du solltest nur 1 Takt verwenden (deinen 50MHz CLK) und mit 
Clock-Enables arbeiten...

>>Hast du ein Constraint auf den 50MHz-Takt gesetzt?
> Was bedeutet das für mich? Der 50MHZ-Takt ist ja doch ein Eingang (CLK),
> dort kann ich doch nichts vorgeben.
Dann mach dich mal zum Thema Timing-Constraints (insbesondere dem 
Period-Constraint) schlau. Wenn du den Tools überhaupt keine Vorgabe 
zur gewünschten Taktfrequenz gibst, dann heißt das im Umkehrschluss, 
dass du auch mit 16MHz zufrieden wärst/bist...

Autor: Random ... (thorstendb) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vielleicht noch mal register an die ausgänge setzen, dass auch alles im 
gleichen takt rausgeht?

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Random ... schrieb:
> vielleicht noch mal register an die ausgänge setzen
> dass auch alles im gleichen takt rausgeht?
Das Design ist schon komplett synchron, da wird nichts kombinatorisch an 
die Ausgänge gegeben...

Ich würde jetzt erst mal ein 25MHz-clock-Enable einführen:
  signal CE25MHZ: STD_LOGIC:='0';

  :

  process(CLK) begin
    if rising_edge(CLK) then 
      CE25MHZ<= not CE25MHZ;
    end if;
  end process;
  
  :
    
  process(CLK) 
  begin
    if rising_edge(CLK) then 
      if CE25MHZ='1' then 
        -- Zaehler
        if VGA_Zaehler_HS<799 then
           :

  process begin
    wait until rising_edge(CLK);
    if CE25MHZ='1' then
      if VGA_Zaehler_VS < 2
        :


Autor: Martin S. (maklin)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank schonmal für die vielen Informationen!

> > Die "wait until rising_edge()"-Version führt zu großem
> > Ressourcenverbrauch bezüglich Slices und LUTs, weshalb ich die "if
> > CLK'event and CLK='1' and CLK'last_value='0'"-Stratgie verwende.
> Kannst du diese Behauptung beweisen?
> Woher kommt diese Information?
> Kannst du diese Behauptung an deinem Design begründen?

Nun, ich weiß nicht mehr wirklich, wo ich es aufgegabelt habe. Ich 
meine, dass sich irgendwann mal in einem anderen Testprojekt eine enorme 
Änderung der Ressourcen durch die Änderung von "wait until..." auf "if
> > CLK'event and CLK='1' and CLK'last_value='0'" ergeben hat und das als 
Bestätigung der Aussage angesehen. Da ich allerdings nicht mehr sicher sagen kann, 
ob ich auch andere Änderungen parallel gemacht habe, und ein Test mit dem 
aktuellem Projekt gezeigt hat, dass man bei allen Varianten immer den gleichen 
Verbrauch hat, möchte ich die Aussage hiermit zurücknehmen.

Ich habe nun das Projekt gemäß der Ideen oben umgebaut (und danach noch 
etwas umgestaltet, um die Übersichtlichkeit zu erhöhen) und ein 
Constraint für das CLK-Signal hinzugefügt ("TIMESPEC TS_CLK = PERIOD 
"CLK" 50 MHz HIGH 50%;" hat ein normaler Quarz eigentlich 50% 
High-Periode? Eigentlich schon, oder?). Allerdings habe ich das 
eigentliche Problem immer noch, ich fürchte, dass es mehr ein VGA statt 
ein FPGA-Phönomen ist, welches sich vielleicht irgendwie mit einem 
anderen Timingverhalten ausschalten lässt?

Es sei noch dazugesagt, dass es sich um ein TFT-Monitor handelt, an dem 
ich es teste. Allerdings kann er ohne Probleme das Bildsignal 640x480 
mit 60 HZ anzeigen.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> hat ein normaler Quarz eigentlich 50%
> High-Periode? Eigentlich schon, oder?)
Üblicherweise schon.

> dass es mehr ein VGA statt ein FPGA-Phönomen ist,
Hast du dein Timing mal mit einem Oszi kontrolliert?
Reichen die Pegel aus?

Autor: Martin S. (maklin)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Nun, hier sind die Messungen. Eigentlich sieht es doch recht ähnlich aus 
(echter Monitor und eigenes Projekt im Vergleich). Oder wird beim echten 
VGA-Monitor über einen der auf der Basys2-Platine auf GND gelegten 
Verbindungen eine weitere Information übertragen?

Bei den ersten beiden Bildern muss man übrigens die unterschiedliche 
Zeitbasis und die vertauschten Farben beachten.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Eigentlich sieht es doch recht ähnlich aus
> (echter Monitor und eigenes Projekt im Vergleich).
Ja. Das sieht eigentlich soweit gut aus...

> Oder wird beim echten
> VGA-Monitor über einen der auf der Basys2-Platine auf GND gelegten
> Verbindungen eine weitere Information übertragen?
Sieh dir mal das Grün-Signal des Referenz-Monitorausgangs zusammen mit 
den Sync-Signalen an. Ältere Monitore verwenden u.U. Sync-On-Green... 
:-/

Autor: Martin S. (maklin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja ein älterer Monitor ist es nicht wirklich, sondern eher genau das 
Gegenteil. Ich fürchte sogar, dass da das Problem liegt...

Über das Forum dieses Projektes:
http://avga.prometheus4.com/index.php

bin ich zu diesen beiden nützlichen Quellen gekommen, die ich mir mal 
morgen in Ruhe ansehen werde:
http://www.maxim-ic.com/app-notes/index.mvp/id/734
http://www.maxim-ic.com/app-notes/index.mvp/id/1184

Vielleicht finde ich dort die Lösung.

Autor: Martin S. (maklin)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Für Interessenten möchte ich folgendes noch erwähnen:
- Ich habe auf dieser Seite: 
http://www.derepas.com/fabrice/hard/#squares einen Code gefunden, der 
ebenfalls auf den Monitor schreiben kann. Auch bei diesem Code war auf 
dem Monitor dieses Krisseln deutlich. Eine Änderung der Back-Porch-Werte 
hat auch so recht nichts gebracht.
- Laut http://www.epanorama.net/faq/vga2rgb/calc.html muss man bei 
640x480, 60HZ einen Takt von 25,17MHZ verwenden. Jedoch kann man 
800x600, 72HZ direkt mit 50MHZ betreiben. Eine Änderung des 
Ursprungscodes hat zwar letzendlich funktioniert, jedoch ebenfalls mit 
dem Krissel, zum Teil sogar mehr Pixel weit als im 640x480 Code.

=> Ich schließe darauf, das das Problem vielleicht gar nicht im Code 
selbst liegt, sondern möglicherweise die Hardware etwas damit zu tun 
haben könnte.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Ich schließe darauf, das das Problem vielleicht gar nicht im Code
> selbst liegt, sondern möglicherweise die Hardware etwas damit zu tun
> haben könnte.
Was hast Du denn für einen Monitor? Bei TFTs hilft es oft die Auto bzw. 
Sync-Funktion zu aktivieren.

Duke

Autor: Martin S. (maklin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe es sowohl mit einem TFT als auch mit einem älteren 
Röhren-Monitor ausprobiert. Das mit dem Snyc könnte ich mal bei 
Gelegenheit testen.

Autor: Dimi S. (ilovespeccy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> - Laut http://www.epanorama.net/faq/vga2rgb/calc.html muss man bei
>
> 640x480, 60HZ einen Takt von 25,17MHZ verwenden.

Hallo,

640x480@60Hz läuft perfekt mit genau 25.000MHz.
Ich habe diese Auflösung schon mehrmals verwendet und
es gab noch nie Probleme mit Darstellung.
Egal ob auf CRT/TFT Monitor oder auf Plasma/LCD Fernseher.

MfG aus Westerwald

Autor: Duke Scarring (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Ich schließe darauf, das das Problem vielleicht gar nicht im Code
> selbst liegt, sondern möglicherweise die Hardware etwas damit zu tun
> haben könnte.

Hast Du eine Testbench? Ansonsten nimm mal die aus dem Anhang und schau 
nach, ob die timings stimmen. Außerdem könntest Du nochmal prüfen ob 
die Polarität von HSYNC und VSYNC richtig ist.

Duke

P.S.: Es ist übersichtlicher, wenn die Datei so heißt, wie die entity 
bzw. das package.

Autor: Martin S. (maklin)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
danke für die Hilfe. Aber ich verstehe nicht ganz, was mir die Testbench 
bringt. Ich habe bereits den vhdl-Code in ModelSim simuliert, indem ich 
das clock-Signal über die after-Befehle generiert habe (so wie in der 
Testbench). Warum sollte man, wie es in der Testbench der Fall ist, 
sämtliche Signale quasie neu benennen und mit den "alten" über die 
Port-Map verknüpfen?
Es sei nebenbei gesagt, dass mir das Simulationsergebniss recht 
schlüssig aussah. Ich habe das Ergebnis in den Anhang geladen.

Autor: Duke Scarring (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Warum sollte man, wie es in der Testbench der Fall ist,
> sämtliche Signale quasie neu benennen und mit den "alten" über die
> Port-Map verknüpfen?
Damit klar ist, welches Signal in der Testbench definiert ist. Damit 
kann man sie schön von internen Signalen unterscheiden.
Außerdem baue ich mir gern ein paar Signalchecker in die Testbench ein.

> Es sei nebenbei gesagt, dass mir das Simulationsergebniss recht
> schlüssig aussah.
Schlüssig aussehen reicht dem Display vermutlich nicht.
Hast Du die Zeiten im Simulator mal nachgemessen und verglichen [1]?

Deine Sync-Timings sehen ganz gut aus:
# ** Note: :pong_480x640_tb:  hsync rate: 31250 Hz
# ** Note: :pong_480x640_tb:  hsync pulse width: 3840 ns
# ** Note: :pong_480x640_tb:  vsync rate: 59 Hz
# ** Note: :pong_480x640_tb:  vsync pulse width: 64000 ns

Duke

[1] http://tinyvga.com/vga-timing/640x480@60Hz

Autor: joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

@Martin S.

Welche Eingänge / Ausgänge konfigurierts Du in der UFC?

Autor: Martin S. (maklin)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Die Frage ist schnell beantwortet, siehe Anhang, dort habe ich die ucf 
eingefügt.

Autor: joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke,

hat mich mal eben interessiert, da ich das spartan-3e entwicklungsboard 
habe,
und der vga port auf diesem board ja "nur" fünf verbundene pins hat.

grüsse

Autor: Martin S. (maklin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falls jemand beim Suchen auf diesen Thread stößt: Das Problem ist 
behoben.

Ich hatte das Board ohne externen Quarz betrieben. Der interne hatte 
wohl eine so schlechte Qualität, dass das Bild einfach grausig aussah. 
Mit einem externen Quarz läuft es super!

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Ich hatte das Board ohne externen Quarz betrieben. Der interne hatte
> wohl eine so schlechte Qualität, dass das Bild einfach grausig aussah.
Das würde mir zu denken geben...  :-/

Was ist "der interne Quarz"? Was kann an diesem Quarz so schlecht sein, 
dass dein Bild nicht gut aussieht? Das was du da hattest sieht eher nach 
einem "klitzekleinen" Timingproblem aus. Durch die Verwendung eines 
anderen Takteingangs und das dadurch nötige geänderte Routing kann es 
dann schon mal passieren, dass das eine Design scheinbar stabil und das 
Andere gar nicht läuft...

Autor: Martin S. (maklin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei näherer Betrachtung des Schaltplans fällt auf, dass der Taktgeber 
kein Quarz (-oszillator) ist, sondern der IC LTC6905, welcher 
wahrscheinlich nicht so genau ist wie ein Quarz.
Dass der Fehler am Routing liegt wäre aber durchaus auch denkbar.

Autor: Terry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn das Ding über eine DSM läuft, dann spielt das bei 25Mhz gar keine 
Rolle! Eher schon ist es so, dass da was von den Teilerverhältnissen 
nicht gepasst hat.

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> RED<="111";
> GRN<="111";
> BLUE<="11";

Warum werden den Farben unterschiedliche Bitbreiten zugeordnet?

Autor: Martin S. (maklin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist so hardwareseitig auf dem Board vorgegeben. Vielleicht haben die 
Entwickler sich überlegt, dass man in blau nicht so viele Unterschiede 
erkennen kann...
Siehe http://www.digilentinc.com/Data/Products/BASYS2/Ba...
Seite 1, unten links.

Autor: B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die hatten wohl nur 8 Bit zur Verfügung.

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.