HI, Ich bin noch ein Anfänger und habe Probleme mit dem SDRAM auf dem Cyclone II EP2C35F672C6N. Ich habe folgendes Problem. Ich möchte das SDRAM verwenden. Das habe ich über den SOPC-Builder gemacht. Compilieren etc. funktioniert einwandfrei. Wegen des SDRAM habe ich ein PLL mit folgenden Daten generiert (über den Wizard): CLOCK 50 MHZ für SDRAM Phasen-Shift -3 ns Das Compilieren funktioniert tadelos! Aber im NIOS IDE beim compileiren (einfaches Halo World Programm) bekomme ich folgende Meldung: Verify failed between address 0x800000 and 0x80D58F Leaving target processor paused was kurz heißt, phasen shift ist nicht richtig gesetzt. Hat jemand den gleichen Board bzw. für diesen Board eine Lösung gefunden, wass ich da einstellen muss. Ich habe den SOPC Builder ganz simple gehalten, damit ich andere Fehlerquellen ausschließen kann: WAS ICH IM SOPC HABE JTAG UART NIOS e TIMER SDRAM mehr nicht. Ich hoffe jemand kann mir bei diesem Problem helfen.
Vielleicht solltest Du die Phase in die andere Richtung schieben? Probier es doch aus. Grüße, Kest
Hi, danke für die Antwort erstmal Wie gesagt ich auch versucht nach oben zu skalieren. phase shift: -3 bis +3 ehrlich gesagt ist das eine Sisyphos Arbeit. Ich habe gehofft, jemand hätte das Problem gehabt und gelöst.
Tja, wie es für Anfänger üblich ist, hast Du die Frage nicht so gestellt, dass dir schnell jemand helfen kann: BAGDA schrieb: > Ich bin noch ein Anfänger und habe Probleme mit dem SDRAM auf dem > Cyclone II EP2C35F672C6N. Da geht's leider schon los. Das FPGA hat kein SDRAM, höchstens einen SDRAM Controller. Du hast hoffentlich einen Controller verwendet, der zu dem angeschlossenen SDRAM Baustein passt. Und braucht dieser Controller überhaupt eine eigene PLL mit speziellem Phasenshift? Was für ein Board setzt Du ein? Welche Version von Quartus verwendest Du? Ist die vom Verify gemeldete Adresse überhaupt die des SDRAMs? Fragen über Fragen.
normalerweise sollte man die Phase in ° einstellen, also -45°, 90°, .... Was sind schon 3 ns bei 50 MHz? Genau -- nichts. Du kannst auch mit dem Oszi alles messen, dann musst Du nicht ausprobieren. Grüße, Kest
Ja du HAST RECHT DA HÄTTE ETWAS GENAUE SEIEN SOLLEN; WIE GESAGT sdram cONTROLLER VERWENDE ICH: HABS VERGESSEN GENAU ZU ERWÄHNEN ADRESSE STAMMT VOM SDRAM CONTROLLER SONST WÜRDE ICH NICHT VERMUTEN DAS ES AM SDRAM CONTROLLER LÄGE: QUARTUS 9.1 SP2 Cyclone II EP2C35F672C6N. Du hast hoffentlich einen Controller verwendet, der zu dem angeschlossenen SDRAM Baustein passt. JEP! HAB ICH!
ACH ja HAB ICH VERGESSEN zu erwähnen, ja der SDRAM controller benötigt einen speziellen speziellem Phasenshift. Danke für die Antworten
Du hast immer noch nicht verraten welches Board. Der verbaute SDRAM wäre auch interessant (die Boards können durchaus unterschiedlich bestückt sein). Du hast dein Design vorher mit einem internen Blockram ausprobiert?
BAGDA schrieb: > ACH ja HAB ICH VERGESSEN zu erwähnen, > ja der SDRAM controller benötigt einen speziellen speziellem > Phasenshift. Hm, ich habe erst neulich ein SOPC mit SDRAM controller gemacht. Mal sehen, wie ging das doch gleich?? ... Ah ja! Da ist eine PLL als eigenständige Komponente im SOPC System drin. Damit mache ich aus dem externen Takt (ext_clk, 16MHz) den Systemtakt (sys_clk, 64MHz). Über die Phasenlage habe ich keine Aussage gemacht. Es ist ja auch wurscht wie der sys_clk im Bezug auf den ext_clk liegt. Alle Komponenten (NIOS, SDRAM, ...) laufen mit dem sys_clk. Das wars schon, mehr ist da doch gar nicht zu run. Und funktioniert hat's auch problemlos.
Hab das Problem behoben, ging ganz einfach: Quartus II 9.1 deinstalliert Quartus II 10 installiert Beispiel ausgeführt => funktioniert Ich weiß nicht genau warum es bei der 10 Version geklappt hat Danke aber nochmals für die zahlreichen Hilfestellungen! Gruß, Bagda
Wenn ein Fehler mit einer Änderung kommt oder geht gibt es 4 Möglichkeiten: 1. Es tut jetzt und ich weiß warum 2. Es tut jetzt und ich weiß nicht warum 3. Es tut nicht mehr und ich weiß warum 4. Es tut nicht mehr und ich weiß nicht warum Du bist gerade im Fall 2 gelandet, meiner Meinung nach dem gefährlichsten. Das fällt dir irgendwann wieder auf die Füße! Und zwar beim Serienanlauf des Produkts wenn Du gerade auf dem Weg in den Urlaub bist. Mein Rat: Installiere nicht einfach eine neue Software wenn nicht der begründete Verdacht besteht, dass die alte Software einen nachweisbaren Fehler erzeugt. Versuche immer, einen Fehler einzugrenzen und messtechnisch dingfest zu machen. Auch wenn es zunächst mehr Aufwand bedeutet. Das gilt nicht nur fürs FPGA-Design.
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.