jsvgatest - async clk

[Burkhard K. (buks)]

Stricke gerade Jürgen Schuhmachers SVGAtest 
https://www.mikrocontroller.net/articles/Datei:Jsvgademo_s3e.zip für 
mein Nexys4 um.

Beim Versuch das Design zu simulieren steigt ISIM aufgrund einer 
kombinatorischen Schleife im nachfolgenden Block aus:

---------------------
-- asynch part
---------------------

-- here an asynchronous clock will be created toogling the two colour vectors


-- generate a toogling clock
  p_toggle : process(RESET, toggle)
  begin
    if (RESET = '1') then
    toggle <= "00";
    else
    toggle <= toggle + "01";
    end if;
  end process;
  
  
  p_toggle_cols : process(toggle, color_code, gitter, frame)
  begin
   if (toggle = "00" or toggle = "10") then
     VIDEO_R <= color_code(0);
     VIDEO_G <= color_code(1);
     VIDEO_B <= color_code(2);
   else
     VIDEO_R <= color_code(3);
     VIDEO_G <= color_code(4);
     VIDEO_B <= color_code(5);
   end if;
  
  end process;

Die Synthese stört das nicht, warnt aber vor der kombinatorischen 
Schleife:
  "WARNING:Xst:2170 - Unit VIDEO_OUT : the following signal(s) form a 
combinatorial loop: VIDEO_R, toggle[1]_GND_40_o_add_135_OUT<1>, 
toggle[1]_toggle[1]_OR_48_o, 
Madd_toggle[1]_GND_40_o_add_135_OUT_lut<1>."

Frage - wozu überhaupt eine "asynchrone" Clock an dieser Stelle, welche 
"Periode" wäre zu erwarten (der Code war für ein S3E Board) - und - last 
not least - durch welches simulator- und syntheseverträgliches Konstrukt 
kann ich diesen Block ersetzen?

Gruß,
Burkhard

[J. S. (engineer)]

Dieser Konstrukt ist genau dafür da, asynchron zum Takt, als zufällig 
die Farben zu mischen und dies mit entsprechend hoher Frequenz. Für den 
S3 ist das so abgestimmt, dass es 2-3 mal je Horizontalpixel wechselt. 
Damit entsteht theoretisch ein fein unterteiltes Pixel. Das sieht man 
aber nicht, weil die Bandbreite der manuellen VGA-Wandlung in Verbindung 
mit dem Kabel das nicht her gibt. Man erhält also eine analoge 
Mischfarbe.

Im Prinzip nach ist das ein simples Dithern. Gedacht ist es

a) für solche in der Bitbreite reduzierten Ausgaben
b) für im Takt beschränkte FPGAs.

Beim Nexys 4 könntest du mit einer PLL auch z.B. den 8 fachen Takt 
erzeugen und damit die Farbe wechseln, sofern das überhaupt nötig ist. 
Das board ja ja eine 12 Bit VGA Ausgabe.

Es gibt da auch ein Demoprojekt:
https://reference.digilentinc.com/learn/programmable-logic/tutorials/nexys-4-vga-test-pattern-with-mouse-overlay/start

Warum werden diese Woche eigentlich alle meine alten Designs 
ausgegraben?

[J. S. (engineer)]

Burkhard K. schrieb:

> durch welches simulator- und syntheseverträgliches Konstrukt
> kann ich diesen Block ersetzen?

Für die Simulation wäre eine Verzögerung mit z.B. "After 1 ns" 
einzusetzen. Dann kann der Simulator arbeiten. Für die Synthese braucht 
nichts getan zu werden, der Konstrukt ist so passend. Für die 
Weiterverwendung eines solchen Taktes wäre in der ISE ein buffer 
einzusetzen.

Das Thema haben wir gerade hier:
Beitrag "Re: Simulation digitaler Rauschgenerator"

[Burkhard K. (buks)]

Jürgen S. schrieb:
> Für den
> S3 ist das so abgestimmt, dass es 2-3 mal je Horizontalpixel wechselt.
Danke, das war die Information die mir fehlte.

Jürgen S. schrieb:
> Beim Nexys 4 könntest du mit einer PLL auch z.B. den 8 fachen Takt
> erzeugen und damit die Farbe wechseln, sofern das überhaupt nötig ist.
Ja, ist bekannt dass das Nexys einen 4bit "Video-DAC" hat. Simuliert 
will ich, um zu verstehen was da passiert.

Jürgen S. schrieb:
> Warum werden diese Woche eigentlich alle meine alten Designs
> ausgegraben?
Ich suche gerade nach VGA-Display, nicht speziell nach Designs von J.S. 
Wie das halt so ist, "keine gute Tat bleibt ungesühnt" - Oder hattest Du 
gerade Geburtstag oder ein anderes Jubiläum ;-) ?

Was mich eigentlich interessiert: Wenn ich ich ein "Minimal-Oszilloskop" 
ohne Trigger (also dem "auto"-Mode) mit VGA realisieren will, wie handle 
ich den Mismatch zwischen kontinuierlich einlaufendem Signal und dem 
Frame, in dem während des Synchs ja nichts angezeigt werden kann. 
Entweder werden Teile des Signals nicht angezeigt (Sprünge), oder aber 
das Signal staut sich zurück?

[Michael W. (Gast)]

Burkhard K. schrieb:
> Was mich eigentlich interessiert: Wenn ich ich ein "Minimal-Oszilloskop"
> ohne Trigger (also dem "auto"-Mode) mit VGA realisieren will, wie handle
> ich den Mismatch zwischen kontinuierlich einlaufendem Signal und dem
> Frame

Ganz so wie in jedem normalen Oszilloskop üblich, einen Speicher 
verwenden, Daten samplen und dort ablegen und parallel immer wieder 
darstellen.

https://www.fpga4fun.com/digitalscope.html

[VHDL-Polizei (Gast)]

Burkhard K. schrieb:
> Frage - wozu überhaupt eine "asynchrone" Clock an dieser Stelle, welche
> "Periode" wäre zu erwarten

Das müsste nach meiner Meinung auch mit einem synchronen Takt gehen, der 
die Farben wechselt oder man tauscht sie Bild für Bild aus. Wozu sollte 
das unbedingt mit einem freilaufenden Wechsler arbeiten müssen?

[J. S. (engineer)]

VHDL-Polizei schrieb im Beitrag #5599409:
> Das müsste nach meiner Meinung auch mit einem synchronen Takt gehen, der
> die Farben wechselt oder man tauscht sie Bild für Bild aus.

Nicht bei den limitierten Taktreserven des verwendeten Spartan3. Da 
müsste man ein Pixel sicher 3-4mal togglen um im Horizontaltakt/Pixel 
eine Farbmischung zu erzielen. Bild für Bild geht wiederum nicht, weil 
es flackert.


Burkhard K. schrieb:
> Was mich eigentlich interessiert: Wenn ich ich ein "Minimal-Oszilloskop"
> ohne Trigger (also dem "auto"-Mode) mit VGA realisieren will, wie handle
> ich den Mismatch zwischen kontinuierlich einlaufendem Signal und dem
> Frame, in dem während des Synchs ja nichts angezeigt werden kann.
Man braucht den üblichen Puffer. Im FPGA ein Block-RAM. Diese sind recht 
bequem, weil sie von links mit irgendeinem Takt beschrieben und von 
rechts mit dem Videotakt gelesen werden können. Oszilloskop im FPGA ist 
eigentlich mit das einfachste was man überhaupt bauen kann, solange die 
Daten ins BRAM passen.

Mit etwas Geschick braucht man dabei auch bei vielen Daten nie mehr 
Speicherplätze als Punkte in X. Hier im Bild ist auch so eine App drin: 
Wird entweder in Echtzeit mit dem Audiotakt geschrieben (Darstellung der 
Echtzeitdaten) oder mit dem Videotakt geschrieben (Darstellung der 
unbearbeiteten Waveform aus dem Generator durch simples Auslesen) oder 
es wird mit dem MIDI-Takt geschrieben (Darstellung der Notenechos) oder 
es wird mit 128stel Sekunden geschrieben, wenn eine Hüllkurve 
dargestellt werden soll.