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!
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
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.
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.
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
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
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.
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.
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
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.
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.
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.
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.
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..
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.
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.
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.
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.
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.
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.
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
