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