SDRAM-Baustein untertakten?

[Sven B. (scummos)]

Hallo!

Ist es möglich, einen SDRAM-Baustein, zum Beispiel [1], z.B. bei einem 
Drittel der Taktfrequenz zu betreiben (z.B. 50MHz) oder kommen die dann 
durcheinander (Refresh und so)? Im Datenblatt ist nur eine Minimalzeit 
für die Clock-Cycles angegeben (aber kein Maximum).

Grüße,
Sven

____
[1] http://www.farnell.com/datasheets/1605256.pdf

[Michael (Gast)]

Haha du bist geil !

Natürlich geht das.

[Sven B. (scummos)]

So unsinnig finde ich die Frage nicht. Immerhin könnte es zum Beispiel 
sein, dass die Refresh-Logik auf einen Takt von 100MHz ausgelegt ist, 
und wenn der tatsächliche Takt deutlich geringer ist, ist die 
Refresh-Rate für die Speicherzellen zu klein. Bist du sicher, dass das 
nicht der Fall ist? Steht das irgendwo, oder hast Du es schon 
ausprobiert? ;)

Grüße,
Sven

[Refresh (Gast)]

Sven B. schrieb:
> Im Datenblatt ist nur eine Minimalzeit
> für die Clock-Cycles angegeben (aber kein Maximum).

Datenblatt wirklich lesen, hilft oft weiter:

Seite 1:
• Refresh
– 64ms, 4,096-cycle refresh (15.6μs/row)
(commercial, industrial)
– 16ms, 4,096-cycle refresh (3.9μs/row)
(automotive)

soll heißen:
mindestens aller 64ms 4096 Refresh-Zyklen (oder aller 15µs ein 
Refresh-Zyklus)
--> grob geschätzt läuft das auch noch mit MHz-Takt

Detaillierte Erläuterungen einschliesslich Taktschemata finden sich im 
Datenblatt unter "Refresh"

Gruß

Jörg

[Sven B. (scummos)]

Ja, aber die Frage, die ich nicht beantworten kann, ist: "Woher nimmt 
der Baustein die Information, dass 15us vergangen sind?" ;)

[Georg A. (georga)]

Gar nicht. Der Hersteller sagt, dass eine Zeile den Inhalt maximal 64ms 
ohne Refresh sicher hält. Wenn es 4096 Zeilen gibt, gibt das eben einen 
mittleren Refreshabstand von 15us. Du kannst die Refreshs natürlich auch 
im Burst machen (dürfte so 250us dauern). Dummerweise will die CPU aber 
auch noch zugreifen, deshalb ist das mit dem Burst eher unpraktisch :)

Nett ist, dass die Gesamtrefreshzeit trotz immer kleinerer Kapazitäten 
auch immer so gestiegen ist, dass pro Zeile 15us rauskommen, und das so 
grob seit 1980...

[Michael A. (Gast)]

Georg A. schrieb:
> Nett ist, dass die Gesamtrefreshzeit trotz immer kleinerer Kapazitäten
> auch immer so gestiegen ist, dass pro Zeile 15us rauskommen, und das so
> grob seit 1980...

Das liegt daran, dass der gleiche Mechanismus, der die Kapazität 
verkleinert, in sehr ähnlichem Maße auch die parasitäre Leitfähigkeit 
verkleinert - nämlich die Strukturgroße ;-)

[(prx) A. K. (prx)]

Andersrum gesehen: Wenn die Refresh-Zeit mit der Kapazität gesunken 
wäre, dann würde der Speicher heute nur noch mit Refresh beschäftigt 
sein, ohne nennenswert Zeit für den Zugriff zu haben. So entschlossen 
sie sich schweren Herzens, die Parameter entsprechend beizubehalten.

[Sven B. (scummos)]

Ah, ich sehe das Missverständnis: Ich dachte, "Auto Refresh" bedeutet, 
dass der Chip die Zeitpunkte für den Refresh selbst wählt. Ist aber gar 
nicht so. Dann ist mir das klar. Danke!

Grüße,
Sven

[Georg A. (georga)]

Das Auto bezieht sich in dem Fall auf das eigene Weiterzählen der 
Refresh(Row)-Addresse. "Früher" musste der Speichercontroller das 
machen, also  RAS+explizite Row-Adresse und dann die Zeile ohne CAS 
gleich wieder schliessen.

Ein "Auto" im Sinne von "das RAM macht alles selbst" heisst Self-Refresh 
(o.ä.)  und das ist ein besonderer Betriebszustand, den man auch erst 
setzen bzw. verlassen muss. In dem gehen dann keine CPU-Zugriffe mehr. 
Das ist dann zB. das, was im "Suspend-to-RAM" benutzt wird.

[Sven B. (scummos)]

Danke für die Erläuterung, war interessant.