Alle Monate wieder setze ich mich in freien Tagen hin und beschäftige mich mit der fpga Welt. Klappt schon deutlich besser, aber immer noch mit Fragezeichen und ohne Gurt. Ich will zu meiner jetzigen Übung nicht allzu viele Fragen auf einmal stellen und mit einer anfangen. Es geht um ein vga Signal. Das muss langsam mal drin sein, habe ich mir gedacht und es funktioniert auch dahingehend, daß der Monitor was anzeigt aber eben nicht dahingehend, daß ich fraglos glücklich wäre. Ich baue auf einem Nexys2 Board von Digilent auf. Wer es nicht kennt: Spartan3e und ein 50 MHz Oszillator. Daraus habe ich per dcm 80 MHz gemacht, denn die kann ich für den benötigten Pixeltakt von 40 MHz komfortabel teilen und ich habe mal einen höheren Takt erzeugt. Benötigen tue ich 80 MHz derzeit nicht, könnte aber ja auch mal sein. Frage 1: Bei einer Synthese wird mir ja von der ise eine bestimmte maximale Frequenz genannt. Bezieht sich das auf den physikalischen Eingangstakt vor dcm (weiß ise also zu dem Zeitpunkt, daß eine dcm vorliegt) oder ist das der maximale Takt nach dcm? Nur nach dem Timing wurden da so 119 MHz genannt. Da kam es mir schon komisch vor, denn man liest immer von 200 MHz und mehr. Ich habe jetzt ja Pong in Angriff, also vergleiche ich die Strahlkoordinaten mit dem Ball und gebe Sprite-mäßig Hintergrund oder Ball aus. Wenn ich mal ein Ram, Framebuffer oder irgendwelche wirklichen Berechnungen in Angriff nehme wo soll das dann hinführen. Ein Ram mit 67 MHz clk scheint mir mehr als mau zu sein. Das gesamte Design, also wirklich ja nix großartiges, ist schon auf 67 MHz rausgekommen. Komischerweise macht der Ball abe rkeine Zicken und die dcm spuckt ja 80 MHz aus. Das verwirrt mich grad total. Da wüsste ich gerne, ob ich meine Denkweise grundsätzlich falsch angesetzt habe, WAS wirklich die Zeit schluckt und was für Tips ich in die Zukunft mitnehmen kann. Allgemeine andere Verbesserungsvorschläge sind mir natürlich auch willkommen. Wirklich zufrieden bin ich mit dem Code nicht.
Ach ja: zweite Frage. Ich habe das Reflektieren des Balls ja jetzt durch Zustände gemacht. Zuerst hatte ich als vx_s ein integer range -5 to 5 und habe immer vx auf die Position addiert, sowie ggf. vx <= -vx gemacht. Handelt man sich bei so einer Vorgehensweise früher oder später Probleme ein verglichen mit so kleinen state-machines oder ist das eher empfehlenswert? schönen Gruß
Clemens M. schrieb: > Bezieht sich das auf den physikalischen Eingangstakt vor dcm Ja. > wo soll das dann hinführen. Wirf mal die statische Timinganalyse an und such den kritischen Pfad. Ich vermute, der ist irgendwo da:
1 | if ( to_integer(unsigned(x_s)) >= ball_x_s and to_integer(unsigned(x_s)) < ball_x_s+20 and to_integer(unsigned(y_s)) >= ball_y_s and to_integer(unsigned(y_s)) < ball_y_s+20) then |
> wo soll das dann hinführen.
Nur als Tipp: du kannst die Sachen ganz relaxt vorher berechnen, denn
der Ball taucht ja nicht unvermittelt irgendwo auf...
"Nur als Tipp: du kannst die Sachen ganz relaxt vorher berechnen, denn der Ball taucht ja nicht unvermittelt irgendwo auf..." Da verstehe ich glaube ich nicht, was du meinst. Ich hätte da einfach 4 Vergleicher erwartet, was und wie kann ich da vorher machen? Wäre nett, wenn du das noch mal klarstellst. danke P.S. bezüglich dieser Timinganalys muss ich mich erst mal einlesen, wie das geht etc. pp. das wird wohl vor morgen nichts.
Resultat jedes Vergleichers zwischenspeichern, das nennt sich dann Pipelining...
Clemens M. schrieb: > Ich hätte da einfach 4 Vergleicher erwartet, > was und wie kann ich da vorher machen? Du kannst den langsamen Vergleicher für die Zeile (die ist ja recht lang stabil und zudem zu erwarten) da rausnehmen und nur noch ein vorher ausgewertetes Bit in den schnellen Vergleicher reingeben. So wie du es jetzt beschrieben hast, muss der Synthesizer alles mit maximaler Geschwindigkeit auslegen. Probier mal einen Vergleich auf Gleichheit und schalte dann ein Flag aktiv, und setze das ein paar Pixel/Zeilen später wieder inaktiv:
1 | if (anfangs_zeile-1 = akt_zeile) then zeile_passt<=1; end if; |
2 | if (ende_zeile-1 = akt_zeile) then zeile_passt<=0; end if; |
3 | if (anfangs_spalte-1 = akt_spalte) then spalte_passt<=1; end if; |
4 | if (ende_spalte-1 = akt_spalte) then spalte_passt<=0; end if; |
5 | |
6 | if (zeile_passt und spalte_passt) then Ball_anzeigen; |
7 | else Hintergrund_anzeigen; |
8 | end if; |
Damit entkoppelst du die Vergleicher voneinander und nimmst eine Logikebene aus dem Pfad heraus...
Muss ich erst mal sacken lassen. Ok daß sich ein Zeilenvergleich rausnehmen lässt leuchtet mir ein. Du hast die Vergleiche jetzt schon noch im getakteten Prozess? Ich hätte jetzt gedacht, ich muss denn hsync noch hinnehmen, um bei eienr neuen Zeile den Vergleich anzustoßen. Die Vorgehensweise deckt sich mit dem von Peter gesagten? Oder meintest du etwas anderes.
Clemens M. schrieb: > Die Vorgehensweise deckt sich mit dem von Peter gesagten? Richtig, da hatte ich das Fenster vor dem Senden zu lange offen rumliegen. Peter hats viel kompakter gesagt... ;-)
Erst mal vielen Dank an euch. Kann man sozusagen als Mantra abspeichern, daß Überprüfung auf Gleichheit und Flag setzen meiner Intervall Abfrage immer vorzuziehen ist, und große Logikverknüpfungen zu vermeiden sind? Ich muss wirklich sagen, das ist haarig für einen mittelmäßigen Softwerker - aber auch spannend :-)
Das macht man nur, wenn nötig, denn wie gesagt: du musst dieses Flag in einem Register speichern (sonst bringt das alles nichts) und handelst dir so gleich mal einen Takt Latency ein...
Berater schrieb: >> benötigten Pixeltakt von 40 MHz > Was ist denn das für ein komischer Pixeltakt? SVGA. Denn VGA hat 25MHz... http://martin.hinner.info/vga/timing.html
> Clemens M. schrieb: > Was ist denn das für ein komischer Pixeltakt? Ich würde eher zu grösseren Taktraten raten, da man mit 108 / 135 MHz auch die 1280x1024 hinbekommt, was etwas ansehnlicher ist auf grossen TFTs. http://www.mikrocontroller.net/articles/Projekt_VGA_Core_in_VHDL
Jürgen Schuhmacher schrieb: > Ich würde eher zu grösseren Taktraten raten, da man mit 108 / 135 MHz > auch die 1280x1024 hinbekommt, was etwas ansehnlicher ist auf grossen > TFTs. Die größere Bildauflösung bedingt aber auch eine größere Speicherbandbreite. Wenn man es dann noch bunter haben will (8 Bit -> 32 Bit Farbtiefe) kommt da nochmal Faktor 4 dazu. z.B.: 800x600 @ 256 Farben --> 40 MByte/s 1280x1024 @ 16M Farben --> 540 MByte/s Diese Speicherbandbreite muß der Speichercontroller und ein ggf. verwendetes Bussytem liefern können. Duke
Genau das war auch meine Überlegung. Derzeit experimentiere ich ja noch mit, ich nenns mal Echtzeitgenerierung der Bilddaten. Wenn ich später überhaupt ne Chance haben möchte irgendwie einen Framebuffer anzugehen, habe ich mit größerer Auflösung gar keine Chance gesehen ich dachte 800x600 ist ein halbwegs guter Kompromiss zwischen Takt und TFT. Aber falls ein experter Speicher ins Spiel kommt werde ich euch ganz sicher ohnehin um Rat fragen müssen. :-) P.S. Durch meinen Anfängermalus würde ich bei allem, was theoretisch möglich ist einen Geschwindigkeitsfaktor von 2-3 abziehen. :-( Ich hab halt wenig Wissen darum, bin im abflachenden Bereich der Lernfähigkeit und habe begrenzte Zeit. Aber umso mehr freue ich mich über das Forum hier
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.