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/dram_norefr.gif
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.)
Angehängte Dateien:
-
at91.png
66 KB
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.
Angehängte Dateien:
-
armcpu2.png
42 KB
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
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.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.