Hat jemand schon mal das SD-RAM auf dem MAX1000 angesprochen? Wie macht man das aus Verilog heraus? Braucht man eine Art SD-RAM Controller, den man im FPGA realisiert, oder benutzt man eine geeignete IP?
Martin O. schrieb: > Hat jemand schon mal das SD-RAM auf dem MAX1000 angesprochen? Ja. > Wie macht > man das aus Verilog heraus? Man implementiert einen SDRAM controller, beispielsweise in dem man einen freien Core antsprechend adaptiert. https://github.com/stffrdhrn/sdram-controller Schau Dir doch einfach mal das datenblatt des SDRAM's an, dann sollte klar werden was dein Controller tun muss. http://www.issi.com/WW/pdf/42-45S16400J.pdf Eventuell ist auf deinem Board ein anderer/ähnlicher Speicher drauf. Man braucht im wesentlichen ein/zwei FSM für Initialisierung und Addressdemultiplex/Speicherkommandierung. > Braucht man eine Art SD-RAM Controller, den > man im FPGA realisiert, oder benutzt man eine geeignete IP? Das ist im Prinzip das selbe.
Im Trenz-Forum gibt es auch ein zwei Beiträge dazu. Ich würde den SDRAM Controller von Intel im Platform Designer (ehemals QSYS) nutzen und den Avalon Bus exportieren, dieser ist recht einfach anzusprechen. Adresse dran, das Read oder Write Flag setzen und Daten über readdata/writedata lesen/schreiben.
Besten Dank schon mal für die Hinweise. Kann man bei so einem SD-RAM Controller dann eigentlich vorhersagen, wie hoch die Schreib/ bzw. Lesezeiten sind?
Naja man kann eine theoretische Berechnung machen. Ich glaube irgendwo steht das der SDRAM mit maximal 166 MHz arbeiten kann (User Manual). Bei deinem 16 Bit Datenbus kannst du dir schnell ausrechnen was theoretisch möglich ist. Wie weit Theorie und Praxis auseinander liegt kann ich nicht sagen.
Donni D. schrieb: > Wie weit Theorie und Praxis auseinander liegt kann ich > nicht sagen. Das kommt nur drauf an, wie Du auf den Speicher zugreifst: linear (dann kommst Du evt. dicht an das theoretische Maximum) oder völlig wahlfrei (dann schaffst Du vielleicht noch ein Zehntel davon).
Markus F. schrieb: > Donni D. schrieb: >> Wie weit Theorie und Praxis auseinander liegt kann ich >> nicht sagen. > > Das kommt nur drauf an, wie Du auf den Speicher zugreifst: linear (dann > kommst Du evt. dicht an das theoretische Maximum) oder völlig wahlfrei > (dann schaffst Du vielleicht noch ein Zehntel davon). Nope, "burst oder nicht burst" ist hier die Frage. Und "crossing page boundaries or not crossing" Sowie "Is it time to refresh?" Nicht zu vergessen "How much clock cycles fit into the CASL" Fangt doch bitte wenigstens an, das Datenblatt zu lesen, bevor ihr meint alles ist so simpel das ein Fred aus dem Forum ein für allemal beantworten könnt. Oder wenigstens eine Überblicksartikel aus einem Fachmagazin: https://www.eetimes.com/document.asp?doc_id=1279726&page_number=2 http://www.es.ele.tue.nl/premadona/files/akesson01.pdf
Dr. BitnByte schrieb: > Nope, "burst oder nicht burst" ist hier die Frage. > Und "crossing page boundaries or not crossing" > Sowie "Is it time to refresh?" > Nicht zu vergessen > "How much clock cycles fit into the CASL" ... und was ist das jetzt anderes als die Aussage "wahlfrei oder nicht" auf Details runtergebrochen? Unsereins ist auch nicht auf der Brennsuppe unterwegs ...
Markus F. schrieb: > ... und was ist das jetzt anderes als die Aussage "wahlfrei oder nicht" > auf Details runtergebrochen? Ja! Wenn Dir das nicht klar ist, dann fang doch bitte mal mit verstehenden Lesen des Datenblattes an.
Dr. BitnByte schrieb: > Ja! Wenn Dir das nicht klar ist, dann fang doch bitte mal mit > verstehenden Lesen des Datenblattes an. Ich hab' schon mal einen DDR-Controller gebaut. Funktioniert prima. Dass man dafür etwa ein Datenblatt lesen müsste, darauf wär' ich jetzt im Leben nicht gekommen. Gut, daß wir so hilfsbereite und freundliche Kollegen wie dich hier im Forum haben!
Dr. BitnByte schrieb: > https://www.eetimes.com/document.asp?doc_id=1279726&page_number=2 > http://www.es.ele.tue.nl/premadona/files/akesson01.pdf speziell eine einfache Formel am Ende - The time to read the first bit of memory from a DRAM with the wrong row open is tRP + tRCD + CL. ist so nicht ganz richtig: es fehlt noch tRAS, falls falsche ROW geöffnet wurde bzw. weniger, falls nach ACT schon ein paar Zyklen durchlaufen sind. Damit erhält man: time <= tRP + tRCD + CL + tRAS Da idR auf letzten Row-Bereich schon lesend/schreibend zugegriffen wurde: time <= tRP + tRCD + CL + (tRAS - tRCD) etc.
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.