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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.