www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Frage zu SDRAM


Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Flint (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Andreas Bergmann (Firma: www.collion.de) (bergy) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Xenu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/applic...


Und fertig bekommst Du einen von Altera (auch für Nicht-Altera-FPGAs
verwendbar):

http://www.altera.com/products/ip/altera/ocore_sdr...

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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/sdr...

Autor: Xenu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 :-)

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Klaus Falser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bekommt man solche Modell auf der Internetseite von Micron?

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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).

Autor: Rene B. (themason) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rene B. (themason) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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) ?

Autor: Kest (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Duke

Ich hab kein Modelsim bei mir laufen. Nur den ISIM. Und für die meisten 
Zwecke reicht es ja auch aus.

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann mir denn da niemand behilflich sein ?
Ich meine vom Timing-Diagramm her siehts ja gut aus.

Autor: bko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_man...
(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:
  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]

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein VHDL-Model eines Speichers ist im Archiv, den ich weiter oben 
gepostet habe.

Grüße,
Kest

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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).

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: mfgJF (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
IBIS ist zur Simulation von elektrischen Signalen auf dem PCB - nicht
zur (funktionalen) Simulation Deines VHDL-Codes

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ....

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann löt ihn halt wieder aus ;)

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 ?

Autor: Kest (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: bko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-(

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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