Forum: FPGA, VHDL & Co. SDRAM Burst lesen ohne Unterbrechung über Column, Row und Banks hinaus


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Steffen H. (avrsteffen)



Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Achim S. (Gast)


Lesenswert?

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.

von Weltbester FPGA-Pongo (Gast)


Lesenswert?

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.

von Steffen H. (avrsteffen)


Lesenswert?

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.

von Steffen H. (avrsteffen)


Lesenswert?

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

von Uwe (Gast)


Lesenswert?

>Der SDRAM ist übrigens nicht extern sondern fest im FPGA verbaut.
Darf man fragen welches FPGA das ist?

von Achim S. (Gast)


Lesenswert?

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.

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Lesenswert?

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.

von Steffen H. (avrsteffen)


Lesenswert?

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

von Steffen H. (avrsteffen)


Lesenswert?

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

von Eagle20 (Gast)


Lesenswert?

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

von Steffen H. (avrsteffen)



Lesenswert?

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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.