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
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?
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"
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?
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
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?
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.
