Hat das schon jemand versucht einen SDRAM im Burst Read über die Page/Bank Grenze hinaus kontinuierlich oder mit einem Zähler auszulesen? Ich benötige dies, um zum Beispiel eine ganze Zeile Displaydaten am Stück aus dem SDRAM zu lesen. Dabei ist meine Page Größe nur 256 32Bit-Bytes groß und würde bei einem benötigten READ von sagen wir mal 800 32Bit Daten 4mal wechseln/überspringen. Meine Idee: Man kann ja schon die nächste Bank öffnen wenn man noch eine andere Bank liest. Setzt man dann noch an der richtigen Stelle den nächsten READ Befehl ab - also genau um CAS-LATENCY früher bevor der vorhergehende Burst Read zu Ende ist - werden gleich im Anschluss die Daten der nächsten Bank abgesetzt. Nun muss nur noch die vorhergehende Bank mit einem precharge geschlossen werden. Falls das der letzte Read gewesen sein sollte, müsste man jetzt statt der nächsten Bank zu öffnen und einen neuen READ zu starten einen BURSTSTOP - ebenfalls wieder CAS-LTENCY früher bevor zu Ende sein soll - absetzen gefolgt von einem PRECHARGE der noch offenen Bank. Könnte das so funktionieren oder übersehe ich da noch was? Ich hab mal die relevanten Auszüge aus dem SDRAM Datenblatt mit angehangen.
Angehängte Dateien:
-
Screenshot_20210610-104507.jpg
240 KB -
20210610_105501.jpg
230 KB -
20210610_105558.jpg
240 KB -
20210610_105639.jpg
230 KB
Steffen H. schrieb: > Hat das schon jemand versucht einen SDRAM im Burst Read über die > Page/Bank Grenze hinaus kontinuierlich oder mit einem Zähler auszulesen? Na, so ähnlich. Ich hatte mal einen Speichertest geschrieben, um festzustellen, ob ein 8 MB oder 16 MB SDRAM am LPC4088 hängt - und das ging voll in die Hose, weil genau dabei der LPC einfach steckenblieb, nur per Reset wieder erweckbar. W.S.
Steffen H. schrieb: > Nun muss nur noch die vorhergehende Bank mit > einem precharge geschlossen werden. Mach aus dem letzten Read auf Bank A einen Read mit Autoprecharge für die letzte Bank - das spart dir den extra Precharge-Befehl. Irgendwann musst du aber einen Activate-Befehl für die "nächste" Bank unterbringen. Wenn der Command-Adress-Bus ständig (d.h. jeden zweiten Takt) mit Read-Befehlen belegt ist, kann es für den Activate Befehl eng werden. Es geht sicher, wenn dein DRAM Burstlänge 8 unterstützt - dann kannst du zwischen 2 Read-Befehlen den Activate für die nächste Bank unterbringen und beliebig lange unterbrechungsfreie Datenausgangsströme daraus abrufen. Musst nur aufpassen, dass das DRAM zwischendurch auch seinen Refresh braucht. Spätestens der begrenzt den völlig kontinuierlichen Datenstrom am Ausgang bei deiner Leseweise.
Achim S. schrieb: > Musst nur aufpassen, dass das DRAM zwischendurch auch seinen Refresh > braucht. Das hätte mich jetzt auch davon abgehalten, solch einen Versuch anzugehen. Für einen kontinuierlichen Datenstrom braucht es immer irgendwo mindestens eine FIFO, zumal nicht gesagt ist, wie schnell jeweils abgeholt wird und ob das auch nicht besser gepulst gemacht wird. Ich hatte etwas Ähnliches im Schreibbetrieb für einen Datalogger, der auf mehrere DDRs arbeitete und es war trotz trickreichem Analysieren nicht 100% möglich, den Refresh abzupassen, um zwischen Eingangspuffer und Data-buffer des Controllers zu vermitteln. Sobald mehr als ein Chip im Spiel ist, wird es unvorhersagbar, was die gerade tun. Hinzu kommt der temperaturabhängige Refresh mancher Bausteine, was den Schreib-Lese-Zyklus noch verschiebt.
Achim S. schrieb: > Mach aus dem letzten Read auf Bank A einen Read mit Autoprecharge für > die letzte Bank - das spart dir den extra Precharge-Befehl. Die Idee ist gut. Aber wird dadurch der Burst Read abgebrochen? Ich glaube nicht. Somit muss ich dann trozdem ein BURSSTOP senden. Achim S. schrieb: > Irgendwann musst du aber einen Activate-Befehl für die "nächste" Bank > unterbringen. Wenn der Command-Adress-Bus ständig (d.h. jeden zweiten > Takt) mit Read-Befehlen belegt ist, kann es für den Activate Befehl eng > werden. Es geht sicher, wenn dein DRAM Burstlänge 8 unterstützt - dann > kannst du zwischen 2 Read-Befehlen den Activate für die nächste Bank > unterbringen und beliebig lange unterbrechungsfreie Datenausgangsströme > daraus abrufen. Der SDRAM unterstützt 1, 2, 4, 8 und Page Burst. Und genau diesen Page Burst wollt ich nutzen. Diesen kann man - wenn ich dies richtig verstanden habe - mit einem BURSTSTOP Befehl oder einem PRECHARGE Befehl beenden. AUTOPRECHARGE ist im Page-Burst-Modus nicht verfügbar. Ist ja auch einleuchtend - denn den PageBurst kann man nur manuell stoppen. Wenn da der interne Zähler an der Adressgrenze der Page angekommen ist fängt der einfach wieder bei 0 an. Dies konnte ich nun schon testen. Hab einen kleinen UART <-> SDRAM Read/Write Tester geschrieben. Achim S. schrieb: > Musst nur aufpassen, dass das DRAM zwischendurch auch seinen Refresh > braucht. Spätestens der begrenzt den völlig kontinuierlichen Datenstrom > am Ausgang bei deiner Leseweise. Das sollte machbar sein. Irgendwann - innerhalb der 64ms - kommt sollte der SDRAM-Controller aus der READ State herauskommen und sich im IDLE befinden. Dann kann er refreshen. Der SDRAM ist übrigens nicht extern sondern fest im FPGA verbaut.
Weltbester FPGA-Pongo schrieb im Beitrag #6722315: > Für einen kontinuierlichen Datenstrom braucht es immer irgendwo > mindestens eine FIFO, zumal nicht gesagt ist, wie schnell jeweils > abgeholt wird und ob das auch nicht besser gepulst gemacht wird. Genau, einen FiFo hatte ich eingeplant. Auf beiden Seiten - Read und Write
>Der SDRAM ist übrigens nicht extern sondern fest im FPGA verbaut. Darf man fragen welches FPGA das ist?
Steffen H. schrieb: > Der SDRAM unterstützt 1, 2, 4, 8 und Page Burst. Und genau diesen Page > Burst wollt ich nutzen. ok: ist eher ungewöhnlich, und das hatte ich im Eröffnungsbeitrag nicht verstanden. Aber wenn es sich um ein embedded SDRAM handelt, kann sowas natürlich "vorkommen". Uwe schrieb: > Darf man fragen welches FPGA das ist? Der Frage schließe ich mich an. Steffen H. schrieb: > Genau, einen FiFo hatte ich eingeplant. Auf beiden Seiten - Read und > Write Ist es dann denn noch wichtig, dass das DRAM ununterbrochen Daten verschickt? Du muss die Transsferrate vom DRAM doch nur im Mittel höher bekommen, als die benötigte Datenrate am Ausgang. Wenn das der Fall ist, stören kleine Wartepausen am DRAM doch gar nicht mehr, sondern du musst sie ggf. sogar einlegen, damit du den Abnehmer der Daten (Display?) nicht überrennst.
Uwe schrieb: >>Der SDRAM ist übrigens nicht extern sondern fest im FPGA verbaut. > Darf man fragen welches FPGA das ist? Ich tippe mal auf GOWIN little Bee 1NR9. Den hat Trenz auf dem Modul TEC-0117-1 für ca. 30 Ocken. Sind aber nur magere 8 Megabyte SDRAM drin.
Uwe schrieb: >>Der SDRAM ist übrigens nicht extern sondern fest im FPGA verbaut. > Darf man fragen welches FPGA das ist? Schaust du hier: Anlogic EG4S20 FPGA Beitrag "Sipeed Lichee Tang FPGA mit RISC-V Core aus China unter 20€" Achim S. schrieb: > Ist es dann denn noch wichtig, dass das DRAM ununterbrochen Daten > verschickt? Du muss die Transsferrate vom DRAM doch nur im Mittel höher > bekommen, als die benötigte Datenrate am Ausgang. Wenn das der Fall ist, > stören kleine Wartepausen am DRAM doch gar nicht mehr, sondern du musst > sie ggf. sogar einlegen, damit du den Abnehmer der Daten (Display?) > nicht überrennst. Genau so möchte ich das machen. Ich will nur jede Zeile des Displays im Voraus, quasi ab der horizontalen Sync-Pause schonmal in einen FIFO vorladen. So kann man dann auch noch den SDRAM mit Daten füllen und den Refresh machen. So meine Idee. Hier hab ich jetzt mal meinen bisherigen SDRAM-Tester vorgestellt: Beitrag "[Verilog] FPGA SDRAM Tester per UART" Gruß Steffen
Gibt es übrigens auch bei Distrelect https://www.distrelec.de/de/fpga-entwicklungsboard-sipeed-tang-primer-seeed-studio-102110202/p/30185703?queryFromSuggest=true Schnuckliges Teilchen. Eigentlich 64Mbit SDRAM, 32bit Datenbreite organisiert zu 256 Column x 2048 Rows x 4 Banks
Interessant, ich wollte mit dem FPGA auch schon mal den SDRAM für einen Logic-Analyzer nutzen, konnte aber nirgends ein Datenblatt auftreiben was das maximal mögliche Timing des SDRAMs beschreibt. Hast Du da bessere Informationen gefunden, oder woher sind die Diagramme oben? Im FPGA Datenblatt stand damals glaube ich nicht mal der maximale Takt des SDRAMs...
Doch, irgendwo steht dazu was drin - In der chinesischen Version 2.6 von 2020, ab Seite 6. Es handelt sich um einen EM638325 Speedgrad-5 bis 200MHz. Bis 192MHz hab ich es schon geschafft. Und ich glaube sogar dass ich da nicht mal den Takt verschoben hatte. Zum FPGA gibt 2 Datasheets die ins englische übersetzt sind. Die V1.4 - Da findet man die nähere Pinbelegung des EG4S20BG256 (der FPGA auf dem Tang Primer) Die V2.8 - Das umfangreichste Datasheet zum FPGA in englisch Dann gibt es da noch die V2.6 - Da steht dann was zum SDRAM drin. Allerdings in Chinesisch.. Ich hab dann auch mal angefangen das Chinesische Datasheet mit der SDRAM Passage ins englische zu übersetzen. Hab dir mal alle oben beigefügt. Auch das des SDRAM.
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.