Forum: FPGA, VHDL & Co. SDRAM am FPGA in VHDL


von Paul M. (Gast)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

ich habe das DE0-Nano-Board von Terasic. Darauf sitzt ein Cyclon 4 FPGA 
und ein ISSI IS42S16160G-7TLI SDRAM, siehe Datenblatt anbei.
Mein Ziel ist es nun, von FPGA Daten in das SDRAM zu schreiben und 
später wieder auszulesen.
Dazu habe ich einen SDRAM-Controller in VHDL (basierend auf dieser 
Verilog-Version: ) geschrieben sowie ein Modul (memory_manager.vhd), das 
auf einer Ebene höher die Schreib- und Lesevorgänge steuert.

Alles was dazu gehört (Testbench, macro-File für ModelSim und sogar das 
Modell des SDRAMs) habe ich angehängt.
In der Simulation funktioniert es auch - ich kann Daten in das SDRAM 
schreiben und später wieder auslesen.

Auf dem DE0-Nano habe ich jedoch Probleme: Wenn ich wie in der Testbench 
aufsteigende Werte in das SDRAM schreibe und danach wieder auslese, dann 
sind die Werte verschoben (wenn ich die Werte 0..299 i schreibe, dann 
bekomme ich 1..299 (und als letzten Wert etwas ganz anderes) zurück). 
Ich vermute daher, dass das Timing einfach noch nicht ganz stimmt.

Was habe ich schon versucht:
Ich habe per PLL den Takt clk auf 125MHz eingestellt und clk_sdram 
ebenfalls auf 125MHz, aber mit 270° Phasenverschiebung zu clk.

Über Tipps würde ich mich sehr freuen.

Bitte lasst wissen, wenn ihr noch weitere Infos benötigt.

Viele Grüße,
Paul

von Robert P. (fpgazumspass) Benutzerseite


Lesenswert?

Du samples die Werte immer nur wenn current_state = read_data, was recht 
ungünstig ist, wenn du mit clk_sdram eintaktest, aber mit clk den 
current_state bestimmst.

Ansonsten ist ein Versuch mit 270° nicht ausreichend.
Beispiel: auf dem DE2-115 funktioniert der SDRam bei mir nur korrekt 
zwischen 112.5 - 135° Verschiebung. Man muss also schon recht genau 
hinsehen und nicht nur einen Wert probieren.

Vorteilhaft ist, wenn man erstmal bei niedrigerem Takt schaut ob alles 
passt.
Desweiteren gibst du den Takt kombinatorisch raus.
In dem Fall musst du den Aussgang constrainen auf x ns relativ zu den 
Datenpins.


Alternativ kann ich empfehlen den Takt in ein IO-Flipflip zu bekommen.
Das geht z.b. indem du den verschobenen Takt mit doppelter Taktrate 
erzeugst und ein Flipflop damit toggelst, dessen Ausgang auf den Pin 
geht.
Aber auch in dem Fall muss natürlich der SDRam Takt passend verschoben 
sein.

von Wletbester FPGA-Pongo (Gast)


Lesenswert?

Robert P. schrieb:
> Vorteilhaft ist, wenn man erstmal bei niedrigerem Takt schaut ob alles
> passt.
Um dann das RAM zu untertakten und die refreshs zu verpassen? Schlechte 
Idee!

> Desweiteren gibst du den Takt kombinatorisch raus.
Au.

> In dem Fall musst du den Aussgang constrainen auf x ns relativ zu den
> Datenpins.
Au.

> Alternativ kann ich empfehlen den Takt in ein IO-Flipflip zu bekommen.
> Das geht z.b. indem du den verschobenen Takt mit doppelter Taktrate
> erzeugst und ein Flipflop damit toggelst, dessen Ausgang auf den Pin
> geht.
Nochmal Au.

RIchtige DDR-Zellen bitte. Wegen budget und internem Timing des RAMs.

von Robert P. (fpgazumspass) Benutzerseite


Lesenswert?

Wenn man DDR Zellen zur Verfügung hat, dann sollte man die natürlich 
benutzen. Hat man leider nicht immer. Welches Budget das sein soll 
erschließt sich mir aber nicht.

Wenn du etwas daran auszusetzen hast, dann bitte etwas mehr Substanz als 
ein dreifaches "Au".

>> Um dann das RAM zu untertakten und die refreshs zu verpassen? Schlechte Idee!

Hast du dir den Code angesehen? Scheint nicht so. Die Refreshzeiten 
werden dort aus der Frequenz abgeleitet. Kann man also machen.


Bitte dem TO helfen und nicht nur trollen, das wäre nett.

: Bearbeitet durch User
von Paul M. (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Robert,

Danke für Deine Antwort.

Robert P. schrieb:
> Du samples die Werte immer nur wenn current_state = read_data, was recht
> ungünstig ist, wenn du mit clk_sdram eintaktest, aber mit clk den
> current_state bestimmst.
Tatsächlich, nach langem Suchen hat sich herausgestellt, dass es daran 
lag. Wenn ich nicht bei read_data, sondern bei read_end samplen tue, 
dann geht es! :-)
Funktionierender Code im Anhang.

>
> Ansonsten ist ein Versuch mit 270° nicht ausreichend.
> Beispiel: auf dem DE2-115 funktioniert der SDRam bei mir nur korrekt
> zwischen 112.5 - 135° Verschiebung. Man muss also schon recht genau
> hinsehen und nicht nur einen Wert probieren.
Das wären ja im Mittel ca. 120°. Mit 360° - 120° = 240° geht es bei mir. 
Vielleicht messe ich die Phasenverschiebung ja einfach nur von der 
anderen Richtung. f_clk = 125MHz.

Vielen Dank Dir für die Hinweise!

Gruß,
Paul

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
Noch kein Account? Hier anmelden.