Forum: FPGA, VHDL & Co. VGA (Framebuffer)


von Julian (Gast)


Lesenswert?

Ich wühle mich etwas in mein VGA Projekt. Für mich ist das ein klasse 
Thema zum lernen, weil ich es an sich immer bunter treiben kann.
Ich habe bis jetzt das Timing gemacht, Testbild generiert und Sprites 
angezeigt. Das war mehr Mühe und Arbeit als ihr alten Hasen jetzt 
vielleicht meint - hängt davon ab, ob ihr euch an die lernkurve erinnern 
könnt ;-)

Jetzt hänge ich in der Luft und weil ich keinen Lehrer oder so habe 
möchte ich euch fragen:
Der nächste Schritt für mich wird sein, einen Framebuffer dazu zu 
nehmen, aus dem die daten angezeigt werden. Da habe ich ein SD-ram. 
(dieses irgendwie sinnvoll ans Laufen zu bringen würde ich auch als 
Meilenstein ansehen, aber der Thread ist erst mal das VGA seitige)

Jetzt kann ich versuchen immer eine ganze Zeile (also die Zeile die als 
nächstes angezeigt werden wird) aus dem Ram in ein FIFO zu lesen, und 
die aktuellen Daten aus einem zweiten Fifo zu holen. Also 2 Fifos bzw 
ein Ping Pong Buffer. Ist das ein praktikabler Weg? Damit könnte ich 
auch daten auslesen während Pixeldaten geschrieben werden. Alternative 
wäre nach meinem Verständnis, dass das Ram so schnell ist dass es in der 
Austastlücke beginnen kann eine neue Zeile zu lesen und dann mit einem 
Fifo hinkommt.
Ist das gedanklich der richtige Weg oder wie sollte ich mich dem 
annähern?

Zweiter und erheblich größeres Problem: Wenn ich nicht nur einen 
statisches Framebuffer anzeigen will, muss ja auch IN den Buffer etwas 
geschrieben werden während er auch gelesen wird. Da hänge ich total in 
der Luft und weiß nciht mal in welcher Richtung ich etwas umsetzten 
wollte, geschweige denn wie.
Angenommen ich lese die Pixeldaten in ein PingPong Fifo aus wie oben 
beschrieben. Dann könnte ich ich der Zeit, die bis Zeilenende bleibt 
etwas in den Buffer rein schreiben. Aber Pixelweise dürfte doch viel zu 
langsam sein und vor allem wenn ich so etwas banales wie eine senkrechte 
Linie zeichnen will, muss ja in JEDER Zeile ein Pixel gesetzt werden. 
Wie soll das verwaltet und mit Bandbreite passieren?

Ich wäre euch super dankbar wenn ihr mir da gedanklich auf die Sprünge 
helfen könnt: wie macht man so was?

schönes Wochenende schon mal!

von Duke Scarring (Gast)


Lesenswert?

Hast Du Dir schon FPGA-Pong angeschaut?
Ich glaube im MiSt-Projekt gab es da ein Tutorial dazu.

SDRAM hält einige Fallstricke bereit. Ich würde noch einen 
Zwischenschritt machen:
Textausgabe mit ASCII-Speicher und Zeichengenerator.
Da bleibt der Speicherbedarf überschaubar und es passt i.d.R alles in 
interne Block-RAMS des FPGAs.
Den ASCII-Speicher kannst Du z.B. statisch füllen, mit einer 
State-Machine oder per UART.

Bei Framebuffer kann man 'unsichtbar' schreiben und lesen, wenn man die 
Pausenzeiten für HSYNC und VSYNC für den Zugriff nutzt.
Wenn man den Framebuffer in externen SDRAM legt, kann man auch auf den 
Refresh verzichten, da normalerweise permanent gelesen wird.

Duke

von honko (Gast)


Lesenswert?

Schau ob dein Ram schnell genug ist und passe daran deinen 
Pixeltakt/Auflösung an. Ein FIFO (einfaches, kein! pingpong)  wird nicht 
viel bringen (paar % vielleicht). Du kannst entweder in deiner 
Abtastlücke Daten in den Framebuffer schieben oder Du hast 2 separate 
Video-RAMs und machst Double Buffering.

von Julian (Gast)


Lesenswert?

erstehe ich eure Antworten so weit richtig, dass ihr aus dem Framebuffer 
an sich ohne Fifo lesen würdet während der Anzeige und Daten in den 
Framebuffer in der Lücke schreibt?

Passiert das schreiben dann i.d.R. per einzel Zugriffen? Ich muss mir 
dann ja die Adressen mit den Daten merken und dann hoffentlich genug 
Pixel in den Lücken per 'random access' schreiben können? So viel 
Bandbreite ergibt sich doch bei einem sdram dann doch gar nicht. Also 
wenn ich mal an die senkrechte Linie aus meinem Post oben denke :-(. Ich 
befürchte der Groschen ist noch nciht gefallen.

Warum würde man denn nicht ein ping pong Fifo machen dann kann man doch 
eigentlich immer auf das Ram zugreifen außer man liest grad in das 
entsprechende fifo.

von Duke Scarring (Gast)


Lesenswert?

Julian schrieb:
> erstehe ich eure Antworten so weit richtig, dass ihr aus dem Framebuffer
> an sich ohne Fifo lesen würdet während der Anzeige und Daten in den
> Framebuffer in der Lücke schreibt?
Ja.

> Passiert das schreiben dann i.d.R. per einzel Zugriffen?
Bei den meisten Systemen schon. Das Bild wird 50 oder 60 mal pro Sekunde 
komplett ausgelesen, aber wesentlich seltener aktualisiert und wenn dann 
nicht zwingend komplett, sondern evtl. nur in Teilen.

Duke

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Julian schrieb:
> erstehe ich eure Antworten so weit richtig, dass ihr aus dem Framebuffer
> an sich ohne Fifo lesen würdet während der Anzeige und Daten in den
> Framebuffer in der Lücke schreibt?

Halte ich fuer unpraktisch, wenn man immer warten muss ob man grad in 
der Austastluecke ist oder nicht, nur weil man "mal ein Raumschiff 
zeichnen will". Bei SDRAM (+Controller) weisste nie so genau, wann da 
die Daten kommen, die du mal ein paar Takte vorher angefordert hast. 
Haengt ja davon ab, ob die Page grad offen ist, ob ein Refresh ansteht 
oder nicht, ...
Also brauchst du, um taktgenau deine Pixeldaten ausm Videointerface zu 
kriegen, einen FIFO zwischen SDRAM und Videoausgang. Immer, wenn in dem 
FIFO Platz fuer soviele Daten ist, wie du mit einem Burst aus dem SDRAM 
lesen kannst, dann machst du (als naechstes am SDRAM-Interface) eine 
Leseoperation aus dem SDRAM ins FIFO. Derweilen kannst du dann die 
Pixeldaten aus der anderen Seite des FIFOs taktgenau ausgeben, mit Sync 
und Gedoens anreichern, etc.

Und immer wenn du nicht gerade aus dem SDRAM einen Burst fuers FIFO 
holen musst, kann dann die CPU, oder irgendwer anders, der da 
Raumschiffe oder Panzer malen will, aufs SDRAM zugreifen. Aber nicht zu 
lange (also z.b. auch immer nur fuer 1 SDRAM Burst), denn der FIFO 
sollte nicht leerlaufen...

Gruss
WK

von FPGAzumSpass (Gast)


Lesenswert?

Ich bin für den Weg mit 2 Zeilen in einem Blockram im FPGA. Das kostet 
nicht allzu viel Speicher im FPGA und ermöglicht dir den SDRAM Burst 
voll auszunutzen.

Soll heißen: wenn du immer eine Zeile komplett liest, dann kannst du das 
mit der maximalen Lesegeschwindigkeit tun und hast auch maximal viel 
Zeit übrig um wieder etwas zu füllen.

Außerdem musst du dann nicht ständig die Page umschalten um wieder ein 
paar neue Pixel zu lesen und bist auch nicht darauf angewiesen immer 
sofort Zugriff aufs SDRAM zu haben zum Auslesen, sondern musst es nur 
irgendwann innerhalb eine Zeile schaffen.

Wenn dir die Pausen für das Schreiben ins SDRAM damit zu groß sind, dann 
kannst du immer noch ein Schreib-FIFO davor hängen das neu zu 
schreibende Pixel annnimmt während gerade eine Zeile ausgelesen wird.

Vertikale oder diagonale Linien sind jedoch wirklich langsamer zu 
schreiben als Horizontale. Hier bleibt aber die Frage ob deine CPU, oder 
was auch immer diese Linien malen will, überhaupt so schnell die 
Farbdaten erzeugen kann.
Typischerweise dürfte die Transferrate ins SDRAM selbst bei wahlfreien 
Zugriff höher liegen als die Erzeugungsrate einer CPU.


Mach dir vorher aber Gedenken wie groß deine Transferrate überhaupt ist 
und welche Aufösung die bei welcher Farbtiefe bedienen willst.

Beispiel: ein mit 16 Bit angebundenes SDRAM das mit 100Mhz betrieben 
wird liefert zwar nicht ganz 200Mbyte pro Sekunde, aber 150Mbyte 
aufwärts kann man mit Bursts gut erreichen.
Bei 640x480 Pixeln bei 60Hz mit 32Bit Auflösung(zum leichteren Handling 
statt krummen 24bit) braucht man dann 73Mbyte pro Sekunde, hat also noch 
die Hälfte der Zeit zum Füllen übrig.

Alle Pixel wirst du dann freilich nicht in jedem Frame neu malen können, 
aber selbst bei komplett wahlfreiem Schreibzugriff bleibt da noch 
einiges übrig.

von Julian (Gast)


Lesenswert?

Ich habe jetzt noch ein Verständnisproblem wenn ich darüber nachdenke, 
in weclhem Format neue Daten in ein Schreibfifo geschrieben werden.
Das würde doch sinnvollerweise in Zieladresse,Farbwert passieren? Ich 
komme etwas ins straucheln, weil der 'Grafikchip' ja auch irgendwie 
feststellen muss, ob die Daten fortlaufend geschrieben werden können, 
oder ob die zerstückelt sind.

Wenn ich mir vorstelle, dass eine Zeile zur Anzeige in einen Zeilenpufer 
gelesen ist (wie jetzt zuletzt angeregt) dann könte ich in der Zeile ja 
ggf. Werte ändern und die dann komplett wieder zurückschreiben. Verstehe 
ich. Aber ich muss die Daten die der Controller oder wer auch immer in 
den Framebuffer schreiben muss ja auch so zur Verfügung haben, dass alle 
Pixel die zu einer Zeile gehören quasi sortiert vorliegen.

Ich hoffe ihr versteht meine Denkblockade.

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Julian schrieb:
> Ich habe jetzt noch ein Verständnisproblem wenn ich darüber
> nachdenke,
> in weclhem Format neue Daten in ein Schreibfifo geschrieben werden.
> Das würde doch sinnvollerweise in Zieladresse,Farbwert passieren?
Naja, vom Farbwert weiss erstmal keiner was, sondern das sind halt 
irgendwelche Daten, aus denen dann das Bild generiert wird. Und so in 
der Art funktioniert ein SDRAM-Controller; dem sagst du an, was du 
machen willst (r/w), wieviel davon (burstlenth) und gibst ihm entweder 
die Daten zum Schreiben oder kriegst die Daten vom Lesen.

> Ich
> komme etwas ins straucheln, weil der 'Grafikchip' ja auch irgendwie
> feststellen muss, ob die Daten fortlaufend geschrieben werden können,
> oder ob die zerstückelt sind.
Das ist hat der Job des 'Grafikchip'. Eine CPU hat an der Stelle gerne 
mal Caches, die es idealerweise schaffen, mehrere Speicheroperationen zu 
einem Burst zusammenzufassen.

> Wenn ich mir vorstelle, dass eine Zeile zur Anzeige in einen Zeilenpufer
> gelesen ist (wie jetzt zuletzt angeregt) dann könte ich in der Zeile ja
> ggf. Werte ändern und die dann komplett wieder zurückschreiben. Verstehe
> ich. Aber ich muss die Daten die der Controller oder wer auch immer in
> den Framebuffer schreiben muss ja auch so zur Verfügung haben, dass alle
> Pixel die zu einer Zeile gehören quasi sortiert vorliegen.
Deshalb ist das keine gute Idee. Du muesstest immer ewig warten, bis 
gerade die Zeile an die Videosignalerzeugung geschickt wird, in der du 
rumfuhrwerken willst. Das ist Kappes.
Wenn du weisst, dass du jetzt einen Panzer an die Koordinaten x,y 
zeichnen willst, dann schreibst du einfach die Panzerpixeldaten an die 
durch x und y berechenbaren Adressen im Speicher. Und kuemmerst dich 
nicht gross drum, welche Zeile aus dem Speicher grad ausgelesen wird und 
in Videosignal verarbeitet wird.
Soll das synchron zur Videoausgabe erfolgen, dann macht man das 
ueblicherweise per Interrupt im V-Blank. Dann weiss jeder, den das 
kratzt, Bescheid, dass jetzt wieder ein neues Bild ausgegeben wird und 
z.b. die Positionen von Panzern, Raketen, Supermarios, etc. neu zu 
zeichnen sind.

Gruss
WK

von Julian (Gast)


Lesenswert?

Ich genieße gerade zwar das Wetter, aber möchte die Gelegenheit nutzen 
euch für die hilfreichen Antworten zu danken.
Ich denke jetzt ist der Punkt gekommen da komme ich theoretisch nicht 
weiter und sollte erst noch mal die Ärmel hoch Krempeln. Kann natürlich 
dauern weil das wie gesagt ja eine ordentliche lern Kurve hat.

Ich würde für mich jetzt bilanzieren:zur Anzeige in ein fifo burst lesen 
wenn Zeit und Platz. Ab einem bestimmten Grad der Entleerung hat das 
Lesen Vorrang. Schreiben passiert zwischen den lese bursts entweder als 
random access für einzelne Pixel oder auch als burst wenn fortlaufende 
Daten anstehen. Wie das Verwaltet wird überdenke ich später dann.

Und erstes zwischenziel der ganz am Anfang empfohlene textmodus wo nur 
Zeichen angezeigt werden können die ich entspannt ohne externes RAM 
angehen werde. Leider leider gibt es ja von altera derzeit überhaupt 
keine Boards am Markt sonst würde ich vielleicht sogar etwas mit 16bit 
angeschlossenem sram suchen. Mich jetzt ja niemand.

von J. S. (engineer) Benutzerseite


Lesenswert?

Eigentlich ist es kein Problem, das timing zu steuern, weil die 
Pixelanforderung ziemlich konstant ist. Man fragt für jedes aktive Pixel 
die Daten mit einem statischen Vorlauf an, der die Latenz des 
DDR-Controllers und refreshs überrückt und Platz für FIFO-Kompression 
hat. Z.B. fragt man man bei 64 Bit Busbreite immer 2 Pixel (30 x 2) Bit 
an und nutzt eine Zeile Vorlauf. Der DDR Controller hat am UI einen 
eigenen FIFO, der die Anfragen sammelt. Das kommt dann frühzeitig zurück 
und gelangt ins Blockram. Der ungenutzte Bereich im Horizontaltiming 
wird überlesen, der im Vertikalbereich einfach nicht angefragt.

Wenn man es nicht schafft oder braucht, zwischen den Zeilen neue 
Informationen einzuschreiben, passiert das eben mit dem burst im 
ungenutzten Bereich des Vertikaltaktes. Sind die Daten zu viel oder das 
Interface zu langsam braucht man eben zwei RAMs / RAM Bereiche.

In einer alten Lösung für overlays habe ich ein Pendel-RAM genutz, in 
das jeweils immer mit minimalem Zeitversatz das Original des parallelen 
Rams oder alternativ die neue Information geschrieben wurde. Um das 
dynamisch halten zu können, gab es ein Block-RAM-Fifo, das sowohl die 
neue Pixelinformation, als auch die Adresse enthielt. Kam der X,Y 
Pointer "vorbei" wurde entschieden, ob die Info aus dem BRAM dazu passt 
oder überlesen werden muss.

Mit der Methode laufen z.B. viele Pixelkorrekturen in Bildprozessoren, 
welche angeben, ob ein Pixel korrigert werden muss und wie, weil es 
deefekt ist. Am Ende braucht man dann "nur" soviel BRAM, wie man Pixel 
ersetzen oder aktualisieren möchte.

Will man hin und her über einen DDR abwickeln, braucht es natürlich 
Bandbreite in der Größenordnung von rund 2.5x dem, was das Video brutto 
hat, also z.B. 148,5MHz x 3 x 8 Bit. Mit einem Artix200 habe ich schon 
297x3x10 Bit gepackt.




Julian schrieb:
> Boards am Markt sonst würde ich vielleicht sogar etwas mit 16bit
> angeschlossenem sram suchen.

von Steffen H. (avrsteffen)


Angehängte Dateien:

Lesenswert?

Welchen FPGA und welchen SD-RAM willst/hast du in Verwendung?

Ich habe letztes Jahr mich auch mal an solch ein Projekt gewagt. Dabei 
hatte ich SD-RAM in drei verschiedenen Datenbusbreiten (8, 16 und 32bit) 
in Verwendung. Das externes Interface zum Displaycontroller war 8bit 
groß um einen AVR zu nutzen.

Ich baute die Ansteuerung/Befehle zum Display Controller ähnlich der des 
OLED-Controllers SSD1306 auf. Halt nur mit einem 8bit RGB565 paralell 
Interface. Ich kann damit Displays bis 800x600 ansteuern.
Der SD-RAM Controller konnte lesend im Full Page Burst Mode benutzt 
werden. Auch Page übergreifend. Somit ist es möglich eine Startadresse 
und die Anzahl zu lesender Datenbytes als Request an den SD-RAM 
Controller zu übergeben und der Controller füllte dann einen der 
Zeilenzwischenspeicher (FiFo) des Displaycontrollers.

Ich hab es so gelöst, das immer eine Zeile im voraus abwechselnd in 
einen der Zeilenzwischenspeicher (A oder B) geladen wurde.
1) Zeile-1 Daten aus SD-RAM holen und in Buffer A speichern
2) Zeile-2 Daten aus SD-RAM holen und in Buffer B speichern
   Zeile-1 Daten aus Buffer A holen und auf Display ausgeben
3) Zeile-3 Daten aus SD-RAM holen und in Buffer A speichern
   Zeile-2 Daten aus Buffer B holen und auf Display ausgeben
...
X) letzte Zeile aus SD-RAM holen und in Buffer A/B speichern
   vorletzte Zeile aus Buffer B/A holen und auf Display ausgeben
Y) letzte Zeile aus Buffer A/B holen und auf Display ausgeben

Je nach SD-RAM Größe kann man da noch eine zweite Page im SD-RAM 
abbilden welche man im Hintergrund beschreiben kann während die erste 
Seite angezeigt wird und vice virsa.

Das beschreiben der Pages im SD-RAM erfolgt ebenfalls über zwei 
FiFo-Buffer da ich ja nur 8bit Daten vom Interface entgegen nehme und 
die Datenbreite pro Pixel ja RGB565 (16bit) ist. Die Displayadresse ist 
sogar 24Bit groß. Diese Daten werden Byteweise (8,16 oder 32bit) in das 
SD-RAM geschrieben, sobald der Bus zum SD-RAM wieder frei ist.

Ich habe hier Beitrag "[Verilog] FPGA SDRAM Tester per UART" auch mal 
einen SDRAM Tester gepostet.

von W.S. (Gast)


Lesenswert?

Julian schrieb:
> Jetzt kann ich versuchen immer eine ganze Zeile (also die Zeile die als
> nächstes angezeigt werden wird) aus dem Ram in ein FIFO zu lesen, und
> die aktuellen Daten aus einem zweiten Fifo zu holen. Also 2 Fifos...

Egal wie du es drehst oder wendest, du hast nur einmal Zeit und mußt 2 
voneinander unabhängige Zugriffe organisieren. Entweder du machst das 
so, daß eine CPU nur in Zeiten zugreifen darf, wo grad keine Videodaten 
zum Display gesendet werden oder du mußt jede Pixelzeit in 2 Stücke 
aufteilen: eines für die CPU, das andere für das Display. Natürlich kann 
man es auch brachial machen, also daß die CPU einfach hineintrampelt und 
der Display-Zugriff währenddessen die Klappe halten muß.

Also: denke dran, daß du mit Fifos, die ja auch erst gefüllt werden 
müssen, hier nix sparst. Du hast die Zeit nur einmal.

W.S.

von Steffen H. (avrsteffen)


Lesenswert?

W.S. schrieb:
> Egal wie du es drehst oder wendest, du hast nur einmal Zeit und mußt 2
> voneinander unabhängige Zugriffe organisieren.

Und genau deswegen brauchst du FiFo. Da das Senden der Pixeldaten ans 
Display zeitgenau passieren muss und man beim Zugriff auf SDRAM nie 
genau weiß wann man da die Daten erhält muss man vorher in ein BlockRAM 
zwischenspeichern.


W.S. schrieb:
> Also: denke dran, daß du mit Fifos, die ja auch erst gefüllt werden
> müssen, hier nix sparst. Du hast die Zeit nur einmal.

Das stimmt so nicht. Siehe oben..

von W.S. (Gast)


Lesenswert?

Steffen H. schrieb:
> Und genau deswegen brauchst du FiFo.

Ach und was spart man damit? Bevor man irgend etwas aus dem Fifo lesen 
kann, muß er zuvor gefüllt werden. Das macht dann eben genau die 
Lesezugriffe aus dem RAM, die man gemeint hat, sparen zu wollen.

Du hast nicht gründlich genug nachgedacht, sondern dich von einem 
Vorurteil leiten lassen, was da sagt: "wenn es schnell gehen soll, dann 
nimmt man einen Fifo". Das ist alles.

W.S.

von Steffen H. (avrsteffen)


Lesenswert?

Jürgen S. schrieb:
> Man fragt für jedes aktive Pixel
> die Daten mit einem statischen Vorlauf an, der die Latenz des
> DDR-Controllers und refreshs überrückt und Platz für FIFO-Kompression
> hat. Z.B. fragt man man bei 64 Bit Busbreite immer 2 Pixel (30 x 2) Bit
> an und nutzt eine Zeile Vorlauf. Der DDR Controller hat am UI einen
> eigenen FIFO, der die Anfragen sammelt. Das kommt dann frühzeitig zurück
> und gelangt ins Blockram. Der ungenutzte Bereich im Horizontaltiming
> wird überlesen, der im Vertikalbereich einfach nicht angefragt.

FPGAzumSpass schrieb:
> Ich bin für den Weg mit 2 Zeilen in einem Blockram im FPGA. Das kostet
> nicht allzu viel Speicher im FPGA und ermöglicht dir den SDRAM Burst
> voll auszunutzen.

Dergute W. schrieb:
> Bei SDRAM (+Controller) weisste nie so genau, wann da
> die Daten kommen, die du mal ein paar Takte vorher angefordert hast.
> Haengt ja davon ab, ob die Page grad offen ist, ob ein Refresh ansteht
> oder nicht, ...
> Also brauchst du, um taktgenau deine Pixeldaten ausm Videointerface zu
> kriegen, einen FIFO zwischen SDRAM und Videoausgang. Immer, wenn in dem
> FIFO Platz fuer soviele Daten ist, wie du mit einem Burst aus dem SDRAM
> lesen kannst, dann machst du (als naechstes am SDRAM-Interface) eine
> Leseoperation aus dem SDRAM ins FIFO. Derweilen kannst du dann die
> Pixeldaten aus der anderen Seite des FIFOs taktgenau ausgeben, mit Sync
> und Gedoens anreichern, etc.

Das sehe aber nicht nur ich anders als du.

W.S. schrieb:
> Du hast nicht gründlich genug nachgedacht, sondern dich von einem
> Vorurteil leiten lassen, was da sagt: "wenn es schnell gehen soll, dann
> nimmt man einen Fifo". Das ist alles.

Ich glaube eher du denkst hier nicht nach. Und ich glaube auch nicht, 
das du je schon einen LCD oder TFT Controller geschrieben hast.

W.S. schrieb:
> Ach und was spart man damit? Bevor man irgend etwas aus dem Fifo lesen
> kann, muß er zuvor gefüllt werden.

Hier geht es um Zeitersparnis beim lesen des SDRAM. Denn durch Burst 
Zugriffe kann man viel effektiver arbeieten als durch Einzelzugriffe. 
Und wenn du Datenmengen von 1280x1048 mit SDRAM schaffen willst, dann 
geht es garnicht anders.

: Bearbeitet durch User
von W.S. (Gast)


Lesenswert?

Steffen H. schrieb:
> Hier geht es um Zeitersparnis beim lesen des SDRAM.

OK, dann erspar dir Zeit nach deinem Gusto, aber zugleich zugreifen 
können eben nicht 2 Einheiten, also bleibt das Problem genau so, wie ich 
das geschrieben habe. Daß es bei SDRAM langsamer bei random Zugriffen 
ist als per Burst, ist hier nicht relevant. Die Zeit kann man nicht 
verdoppeln, also braucht es ein Nacheinander bei den Zugriffen.

W.S.

von Steffen H. (avrsteffen)


Lesenswert?

W.S. schrieb:
> Daß es bei SDRAM langsamer bei random Zugriffen
> ist als per Burst, ist hier nicht relevant. Die Zeit kann man nicht
> verdoppeln, also braucht es ein Nacheinander bei den Zugriffen.

Du widersprichst dich ja selber. Keiner will zugleich zugreifen. Das hat 
hier niemand gesagt/geschrieben. Natürlich kann man nur seriell auf den 
SDRAM zugreifen und genau deswegen musst du Zeit gut machen. Um zum 
Beispiel zwei Zugriffe in der Zeit eines SDRAM Zugriffs per random 
alternating Access zu machen. Wenn dein Pixelclock größer 14,3Mhz ist, 
wird es unmöglich per random Access und 100Mhz SDRAM Clock (RCD=2clk, 
CL=3clk, RP=2clk: -> 7clk minimum) ein Pixel bereit zustellen. 
Geschweige denn noch eins zu schreiben.

: Bearbeitet durch User
von W.S. (Gast)


Lesenswert?

Steffen H. schrieb:
> Du widersprichst dich ja selber. Keiner will zugleich zugreifen. Das hat
> hier niemand gesagt/geschrieben.

Ich habe den Eindruck, daß du bloß den Thread anheizen willst.

Also:
Es gibt einen Bildspeicher, meinetwegen SDRAM, ist hier aber egal.
Es gibt aber zwei voneinander unabhängige Akteure, die darauf zugreifen 
müssen, hier also CPU und Display genannt. Folglich braucht es ein 
Zugriffs-Regime, das den Zugriff beider Akteure regelt. Und zugleich 
zugreifen wollen in der Regel auch beide. Oder sagen wir's allgemeiner: 
zeitlich überlappend. Das muß man erstmal geregelt kriegen.

W.S.

von Julian (Gast)


Lesenswert?

Ich habe jetzt erst bemerkt, dass mein Thread noch etwas lebt :-)

>Welchen FPGA und welchen SD-RAM willst/hast du in Verwendung?

Also ich habe hier ein DE 10 lite mit Altera Max10 FPGA. Ich hoffe das 
ist eine gute Basis... viele Alternativen gibt es ja im Moment nicht zu 
kaufen.

von Dergute W. (derguteweka)


Lesenswert?

Moin,

W.S. schrieb:
> Und zugleich
> zugreifen wollen in der Regel auch beide. Oder sagen wir's allgemeiner:
> zeitlich überlappend. Das muß man erstmal geregelt kriegen.

Nur, wenn man glaubt, dass man selbst einen besseren SDRAM controller 
schreiben kann, als der jeweilige FPGA Hersteller.
Sonst macht der das. Da kannst du vorher angeben, wieviele Ports zum 
SDRAM du haben willst, ob die RW, oder RD_ONLY oder WR_ONLY sein sollen, 
etc.
Auch ein Grund, warum man nie so genau weiss, wie lange es dann dauert, 
bis die angeforderten Daten aus dem SDRAM "da" sind. Kann ja sein, dass 
nicht nur grad ein Refesh ansteht, sondern evtl. noch weitere R/W 
Operationen von anderen SDRAM-Controller-Ports.

Julian schrieb:
> Ich hoffe das
> ist eine gute Basis...
Denke schon. SDRAM ist drauf und eine VGA Buchse, was willste mehr :-)

Gruss
WK

: Bearbeitet durch User
von J. S. (engineer) Benutzerseite


Lesenswert?

Julian schrieb:
> viele Alternativen gibt es ja im Moment nicht zu
> kaufen.

Nun ja, zum Basteln gibt es schon einiges:
https://shop.trenz-electronic.de/de/Produkte/Trenz-Electronic/

Bitte 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
Noch kein Account? Hier anmelden.