www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik DRAM am Prozessor


Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich möchte meine Prozessoren gerne mit noch mehr RAM ausrüsten (bis 
ejtzt max. 1 MB SRAM).
Bei RAM von einigen MB bis zu GB verwendet man ja DRAM. Ich hab da ein 
paar nette DRAM-Chips rumliegen, z.B.  IS42S16160B und andere, bis zu 
256 MBit.
Die Frage ist nun, wie man sowas an einen Prozessor anschliessen kann. 
Bei 8051 oder so ist das ja möglich, dank dem ALE-Signal, wodurch man 
einen CBR-Refresh automatisch durchführen kann.
Das Problem ist aber, dass mein Prozessor nur bedingt solche 
Timingsignale zur Verfügung stellt. Wie kann man DRAM beschalten, wenn 
man nur einen Adress- und einen Datenbus hat sowie RD und WR? geht das 
überhaupt? Müsste man evtl etwas mit einem FPGA deichseln (was ich bis 
jetzt noch nicht versucht habe, ein Experimentierboard ist aber in 
Entwicklung)?
Mich würde insbesondere die Verwendung von DRAM mit einem 68k 
interessieren (68000 und '332). Gut wäre natürlich, wenns eine Schaltung 
ist, die hardwaremässig den Refresh selber vornimmt, sodass ich von der 
Prozessorseite her keinen Unterschied zwischen SRAM und DRAM merke.
Ich bin sicher nicht der erste der sowas versucht, aber Google liefert 
keine wirklich brauchbaren Resultate.
Weiss jemand von euch genaueres?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias Plüss wrote:
> Bei RAM von einigen MB bis zu GB verwendet man ja DRAM. Ich hab da ein
> paar nette DRAM-Chips rumliegen, z.B.  IS42S16160B und andere, bis zu
> 256 MBit.

Das dürften dann aber SDRAMs sein. Ohne passenden Controller in einem 
FPGA/CPLD kann man die nicht verwenden.

> Das Problem ist aber, dass mein Prozessor nur bedingt solche
> Timingsignale zur Verfügung stellt. Wie kann man DRAM beschalten, wenn
> man nur einen Adress- und einen Datenbus hat sowie RD und WR? geht das
> überhaupt?

Mann kann das ALE Signal zweckentfremden, um die Zeilen/Spaltenadresse 
zu multiplexen. Ist etwas timingkritisch, funktioniert aber. Ist aber 
erstmal ziemliche Bastelei.

> Müsste man evtl etwas mit einem FPGA deichseln (was ich bis
> jetzt noch nicht versucht habe, ein Experimentierboard ist aber in
> Entwicklung)?

Könnte gehen. Das Problem dabei ist nur, dass der DRAM nur im Pagemode 
schnell ist. Da der DRAM Controller aber nicht weiß, wann der µC das 
nächste mal auf den Speicher zugreift, und was er liest, dann kann es 
Timingprobleme geben, wenn z.B. gerade ein Refresh durchgeführt wird.

> Ich bin sicher nicht der erste der sowas versucht, aber Google liefert
> keine wirklich brauchbaren Resultate.
> Weiss jemand von euch genaueres?

Es ist alles andere als einfach, vor allem wenn der µC wirklich 
garnichts mitbekommen soll, also nur ein großes SRAM sieht.

Schau mal auf diese Seite, da wurde sowas in der Art gemacht:
http://www.pjrc.com/tech/mp3/

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke erstmal.
Also geht das so, wie ich mir das vorstelle überhaupt nicht?
Wie wird das im PC gelöst? Dort ist ja auch DRAM im einsatz (und ja, 
klar meinte ich SDRAM :D).
Für den Controller brauchts also nicht extra einen FPGA. Reicht 
womöglich ein CPLD mit 64 Macrocells? Solche hab ich hier nämlich noch 
rumliegen.

Zumindest der CBR-Refresh erscheint mir ziemlich Simpel. Dort muss ja 
nur CAS vor RAS aktiviert werden, und intern wird dann irgend ein Zähler 
aktiviert, der automatisch Refresh-Adressen bildet. Kann man evtl. damit 
was machen? z.B. einen kleinen Controller, der immer, wenn der Bus nicht 
verwendet wird, erst CAS und dann RAS auf low legt? Oder ist das 
völliger Quark?

Danke noch für den Link.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Tobias Plüss (hubertus)

>Also geht das so, wie ich mir das vorstelle überhaupt nicht?

Der Aufwand ist imens und das Ergebnis nicht wert.

>Wie wird das im PC gelöst? Dort ist ja auch DRAM im einsatz (und ja,
>klar meinte ich SDRAM :D).

Schon mal in einen PC reiungeshaut? Da sind neben dem Prozessor noch 
einge, grosse, sehr leistungsfähige ICs drauf, Chipsatz genannt. Die 
machen das.

>Für den Controller brauchts also nicht extra einen FPGA. Reicht
>womöglich ein CPLD mit 64 Macrocells? Solche hab ich hier nämlich noch
>rumliegen.

Maybe.

>Zumindest der CBR-Refresh erscheint mir ziemlich Simpel. Dort muss ja
>nur CAS vor RAS aktiviert werden, und intern wird dann irgend ein Zähler
>aktiviert, der automatisch Refresh-Adressen bildet. Kann man evtl. damit
>was machen? z.B. einen kleinen Controller, der immer, wenn der Bus nicht
>verwendet wird, erst CAS und dann RAS auf low legt? Oder ist das
>völliger Quark?

Relativ. Das Problem ist vor allem auch, dass der Bus von deinem 68K 
nicht auf DRAm ausgelegt ist, sondern auf SRAM. Den kann man reltive 
einfach ansprechen, und auch jede Sdresse direkt. Bei DRAm ist das ncht 
der Fall, u.a. wegn des gemultiplexten Adressbusses. Ein DRAM-Controller 
müsste nu auf der einen Seite sich so wie ein normaler SRAM verhalten, 
auf der anderen aner de Zugriff auf einen DRAM umbiegen. Alles zeimlich 
umständlich.

Wenn du ordentlich RAM braucht/willst, investier ein paar Euro und kauf 
dir SRAM und gut.

MFG
Falk

Autor: Dominic R. (dominic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wie wird das im PC gelöst? Dort ist ja auch DRAM im einsatz (und ja,
> klar meinte ich SDRAM :D).
> Für den Controller brauchts also nicht extra einen FPGA.

Wie Falk schon angemerkt hat -> Chipsatz. Bei AMD steckt der 
Speichercontroller allerdings seit K8 direkt im Prozessor - und der hat 
mit seinen zig Millionen bis hunderten Millionen Transistoren mehr Logik 
als jeder FPGA...

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im PC werden doch die Befehle in den Cache geladen, und von dort 
ausgeführt, wobei der Cache wieder Sram ist ...

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Hauke Radtki (lafkaschar)

>Im PC werden doch die Befehle in den Cache geladen, und von dort
>ausgeführt,

Im cache wird gar nichts ausgeführt, nur zwischengespeichert.

> wobei der Cache wieder Sram ist ...

wohl war.

MFG
Falk

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
> @ Hauke Radtki (lafkaschar)
>
>>Im PC werden doch die Befehle in den Cache geladen, und von dort
>>ausgeführt,
>
> Im cache wird gar nichts ausgeführt, nur zwischengespeichert.
>
>> wobei der Cache wieder Sram ist ...
>
> wohl war.
>
> MFG
> Falk

Ist da aber auch im Prozessor drinne ;)
Wobei ich mir überlegt hab, ob man überhaupt SRAM braucht für sowas?
Weil die Daten ja eh nach einiger Zeit "verfallen" könnte man das ja 
auch durch auslassen der Refreshcycles machen :P
(Hab mal gelesen das drams auh ein bsi 2 sek ohne refresh die Daten noch 
halten)

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay danke für eure Auskünfte.
Somit wird das wohl nichts - DRAM-Controller selber bauen ist zu 
kompliziert, wenn nicht gar unmöglich.
Bleibe ich halt bei meinen SRAM ;)
Das einzig unschöne daran ist halt, dass man ziemlich viele Chips 
braucht, wenn man sagen wir mal 4 MB RAM realisieren will. Das sind dann 
halt 8 512k x 8 RAMs. Und grössere SRAM habe ich keine gefunden, welche 
auch noch bezahlbar wären.

Grüsse
   Tobias

Autor: Micro Mann (micromann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Billiger ist es sicherlich einen Prozessor mit SD-Interface zu 
verwenden, als einen 8051 mit viel SRAM auszustatten ...

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wobei ich mir überlegt hab, ob man überhaupt SRAM braucht für sowas?

Ja.

> Weil die Daten ja eh nach einiger Zeit "verfallen" könnte man das ja
> auch durch auslassen der Refreshcycles machen :P

Du weißt aber nicht, wann sie verfallen. Außerdem muß, sofern man 
write-back-Cache hat, der Cache-Controller tunlichst darauf achten, daß 
alles rechtzeitig in den Hauptspeicher geschrieben wird.

> Hab mal gelesen das drams auh ein bsi 2 sek ohne refresh die Daten noch
> halten)

Nach dieser Zeit können Fragmente noch erhalten sein, ja. Zuverlässig 
ist das aber nicht.

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Irgendwer hat hier im Forum mal ne nette Grafik gepostet, die 
"Datenverfallsrate" im bezug zur Temperatur. Bei 25° halten die Daten 
manchmal mehrere 10 sek. Bei höheren temperaturen eben viel weniger.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hauke Radtki wrote:
> Irgendwer hat hier im Forum mal ne nette Grafik gepostet, die
> "Datenverfallsrate" im bezug zur Temperatur.

Das war ich (in der Codesammlung unter 2MB DRAM an AVR):
http://www.mikrocontroller.net/attachment/21296/dr...

Autor: WhAT DOTh LOVE BE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein DRAM-zu-SRAM-Converter wäre doch eigentlich eine Marktlücke. Hat das 
noch keiner erfunden?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Doch, das gab es vor sehr vielen Jahren. Nur ist das Verhältnis 
Aufwand/Nutzen anscheinend zu gering (hoher Aufwand.)

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

Bewertung
0 lesenswert
nicht lesenswert
Am besten nimmst du einen ARM Prozessor von ATMEL

z.B. den Type AT91SAM7SE512

der hat ein SD-RAM Interface mit eingebaut.
Da ist das anschliessen von SD-RAM so einfach wie das anschliessen von 
SRAM.

Ich habe damit ein Board aufgebaut und es funktioniert einwandfrei.

Du hast bei diesem Prozessor auch den Vorteil das er das RAM linear 
addressieren kann.

Wuerdes du auf einem 8051 soviel RAM zu verfuegung haben muesstes du da 
eine Speicherverwaltung (Banking) programmieren.

Gruss Helmi

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie kommt ihr auch immer auf den Vergleich mit dem 8051?
8051 kann ja max. 64k Speicher adressieren.
Nee, das ist mir definitiv zu popelig. Wenn ich mal was grösseres machen 
will, muss man da nur umständlich Bank switching basteln. 68k ist mir da 
schon lieber; ist zwar total kompliziert, aber halt auch linearer 
Adressraum und die kleinste Ausführung kann immerhin 16M x 16 
adressieren, was eigentlich genügen sollte. Wird aber schwer, 16M mit 
SRAM zu realisieren ;)

Aber danke für die Schaltung Helmi. Ich wollte mich sowieso auch mal dem 
ARM widmen.

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

Bewertung
0 lesenswert
nicht lesenswert
Falls es dich interisiert:
Hier noch der Ethernetteil davon.

Gruss Helmi

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habe auch mal eine frage zum refresh.

ich möchte auch gerne ein SIMM ram nutzen und denke ich werde 
(anfänglich) einen cbr refresh machen. jetzt hab ich in div. beispielen 
gesehen das dieser refresh ca. alle 4ms 1024 mal hintereinander 
ausgeführt wird.
das unschöne ist das man den refresh 1024 hintereinander ausführt und 
der uC während der zeit brach liegt. kann man den cbr nicht einfach 
öfter aber dafür eben nicht 1024 mal hintereinander ausführen. z.b. nur 
64 mal und dafür alle 250us zu machen, sodass man in der summe auch auf 
1024 cbr impulse in 4ms kommt, oder erwarten die chips das der cbr 1024 
hintereinander kommt ? sollte doch auch so machbar sein oder ? immerhin 
wird beim zyklischen mit hidden ras refresh ja auch das ganze ram 
refreshed.

gruß
rene

Autor: Condi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm doch ne Festplatte, da hast du genug Speicher.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
TheMason wrote:
>  kann man den cbr nicht einfach
> öfter aber dafür eben nicht 1024 mal hintereinander ausführen. z.b. nur
> 64 mal und dafür alle 250us zu machen, sodass man in der summe auch auf
> 1024 cbr impulse in 4ms kommt

Ja, das geht auch. Das nennt sich dann distributed refresh, während das 
andere burst refresh genannt wird.
Im Prinzip ist beides gleichwertig, softwaremäßig ist der Burst Refresh 
etwas effizienter, da der Overhead (Interrupteintritt usw.) seltener 
gemacht wird.

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@benedikt

danke für den hinweis. hatte schon so ein gefühl das das mit distributed 
refresh gemeint sein könnte. :-)
das es etwas ineffizienter ist stört mich nicht sonderlich.
mir geht es darum das der uC nicht während der 1024 cbr-toggeleien 
steht. das dauert eben seine zeit und blockiert alles andere.
eine weitere idee die ich damit verfolge ist das ich bei einem clpd/fpga 
eine statemachine baue die im idle-state das dram permanent refresht und 
nur wenn sie was zu tun bekommt lese oder schreib-operationen ausführt.

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]
  • [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.