Ich habe eine Frage zum Thema SDRAM. Ich verwende ein MT48LC8M16A2 von Micron. Das Datenblatt habe ich mit (zwar noch nicht komplett) durchgelesen und habe die einzelnen Teile verstanden. Also erst Initalisierung (100us warten, dann alle Banks PRECHARGEn, MODE REGISTER setzen und im Idle entweder NOP oder AUTOREFRESH durchführen) dann Lesen/Schreiben mit ACTIVE, READ/WRITE, evtl BURSTTERMINATE und anschließendem PRECHARGE um die Bank zu "schließen". Wenn nichts zu tun ist dann ein AUTOREFRESH oder NOP (aber eben nicht den Refresh alle paar ms/us vergessen). Ist das die richtige Vorgehensweise ? Ich benötige auch nur einen Single-Word Burst (also immer nur eine Speicherstelle auslesen/beschreiben), um die ganze sache nicht allzu kompliziert werden zu lassen. Meine Frage ist : Habe ich das so richtig verstanden ? Also nach dem Init meine Lese/Schreib-Operationen durchführen und wenn nichts zu tun ist das SDRAM im Autorefresh verharren zu lassen. Wie würde das aussehen wenn ich während das SDRAM einen Autorefresh durchführt eine Lese/Schreib-Operation antriggere ? Reicht es da nachher einfach wieder in den Auto-Refresh zu gehen, oder muß ich dem irgendwie bescheid sagen wo der weitermachen soll ? Da ich mit SDRAM noch nicht viel gemacht habe ich da etwas bedenken das die Vorgehensweise vllt falsch ist/sein könnte. Was meint ihr dazu ? Gruß
Es gibt doch von Xilinx den MIG Core. Mit Hilfe dieses Cores hast Du eine Möglichkeit recht schnell einen Controller für SDRAM; DDRRAM; DDR2RAM und DDR3RAM zu erzeugen
Hallo Johann, ich würds gerne erstmal "zu Fuß" probieren, bevor ich einem Core alles überlasse. Außerdem habe ich bei einem Core ja das Problem das der dann bei einen Update des ISE's u.U. rumzickt. Ebenfalls habe ich das "Problem" das ich die ISE 9.1 nutze und auch nicht weiter upgraden möchte, da es mir davor graut welche Fehler als nächstes in der ISE drin sind. Mir reicht es schon das das Teil alle Nase lang abstürzt. Und mit der neueren Version wirds sicherlich nicht besser. Außerdem geht es mir ja auch um das Verständnis der SDRAM's und das würde bei einem MIG Core eben unter den Tisch fallen. Na ja. Vllt überleg ichs mir ja noch mit dem MIG, aber zuerst möchte ich es zu Fuß ausprobieren. Daher eben auch die Frage ob man es so machen kann, bzw ob es so die richtige Vorgehensweise ist.
Rene Böllhoff schrieb: > Ebenfalls habe ich das "Problem" das ich die ISE 9.1 nutze und auch > nicht weiter upgraden möchte, da es mir davor graut welche Fehler als > nächstes in der ISE drin sind. Mir reicht es schon das das Teil alle > Nase lang abstürzt. Und mit der neueren Version wirds sicherlich nicht > besser. Doch, das ist erstaunlicherweise viel besser geworden. Seit der 11 ist mir die ISE noch nie wieder abgeschmiert. Was zu einem großen Teil an den endlich mit 10.1 eingeführten XML-Projektfiles liegt. > Außerdem geht es mir ja auch um das Verständnis der SDRAM's und das > würde bei einem MIG Core eben unter den Tisch fallen. Bei opencores.org gibts einen Core, da kannst du die Funktionsweise lernen. Ist aber glaube ich in Verilog.
"Im Autorefresh verharren lassen" klingt etwas seltsam, im einfachsten Fall stellst du einfach sicher, dass das Auto Refresh Kommando ausreichend oft gegeben wird, damit alle Rows in 64 ms einen refresh Zyklus bekommen, das läuft typischerweise auf ein Intervall von ein paar us zwischen zwei Auto Refresh Kommandos hinaus. Wenn du ganz simpel testen möchtest, ob du das Protokoll richtig sprichst und das Timing am Interface hinhaut kannst du auch einfach die ersten paar 1000 Wörter beschreiben und direkt danach auslesen, da sie nach dem Schreiben zumindest 64 ms überstehen sollten (im Normalfall deutlich länger) kannst du die Schreibe-, Leselogik so testen, ohne dir über den Refresh Gedanken zu machen. lg m
Also ich habe auch die Version 11.4 drauf und ich bin damit bis jettz sehr zufrieden. Ich finde es immer extrem das sich einige Leute über die Software beschweren und dann noch mit einer so alten Software arbeiten. So nach dem motten blos nicht neues dazulernen es könnte sich ja etwas verändern. Manchmal muß man auch mal mit der Zeit gehen. Ich kenne noch Leute die erstellen ihre Boards auf DOS-Programmen.
@johann >Ich finde es immer extrem das sich einige Leute über die >Software beschweren und dann noch mit einer so alten Software arbeiten. Also das neue Software immer besser ist halte ich für ein Gerücht. Das beste Beispiel liefert für mich immer noch ISE selbst. Version 6.3 gegen 9.1. 6.3 ist nur ganz selten abgeschmiert oder hat sein Projekt zerbröselt, war von der Installation her "relativ" klein und es war sehr stabil. 9.1 schmiert sehr oft ab, muß tlw per Task-Manager beendet werden, und ist zudem grotten langsam. Wenns ab Version 11 wieder besser ist nutze ich es gerne, aber bei dem was ich hier im Forum über die Versionen nach 9.1 gelesen hab bin ich eher skeptisch. >So nach dem motten blos nicht neues dazulernen Darum gehts ja nicht. Nur wenn ich ein Projekt mit entsprechenden Cores bei einem ISE Update erst über klimmzüge wieder nutzen kann machts auch keinen Spaß, und lernen tut man dabei auch nichts. Und neues lernt man denke ich nicht dazu wenn man jedesmal wieder eine Software installiert die zwar 100 neue Features hat, von denen man aber immer nur 5 ganz bestimmte braucht. Da ändert sich dann auch bei Version 20.5 nichts daran. Dann lerne ich lieber dazu, indem ich eben keinen Core-Generator nutze und es von Hand programmiere, selbst wenns eben nicht so elegant ist. Vllt lass ich mich ja doch noch zum MiG hinreißen. Aber erstmal von Hand ausprobieren.
Rene Böllhoff schrieb: > Wenns ab Version 11 wieder besser ist nutze ich es gerne, aber bei dem > was ich hier im Forum über die Versionen nach 9.1 gelesen hab bin ich > eher skeptisch. Naja, die Unkenrufe. Hauptsächliches Argument ist der große Speicherplatzverbrauch. Aber wen jucken heutzutage 15GB auf der Platte? Bei mir läuft die 11 schneller als 9.1 und die Synthese geht auch ein ganzes Stück schneller beim gleichen Design. Einzig der Schaltplan-Editor ist langsamer geworden. Aber den braucht man ja nicht wirklich. Zerbröselte Projekte gabs seit 10.1 nicht mehr, dank xml Files. Abgeschmiert ist nur Impact immer mal von 11.1 bis 11.3, das geht aber mit 11.4 auch wieder ordentlich.
@supachris mmh .. überredet :-) Ich werd mir wenn ich Zeit finde mal das 11.irgendwas antun. Aber die alte Version ist echt ne Katerstrooofe (ums mal phonetisch zu sagen). Der Speicherplatzverbrauch ist mir im Prinzip auch schnuppe, es ging sich einzig und allein darum das das ISE 9.1 gegenüber 6.3 eben so elend lahm war, und derart oft abgeschmiert ist das es selbst fürs Hobby schon nicht mehr witzig war und da in der Regel die SW größer, klobiger und anfälliger wird, bin ich jetzt nicht von einer nennenswerten Verbesserung (eher von einer Verschlimmbesserung) ausgegangen. Aber ich lass mich wie gesagt gerne eines besseren belehren. Ist ja schließlich auch im Sinne meines Nervenkostüms :-)) Ich werd mich mal daran machen das SDRAM zu Fuß anzusprechen, und wenn das klappt und ich Zeit und Muße habe schau ich mir mal den MiG an. Nichts gegen die Cores, aber ich möchte es allein vom Verständnis her mal zu Fuß gemacht haben, und weil ich dann eben weiß was da passiert :-). Außerdem habe ich es ganz gerne (soweit es geht) portierbar. Falls ich dann mal auf Altera umsattel kann ich den größten Teil des Codes (bis auf die BlockRAMs und die DCMs) wiederverwenden.
Rene Böllhoff schrieb: > @supachris Hallo Rene, nun auch noch meinen Senf... früher gab es faßt eine eiserne Regel am besten keine ISE-Version mit einer 1 in der Version einzusetzten und bei einer Zwei zumindest das erste Patch abzuwarten. Mit V10 und V11 hat sich dies allerdings zugegebener Maße stark gebessert (obwohl auch hier wieder Dinge zu Tage getreten sind... aber lassen wir das). Das hier im Thread der MIG empfohlen wird hat durchaus seine Berechtigung. Es ist nicht der performanteste Core, "kann" aber in kurzer Zeit stabil ans laufen bekommen werden. Da Du NUR ein SDR SDRAM mit gemässigter Geschwindigkeit implementieren möchtest, dürften viele mögliche Probleme und Fallstricke auf Dich nicht zutreffen. Bevor Du aber anfängst möchte ich Dir zumindest die Dokumentation zum MIG ans Herz legen. Diese ist erstaunlich gut und gibt auch Auskunft, warum gewisse Dinge im Core für bestimmte FPGA Familien unterschiedlich gelöst wurden. Dies könnte für Dich auch nützlich sein. Ein weiterer Tip wäre das Design mit deinem Ram und dem Target-FPGA mal mit Hilfe des MIG zu implementieren und zumindest das dort ausgeworfene Pinning (UCF) herzunehmen. Der MIG enthällt teilweise handoptimierte Platzierungen. Solltest Du irgendwann einmal beschliessen den MIG Core doch nutzen zu wollen, so könnte es andernfalls passieren, das der MIG Core sonst das Timing nicht einhalten könnte. Was die Portierbarkeit angeht, so kannst Du zwar deine Statemaschines etc. übernehmen (was den grössten Teil der Codezeilen ausmacht). Den überwiegenden Teil deiner Zeit wirst Du allerdings mit den Bauteilspezifischen Problemen verbringen ( eben Takterzeugung, IO und interne Latenzen, etc.). Gruß Andreas
Hallo Rene, der Xilinx MIG unterstützt keine SDR SDRAMs. Und Dein SDRAM ist ein SDR. Die Tipps von Andreas bringen Dir daher nicht viel. Von Elpida gibt es noch ein paar gute Manuals und AppNotes zum Thema: http://www.elpida.com/pdfs/E0123N81.pdf http://www.elpida.com/pdfs/E0124N10.pdf Und von Analog Devices das hier: http://www.analog.com/static/imported-files/application_notes/835582452EE126.pdf Und fertig bekommst Du einen von Altera (auch für Nicht-Altera-FPGAs verwendbar): http://www.altera.com/products/ip/altera/ocore_sdr_sdram.html
Rene Böllhoff schrieb: > Meine Frage ist : Habe ich das so richtig verstanden ? Also nach dem > Init meine Lese/Schreib-Operationen durchführen und wenn nichts zu tun > ist das SDRAM im Autorefresh verharren zu lassen. Einen Autorefresh soll man nicht dauern manchen, da dies unnötig ist. Wie im Datenblatt gesagt, braucht es ca. alle 15 us einen Refreshzyklus. > Wie würde das aussehen wenn ich während das SDRAM einen Autorefresh > durchführt eine Lese/Schreib-Operation antriggere ? Während des Refreshs darf keine Schreib oder Lese-Anforderung kommen. Deshalb muss die Operation verzögert werden, bis das SDRAM wieder frei ist. > Reicht es da nachher > einfach wieder in den Auto-Refresh zu gehen, oder muß ich dem irgendwie > bescheid sagen wo der weitermachen soll ? Wie gesagt, der Autorefresh soll nicht dauernd kommen. Es genügt ein Timer mit ca. 15 us, wenn der abläüft, dann wird ein Refresh-Zyklus eingeschoben. Hast Du das Datenblatt gelesen?
@Xenu danke für den Hinweis und die Links. Werde ich mal durchackern. @Klaus Das Datenblatt hab ich gelesen (wenn auch nicht komplett, sondern erstmal nur die einzelnen Funktionsabschnitte und ein paar Timing-Diagramme), aber noch nicht alles verstanden bzw es ist mir noch nicht alles klar. >Einen Autorefresh soll man nicht dauern manchen, da dies unnötig ist. Unnötig vllt schon, aber es schadet dem SDRAM nicht, oder ?! Ich würde den Dauerfeuer-Refresh auch nur machen um die generelle Funktion zu testen. Später wenn alles läuft würde ein Timer zum einsatz kommen der eben nur alle paar us/ms einen Refresh auslöst. >Wie im Datenblatt gesagt, braucht es ca. alle 15 us einen Refreshzyklus. Ok. Die Stelle im Datenblatt hab ich noch nicht gefunden/gesehen. Ich meine ich habe irgendwo was von 64ms als maximale Zeitspanne zwischen 2 Refreshs gelesen. Zumindest würde ich tREF auf S. 50 des Datenblattes (Link ist unten) so interpretieren. >Wie gesagt, der Autorefresh soll nicht dauernd kommen. Soll, muß oder darf nicht dauernd kommen ?! Wie gesagt für einen ersten Funktionstest bzw erste Version meiner Statemachine wäre es am einfachsten. Klar ist ein Zähler kein Hexenwerk, aber wie gesagt geht es mir um einen ersten Test. >Deshalb muss die Operation verzögert werden, bis das SDRAM wieder frei >ist. Ich meine (zwischenzeitlich) etwas von "Concurrent Auto Precharge" gelesen zu haben wo genau das beschrieben ist, und bei den Micron SDRAMS wohl doch möglich ist. Wie dem auch sei, ein Refresh braucht ein paar Takte. Laut Datenblatt 60-66ns (tRFC auf S.50), bei 50MHz wären das 3-4 Takte die ich warten muß bis ich neue Operationen im SDRAM anstoßen kann, ist das richtig ? Hier noch der Link zum Datenblatt : http://download.micron.com/pdf/datasheets/dram/sdram/128MSDRAM.pdf
Hallo nochmal,
wenn Du den Refresh häufiger machst, ist das nicht schlimm, aber
unnötig. Duch den Refresh geht ja nichts kaputt - ganz im Gegenteil;
damit werden ja die Speicherzellen wieder aufgeladen.
Ich kann Dir nur sehr empfehlen, Dir in Ruhe die zwei Elpida-PDFs
durchzulesen, deren Links ich oben gepostet habe; da wird Dir sicher
vieles klarer. Vor allem das erste ("HOW TO USE SDRAM"). Beim zweiten
stehen auch Sachen drin, die wohl nicht so interessant für Dich sind,
wie z.B. PCI-Bus-Anbindung.
Rene Böllhoff schrieb: >>Wie im Datenblatt gesagt, braucht es ca. alle 15 us einen Refreshzyklus. > > Ok. Die Stelle im Datenblatt hab ich noch nicht gefunden/gesehen. Ich > meine ich habe irgendwo was von 64ms als maximale Zeitspanne zwischen 2 > Refreshs gelesen. Wenn du diese 64ms nun durch die 4096 Rows dividierst... Diese 15µs sind sowas wie eine universelle Konstante der DRAMs, denn dieser Wert hat sich über die Jahrzehnte gehalten. Wann immer sich die Anzahl Rows verdoppelte, dann verdoppelte sich auch die Lebensdauer der Zelle.
Rene Böllhoff schrieb: >>Einen Autorefresh soll man nicht dauern manchen, da dies unnötig ist. > > Unnötig vllt schon, aber es schadet dem SDRAM nicht, oder ?! > Ich würde den Dauerfeuer-Refresh auch nur machen um die generelle > Funktion zu testen. Später wenn alles läuft würde ein Timer zum einsatz > kommen der eben nur alle paar us/ms einen Refresh auslöst. > Ein Refresh braucht Strom, weil alle Zellen wieder aufgeladen werden. >>Wie im Datenblatt gesagt, braucht es ca. alle 15 us einen Refreshzyklus. > > Ok. Die Stelle im Datenblatt hab ich noch nicht gefunden/gesehen. Ich > meine ich habe irgendwo was von 64ms als maximale Zeitspanne zwischen 2 > Refreshs gelesen. Zumindest würde ich tREF auf S. 50 des Datenblattes > (Link ist unten) so interpretieren. > Nein, der Refresh muss 4096 x innerhalb von 64 ms kommen. Man verteilt üblicherweise diese Zyklen gleichmäßig (deshalb die 15-16 us), um das SDRAM nicht zu lange zu blockieren und vielleicht um den Stromverbrauch gleichmäßiger zu halten. Man könnte aber auch alle 4000 Zyklen blockweise ausführen. >>Wie gesagt, der Autorefresh soll nicht dauernd kommen. > > Soll, muß oder darf nicht dauernd kommen ?! Wie gesagt für einen ersten > Funktionstest bzw erste Version meiner Statemachine wäre es am > einfachsten. > Klar ist ein Zähler kein Hexenwerk, aber wie gesagt geht es mir um einen > ersten Test. Siehe oben. Du hast falsche Vorstellungen vom Controller. Der Normalzustand ist IDLE. Deine Statemachine reagiert auf Lese/Schreibanforderungen von außen und erledigt diese mit dem gewünschten Timing. Wenn ein Refresh ansteht, dann wird dieser gegenüber der Anforderung von Außen priorisiert, er funkt sozusagen beim Normalbetrieb dazwischen. >>Deshalb muss die Operation verzögert werden, bis das SDRAM wieder frei >>ist. > > Ich meine (zwischenzeitlich) etwas von "Concurrent Auto Precharge" > gelesen zu haben wo genau das beschrieben ist, und bei den Micron SDRAMS > wohl doch möglich ist. Wie dem auch sei, ein Refresh braucht ein paar > Takte. Laut Datenblatt 60-66ns (tRFC auf S.50), bei 50MHz wären das 3-4 > Takte die ich warten muß bis ich neue Operationen im SDRAM anstoßen > kann, ist das richtig ? > Precharge hat mit Refresh nur insofern zu tun, als vor dem Refresh alle Bänke mittels Precharge geschlossen werden müssen. Dann kann ein Refresh-Zyklus ausgeführt werden. Bevor dieser nicht abgeschlossen ist, darf kein ACTIVATE Kommando ausgeführt werden. Wenn von außen an den SDRAM Controller eine Lese/Schreibanforderung kommt während der Refresh läuft, dann muß die Operation verzögert werden.
Das die SDRAMS und DDRRAMS immer einen refresh benötigen ist ja grausam. Wenn ich mir das gerade so überlege. Das ich einen konstanten AD-Wandler Datenstrom habe und diesen abspeichern möchte dann geht das wieder nur über einen BlockRAM Zwischenspeicher.
Wenn, wie oben angedeutet, die Daten nicht schneller geschrieben werden müssen, als ein kompletter Row/Col Schreibzyklus einschliesslich Precharge dauert, dann ist für die Dauer dieser ganzen Schreibaktivität überhaupt kein Refresh erforderlich und daher ein konstanter Datenstrom ohne Puffer machbar. Der Refresh erfolgt dann implizit im Rahmen dieser Schreibzyklen. Dabei sollte man erst Rows und Banks, dann Cols hochzählen. Voraussetzung: Der Abstand dieser Zyklen ist <= 15µs/#Banks. Aber andersfalls hat man mehr als genug Zeit für Refresh zwischendurch.
@A.K. >Wenn du diese 64ms nun durch die 4096 Rows dividierst... Ok. Das mit den 15us hab ich verstanden. :-) Hätte ich auch selbst drauf kommen können :-S. @Klaus >Du hast falsche Vorstellungen vom Controller. Der Normalzustand ist >IDLE. >Deine Statemachine reagiert auf Lese/Schreibanforderungen von außen ... Genauso hatte ich mir das ja auch vorgestellt (als endgültige Lösung). Statemachine laufen lassen, ab und zu einen Refresh machen und wenn ne Anforderung von außen kommt diese Bearbeiten (solang eben kein Refresh "dazwischenfunkt", ansonsten die Operation verzögern). Nur das ich eben für den ersten Test Dauerrefresh machen wollte um eben a) ganz sicher zu gehen das die Daten nicht hops gehen und b) um meine erste Statemachine einfacher zu halten. Stromverbrauch ist in erster Linie nicht so kritisch (ich glaube kaum das ein Dauerrefresh mehr als 500mA zieht). >Bevor dieser nicht abgeschlossen ist, darf kein ACTIVATE Kommando >ausgeführt werden. Ok. Das ist klar. Dazu eben nochmal die Frage ob ich richtig liege das die Dauer der Refresh Operation tRCD entspricht, was bei 50MHz (also 20ns) 3-4 Takte (je nach Speedgrade des Rams) entspricht. Also wenn ich einen Refresh machen muß (egal ob per Dauerrefresh oder eben über einen Zähler alle 15 us) muß ich 3-4 Takte nach dem Refresh-Kommando NOPs machen, sehe ich das richtig ? Nochmal : Mir geht es nur um einen ersten Test, nicht das das unnötig ist (das ist mir schon klar). Nur es ist eben Neuland, und mit SRAM hatte ich bisher keine größeren Probleme. Nur ist SDRAM eben wegen dem Refresh ein bissl komplizierter und ich möchte nicht direkt nen Fehlschlag erleben (vor allem weil ich kein 100MHz Scope/Logic-Analyzer habe um mögliche Fehler zu finden, daher die etwas "schisshasige" Herangehensweise. @xenu Ich danke dir für die Links und die nochmaligen Hinweise. Ich werde mir die PDF's auf jedenfall durchlesen, nur wollte ich vorher schonmal abklopfen ob ich mit meinem bisherigen Verständnis richtig liege (und ich denke ich hab es richtig verstanden), selbst wenn ich etwas auf diesem Dauerrefresh "rumreite". Das der nach einem (hoffentlich erfolgreichen) ersten Funktionstest rausfliegt ist denke ich klar :-)
@xenu Ich hab mir mal das erste PDF angeschaut und ich lag mit meinem bisherigen Verständnis wohl soweit richtig. Das PDF ist sehr schön gemacht (auch die Unterschiede zum "normalen" DRAM fand ich sehr gut erklärt). Was ich vllt noch generell dazu sagen sollte : Das das SDRAM in erster Linie konzipiert ist a) schneller und b) eine größere Dichte gegenüber DRAMs zu haben ist mir klar. Allerdings benötige ich im Moment nur den 2. Aspekt. Sprich mir geht es um mehr Speicher als SRAM oder DRAM (bei beiden ist ja im groben und ganzen bei 1MByte pro Chip Feierabend). Den Geschwindigkeitsvorteil durch den Burstmode ist erstmal für mich uninteressant. Mir reicht es wenn ich (bei 50Mhz) 7 Takte zum Lesen eines einzelnen Wortes benötige. Das SDRAM wird die meiste Zeit eh Idle sein (daher auch eben die Idee mit dem Dauerrefresh für den ersten Test). Ebenfalls nicht benötigt werden Self-Refresh (also CKE bleibt dauerhaft auf High) sowie Power/Clock Down Modi. Multiple Banks, Burstlängen > 1 und dergleichen werden alle nicht benötigt. Auch reicht es mir nach einem kompletten Read/Write das Precharge von hand zu machen (also kein Auto-Precharge), da das AP ja eig. (so wie ich es verstanden habe) "nur" zusätzliche Performance bringt die ich im moment nicht benötige. Ich möchte es mir damit eben so einfach wie eben möglich machen, und dennoch die von mir verbauten 8x16 Megaworte für meine Applikation (es geht wieder um das Audio-Projekt :-))) nutzen, und da ist wie gesagt die Geschwindigkeit nicht so im Fokus, sondern eher die Speichergröße die sich mit normalen SRAMs ja nicht mal eben so realisieren lässt. Falls ich noch weitere Fragen habe (bis auf die Verständnisfrage mit tRFC und den 3-4 Takten :-)) melde ich mich.
Ich würde dir empfehlen, ein VHDL Modell von Micron zu holen und eine Testbench zu schreiben. Soviel ich erinnere, melden diese Modelle wenn man Timingverletzungen erzeugt.
@klaus Ja das werde ich mal machen. Hoffe das ich das Verilog und/oder IBIS Model so einfach mit in die Simulation packen kann. @Johann Ja gibt es. Ich habe das Verilog und IBIS Model für mein SDRAM von der Homepage geladen. Einfach den SDRAM Typen suchen den du verwendest/verwenden möchtest, und auf der rechten Seite unterhalb des Datenblatt-Links sind die Modelle zu laden.
@klaus Erstmal danke für den Hinweis mit den SDRAM-Modellen. Hab mir letztens das passende Modell runtergezogen und auch mit meiner State-Machine durchsimuliert. Das Ergebnis sieht recht gut aus, allerdings sind da noch 2 Unschönheiten bzw 2 Sachen die mir nicht so ganz einleuchten wollen. Ich bekomme bei jedem Kommando das ich an das SDRAM schicke eine Warnung über eine Timing-Verletzung. Und zwar wird die setuphold-Zeit angemeckert, das ich da 800ps (also 0.8ns wie im Datenblatt beschrieben) zu früh bin. Ich frage mich nur wie man das einhalten soll, wenn das ganze Design synchron sein soll. Also die CLK vom SDRAM und die CLK vom FPGA (ich arbeite mit 50MHz, ist also unkritisch, sprich die FPGA CLK ist nicht schneller als die max. SDRAM Clk). Ich kann in einem synchronen Design die Leitungen für die Kommandos ja nicht früher anlegen (es sei denn ich halbiere den Takt für das SDRAM) als meine System-CLK. Ansonsten habe ich keine Fehlermeldungen (also das der z.b. sagt : die Refreshzeit ist zu kurz vor dem nächsten Kommando oder sonstiges). Es werden auch die Befehle genau aufgelistet die meine Statemachine von sich gibt, also ACTIVE, READ, WRITE, PRECHARGE, REFRESH usw. Und das zweite Problem ist das die Daten die beim Schreiben und Lesen an das SDRAM gehen nicht "übernommen" werden. Der Output im Simulationsfenster sagt mir immer "Data : Z" (wenn der Befehl Schreiben an das SDRAM Dekodiert ausgeben wird), obwohl im Timing an der Stelle definitiv (laut Timing-Diagramm) ein gültiges Datenwort anliegt. Ansonsten scheint alles richtig zu sein, sprich Abwarten der Initialisierungszeit, Refresh, Mode Register und eben die schon erwähnten dekodierten Befehle im Simulationsfenster. Ich werde am Sonntag (vorher komme ich nicht dazu, da ich meinen Läppi nicht mithabe und bis Sonntag unterwegs bin) mal einen Screenshot, den Output des Simulationsfensters sowie die dazugehörigen VHDL-Files hier reinstellen).
Angehängte Dateien:
-
sdram_sim_read.JPG
110 KB -
sdram_sim_write.JPG
110 KB
Wie versprochen (oder eher angedroht) die Screenshots der Simulation, das Log-File der Simulation und die VHDL Files für die SDRAM-Statemachine, die Testbench und das SDRAM Model. Ich hoffe ich habe nichts vergessen. Es wäre schön wenn mir jemand dabei helfen könnte. Wie gesagt ist ein Problem das mir das Model zig Warnungen wegen der Timing-Verletzung anzeigt obwohl ich bei einem synchronen Design nicht wüsste wie ich ein Signal 0.8ns (oder mehr) vorher anlegen könnte. Das einzige was mir dazu einfällt ist das ich die SDRAM Clock invertiere und somit die Setup/Hold-zeit auf eine halbe System-Clock Länge verlänger. Aber ich weiß nicht ob das ein sauberer Weg ist/wäre. Das zweite Problem ist das mir laut SDRAM Model immer Z als Ergebnis einer Read bzw Write-Operation "herauskommt", obwohl die Signale laut Testbench korrekt anliegen müssten (die Befehle zum Ansteuern des SDRAMs werden ja auch richtig dekodiert ud angezeigt). Wäre schön wenn mir da jemand etwas unter die Arme greifen könnte und mir erklären kann wo da der Fehler liegen kann bzw liegt.
Rene Böllhoff schrieb: > Ich kann in einem synchronen Design > die Leitungen für die Kommandos ja nicht früher anlegen (es sei denn ich > halbiere den Takt für das SDRAM) als meine System-CLK. Natürlich kannst Du das. Z.B. indem du die Leitungen für die Kommando mit der abfallenden Flanke änderst. Dann sind die Leitungen zur aufsteigenden Flanke stabil. Achtung, Laufzeiten berücksichtigen. In einem Design, das ich einmal gemacht habe, wurde der Takt für das SDRAM direkt vom FPGA erzeugt. Dazu habe ich die DDR Eigenschaften des Spartan-3 verwendet.
>Z.B. indem du die Leitungen für die Kommando mit der abfallenden Flanke >änderst. Dann sind die Leitungen zur aufsteigenden Flanke stabil. Dann würde es doch theoretisch auch gehen wenn ich die CLK vom SDRAM invertiere. Dadurch das die CLK Leitung ohnehin am FPGA angeschlossen ist wäre es ja ein leichtes. Somit würde mein System auf die steigende Flanke reagieren, das SDRAM aber durch die Invertierung auf die fallende Flanke. Ich hab das gestern mal im Simulator durchgespielt, aber die Setup/Hold-Zeit wurde immer noch anmoniert.
Rene Böllhoff schrieb: > Das einzige was mir dazu einfällt ist das ich die SDRAM Clock invertiere > und somit die Setup/Hold-zeit auf eine halbe System-Clock Länge > verlänger. Aber ich weiß nicht ob das ein sauberer Weg ist/wäre. Warum sollte das kein sauberer Weg sein? Du mußt aber berücksichtigen, dass die vom SRAM gelesenen Daten dann auch zu einem anderen Zeitpunkt kommen. TheMason schrieb: > Ich hab das gestern mal im Simulator durchgespielt, aber die > Setup/Hold-Zeit wurde immer noch anmoniert. Irgend etwas muss sich ändern, sonst hast Du noch irgend einen Fehler. Rene Böllhoff schrieb: > Das zweite Problem ist das mir laut SDRAM Model immer Z als Ergebnis > einer Read bzw Write-Operation "herauskommt", obwohl die Signale laut > Testbench korrekt anliegen müssten (die Befehle zum Ansteuern des SDRAMs > werden ja auch richtig dekodiert ud angezeigt). Die Diagramme zeigen nicht genug. Vielleicht macht dein Problem mit den Setup/Holdzeiten dass das Modell nicht korrekt arbeitet. Ansonsten müßtest Du halt ein bischen von Deinem Code posten.
@klaus Danke für den Tipp. Ich dachte nur das es vllt kein sauberes Vorgehen ist den SDRAM-Clock "einfach so" zu invertieren. Das die Daten dann eine halbe Taktzeit später kommen ist mir bewusst und werde ich auch entsprechend in der Statemachine berücksichtigen. >Irgend etwas muss sich ändern, sonst hast Du noch irgend einen Fehler. Na ja. Vllt liegt es auch am ISE. Hab den noch nicht geupdatet. Ich probier es heut abend nochmal. >Ansonsten müßtest Du halt ein bischen von Deinem Code posten. Den Code habe ich gepostet. (siehe sdram_access.vhd) Da ist die eigentliche Statemachine die die SDRAM Ansteuerung übernehmen soll. Der Rest ist für die Testbench. Das das Simulationsmodell wegen der SetupHold-Warnung vllt nicht "funktioniert" bzw keine gültigen Daten rausgibt kann ja sein. Aber wenigstens dürfte das Prinzip schonmal richtig sein, denn die Befehle werden ja sauber ausdekodiert. Ich versuche es nochmal mit der invertierten SDRAM Clock. Ansonsten den Takt halbieren. Irgendwie muß das ja zum Laufen zu bewegen sein.
Sooo .. ich bin nun schonmal nen halben Schritt weiter. Das Invertieren des SDRAM Clocks hat geholfen. Ich hatte es zwar gestern schonmal ausprobiert, aber mir ist vorhin aufgefallen das man an das SDRAM Model auch den richtigen Clock anschließen sollte :-S. Nun hab ich keine Timingverletzungen mehr. Allerdings werden die Test-Daten auch nicht richtig geschrieben bzw gelesen. Die Log-Meldung des SDRAM Models liefert bei Data immer nur Z. Na ja. Vllt finde ich den Fehler ja noch. Falls jemandem noch an meinem Code was aufgefallen ist was falsch sein könnte bitte ich um Feedback.
Angehängte Dateien:
-
sdram_sim_init_2.JPG
180 KB -
sdram_sim_write_2.JPG
170 KB -
sdram_sim_read_2.JPG
170 KB
Hier nochmal die Screenshots von den gesamten Abläufen. So sollte es laut Datenblatt eigentlich funktionieren. Aber es wird immer nur Z übernommen/gelesen. Obwohl beim Schreiben z.b. an rdata ein Bitmuster anliegt. Oder beim lesen müsste zumindest ein Wechsel an rdata zu beobachten sein, statt einem dauerhaften Z. DQM ist auch richtig "beschaltet" (wenn ich eine 1 reinschreibe steht im Simulatoroutput "Data : Hi-Z"). Auch wenn ich dem SDRAM Model ein eigenen rdata-bus gebe ist der auch immer auf Z. Ebenso hab ich in der Simulation spaßeshalber die 100us Wartezeit "abgewartet", aber da war auch nix ... Vom Ablauf her ist es eigentlich schon fast ein SDRAM Bilderbuchdiagramm ;-). Wenn da eben nicht das Data : z wär ... Also ich weiß irgendwie nicht weiter. Hat jemand ne Idee. Oder könnte vllt jemand mal die obigen Dateien durchsimulieren (man muß nur in sdram_access aus "rclk <= clk" "rclk <= not clk" machen, die Testbench ist (fast) diesselbe wie in den hier angehängten Screenshots nur mit einem zusätzlichen Write) ?
Hallo Rene, ich habe nicht alles durchgelesen und sorry, falls Du die Frage schon beantwortet hast, aber wieso erfindest Du das Rad neu? Es gibt doch viele andere schöne Sachen, womit man sich die Zeit vertreibt ;-) Ich habe hier schon Mal SDRAM Controller von Altera gepostet. Da ist alles schön nach ein ander beschrieben, was wie man machen muss. Früher habe ich den oft verwendet, aber mittlerweile benutze ich nur noch den von Altera SOPC -- der ist ja sowieso frei. Hier sind noch mal die ganzen Dateien, vielleicht schaust Du Dir das mal an. Unter anderem ist da auch Micron VHDL Modell des Speichers. Alles sollte auf Anhieb funktionieren. Grüße, Kest
Hallo Kest,
>aber wieso erfindest Du das Rad neu?
ich hab weiter oben geschrieben das ich das ganz gerne mal zu Fuß machen
möchte. Allein schon vom Verständnis her.
Danke für den Code. Ich werd mir den mal bei Gelegenheit durchschauen.
Aber ich hoffe ja dennoch das mir jemand den oben geposteten Code mal
durchsimulieren kann, damit ich weiß ob der ISE ne Macke hat oder mein
Design noch einen Fehler hat. Ich komm da leider nicht weiter.
@TheMason: Hast Du das ganze mal testweise mit ModelSim simuliert? Dort kann man sich den Inhalt der Speicher anzeigen lassen (k.A. ob das auch mit ISIM geht). Da könntest Du sehen ob das Lesen oder schon das Schreiben das Problem ist. Duke
@Duke Ich hab kein Modelsim bei mir laufen. Nur den ISIM. Und für die meisten Zwecke reicht es ja auch aus.
Kann mir denn da niemand behilflich sein ? Ich meine vom Timing-Diagramm her siehts ja gut aus.
Hallo Rene, du benutzt ein verilog modul in einer VHDL Testbench in einer Simulation mit dem Xilinx-ISim. Ich sehe das der Datenbus "rdata" Bidirektional ist, aber laut diesem Dokument von Xilinx - http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/plugin_ism.pdf (Seite 58:) > Note Connection to bi-directional pass switches in Verilog are not >supported. - geht dies so nicht mit dem ISim. Außerdem kann dein Code so nicht synthetisert werden denn du weist einem Signal in einem getakteten Prozess ein Z zu: Z.B.: hier: >Process (clk, res) > begin > if res = '1' then > SDRAM_State <= CMD_INHIBIT; > SDRAM_IState <= X"ff"; > SDRAM_Addr <= (others => '0'); > rdata <= (others => 'Z'); Dies funktioniert zwar in einer Simulation; die Synthese muss hier ein Register aus 8-Flipflops für "rdata" bauen, aber kein Flipflop kann ein "Z" speichern! Nur die IO-Blöcke der FPGAs können ein Z auf den Pins treiben. Die Zuweisung muss in VHDL dann in etwa so aussehen:
1 | rdata <= "ZZZZZZZZ" when (tristate_ein = '1') ELSE datenausgabe; |
Um nun dein Problem zu lösen: eventuell geht es wenn du diese Zuweisung ein eigenes verilog Modul (wrapper) schreibst, welches dann das Verilog Modell des des SDRAMs aufruft. Es gehen dann von deinem VHDL zwei Datenbusse (1x ein,1x aus) und ein Steuersignal in diesen "wrapper". In diesen verilog module sieht der code dann in etwa so aus: (ohne Erfolgsgarantie, keine Ahnung ob der Isim das kann) [verilog] assign datenbus_zum_sdramacces = rdata; assign rdata = steuersignal ? datenbus_vom_sdramaccess : 8'bzzzz_zzzz; [/verilog]
@bko >> Note Connection to bi-directional pass switches in Verilog are not >>supported. >- geht dies so nicht mit dem ISim. Ok. Das erklärt warum da immer nur Z bei rauskommt. Ich versuch es dann vllt doch mal mit Modelsim. >Außerdem kann dein Code so nicht synthetisert werden Also bisher hab ich das immer Synthetisieren können. Ich meine wie würde man denn sonst ein externes RAM mit einem bidirektionalen Datenbus anbinden können ? Würde ja sonst per se nicht funktionieren. Und rdata ist in dem falle ja kein Flip-Flop. Sondern eher ein bidirektionales Latch (ähnlich einem 74245, nur mit FlipFlops in der einen Richtung und einem Tri-State-Ausgang). Danke noch für den Tip mit dem Wrapper, aber dazu müsste ich ja in das SDRAM-Model eingreifen (da von dem Model der bidirektionale Bus aus gesteuert wird) und das möchte ich eigentlich nicht.
bko schrieb: > Ich versuch es dann > vllt doch mal mit Modelsim. Da wirst du auch Pech haben. Die XE und Starter versionen unterstützen mixed language (VHDL + Verilog) nicht. Vielleicht hilft ein Memory Modell von der FMF.
@klaus Erstmal danke für den Hinweis das ich mit Modelsim da auch nicht weiterkomme. @kest Danke dir vielmals für den Hinweis. Ich hatte es zwar gelesen gehabt das du das Simulationsfile mit drin hattest, aber mir noch nicht weiter angeschaut (dann wär mir aufgefallen das es in VHDL ist). Es ist ja gestern erst "herausgekommen" das ich mixed-language nicht so simulieren kann wie ich es brauche. Von daher hatte ich auch an deinen Kommentar mit dem Simulationsfile nicht mehr gedacht. Das VHDL-File kommt mir also gerade recht. Vielen vielen Dank noch für deinen Post und das File. Werde das heute abend direkt mal ausprobieren. Hoffe mal das es sich so durchsimulieren lässt. Kann ja nicht soo schwer sein eigentlich (DDR-RAM stell ich mir deutlich schwieriger vor).
@klaus falser >Vielleicht hilft ein Memory Modell von der FMF. Was mir noch einfällt ... Wäre es möglich statt dem Verilog-Modell das IBIS Modell zu verwenden, oder wird IBIS von ISIM ebenfalls nicht unterstützt ? Ich werde zwar vorrangig mit dem VHDL-Model simulieren, aber für spätere Modelle wäre IBIS denke ich nicht schlecht.
IBIS ist zur Simulation von elektrischen Signalen auf dem PCB - nicht zur (funktionalen) Simulation Deines VHDL-Codes
Klaus Falser schrieb: > Die XE und Starter versionen unterstützen mixed language (VHDL + > Verilog) nicht. Seit wann das denn? Ging das nicht früher mal (~ISE9)? Duke
Duke Scarring schrieb: > Klaus Falser schrieb: >> Die XE und Starter versionen unterstützen mixed language (VHDL + >> Verilog) nicht. > > Seit wann das denn? Ging das nicht früher mal (~ISE9)? > > Duke Weiss nicht, die letzte Version scheint's nicht zu können, und beim Versuch hat es auch nicht geklappt. http://www.xilinx.com/support/answers/24506.htm Und bei der Vollversion PE von Mentor braucht man, glaube ich, auch eine eigene Lizenz. Wir haben in der Firma jedenfalls nur VHDL für ModelSim PE.
@duke > Seit wann das denn? Ging das nicht früher mal (~ISE9)? Also mit der ISE 9.1 gehts wohl nicht, weil mit der Version hab ich ja das Problem. Müsste also ne vorherige Version sein in der das geht. Schade eig. das das nicht hinhaut. Wär schön gewesen wenn ich "einfach mal eben" das Verilog-Model und meine VHDL-Statemachine zusammen durchsimulieren könnte. Na ja. Vllt klappts ja mit dem VHDL Model des SDRAMs von kest.
@Kest Erstmal vielen vielen Dank für das VHDL-Model. Es lässt sich nun simulieren so das der DQ-Bus auch andere Zustände als Z einnimmt. Es sind sogar die erwünschten Zustände :-)) Allerdings gibt es noch einen Wermutstropfen ... Das Model meldet mir immer Timing-Violations. Egal ob ich den SDRAM-Clock invertiere oder nicht. Und es scheint so zu sein das der SDRAM-Output einen Takt zu früh ist. Jedenfalls kommt es mir etwas merkwürdig vor das das Datenwort schon nach ca 1.5. Takten anliegt und kurz (ca 3 ns) nach der 2 positiven Flanke nach dem Read wieder verschwindet (d.h. Z wird). Wäre ja eig. auch richtig, nur eben einen halben Takt später. Wenn ich die Statemachine nun synthetisiere und mit dem SDRAM verbinde so muß ich die Daten einen Takt später übernehmen als in der Simulation, sonst liegen die Daten nicht stabil an (Bits können kippen wenn ich diesselbe Speicherzelle mehrmals auslese). Übernehme ich die Daten einen Takt später (in Zustand 0x35) lese ich immer denselben Wert aus (den ich natürlich auch verändern kann). Ich habe zwar mit der Hardware noch ein anderes Problem, und zwar das nur jedes 2 Bit meines Datenwortes geändert wird (wenn ich 0xff schreibe, lese ich 0x55 zurück), aber das kann daran liegen das ich vergessen habe 100us zu warten. Und 5 us sind nunmal ungleich 100us. Vllt ist es aber noch ein anderes Problem. Jedenfalls funktioniert es vom Prinzip her schonmal. Daher nochmals vielen dank an alle die mir dabei geholfen haben.
So. Es läuft nun so wie es soll. Das Problem das nur jedes zweite Bit gelesen wurde habe ich auch identifiziert. Es liegt am DAB ... !!!! Dämlichster Angenommener Benutzer !!!! Man sollte auch den richtigen Baustein einlöten, und nicht den falschen. Statt eines MT48LC8M16 habe ich einen MT48LC16M8 eingebaut der natürlich nur 8 Bit breit ist. Einen 16 Bit Datenwort einzulesen macht da wenig Sinn. Ich könnt mich sowas von beißen ... Jedenfalls kann ich mit dem Fehlenden Baustein eine Burstlänge von 2 ausprobieren. Trotzdem könnt ich mich beißen .... fluch, schrei, verwünsch, selbst-verhau ....
>Dann löt ihn halt wieder aus ;)
Ich hab den Ersatz-typen (bzw richtigen Typen) noch nicht da. Aber so
kann ich wenigstens mit dem Burst-Mode was rumspielen :-) Man muß nur
das gute sehen in den Fehlern die man macht ;-P
@Kest Nachdem mit dein VHDL-Modell weitergeholfen hat wende ich mich nochmals an dich. Wo hast du dieses Modell her ? Ich bräuchte es nochmal, allerdings in 16Meg x 8Bit, da ich den 8Meg x 16Bit noch nicht habe, und ich nicht weiterkomme, da ich den 16M8 Typen nicht durchsimulieren kann (eben weil mir dieses Modell fehlt, und ich erstmal nicht das Modell anpassen möchte, einfach um zusätzliche Fehler zu vermeiden). Kannst du mir da evtl. nochmal weiterhelfen ?
Hallo Rene, die vhdl-Datei habe ich damals von Micron-Seite heruntergeladen. Ich glaube mittlerweile gibt es keine mehr/ oder höchstens in Verilog. Anbei ein Archiv von Hynix mit dem 16M8 SDRAM-Model. Grüße, Kest
Danke dir vielmals Kest. Ich denke mal damit komm ich weiter. Schade eig. das die VHDL-Modelle irgendwie aus der Mode gekommen sind. Und noch schadererer das Mixed-Language VHDL/Verilog unter ISE so problematisch ist (zumindest wenns um die bidirektionalen Ports geht)
Rene Böllhoff schrieb: > Schade eig. das die VHDL-Modelle irgendwie aus der Mode gekommen > sind. Und noch schadererer das Mixed-Language VHDL/Verilog unter ISE > so problematisch ist (zumindest wenns um die bidirektionalen Ports > geht) Das hat aber nicht unbedingt was mit ISE zu tun, sondern damit, dass VHDL bestimmte Eigenschaften von Verilog nicht modellieren kann. Mit Questa (ModelSim) kommt man da auch nur bedingt weiter. -- Marcus
nee, stimmt nicht ganz, der "modelsim" kann das, habe schon selbst damit solche Datenbusse über verilog/VHDL hinweg simuliert. Allerdings kostet die VHDL/verilog Lizenz so mindestens 5 stellige (Dollar) Summe :-(
bko schrieb: > nee, stimmt nicht ganz, der "modelsim" kann das, > habe schon selbst damit solche Datenbusse über > verilog/VHDL hinweg simuliert. Ich habe ja auch nicht gesagt dass es gar nicht geht. Man muss nur bestimmte Bedingungen einhalten. Daher geht es nur "bedingt" ;-) Siehe Abschnitt "Modules with Bidirectional Pass Switches" im Handbuch. -- Marcus
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.