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?

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/

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.

@ 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

> 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...

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

@ 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

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)

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

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

> 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.

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.

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...

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

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

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

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.

Falls es dich interisiert:
Hier noch der Ethernetteil davon.

Gruss Helmi

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

Nimm doch ne Festplatte, da hast du genug Speicher.

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.

@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.