www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik DRAM am AVR: Wie sieht Euer Wunsch-Interface aus?


Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

es gibt hier im Forum ja schon einige Beispiele fuer DRAM am AVR (e.g.
http://www.mikrocontroller.net/forum/read-4-121457.html,
http://www.mikrocontroller.net/forum/read-1-240689.html )
Ich arbeite aber gerade an einem DRAM-Controller (als Vorprojekt fuer
einen SDRAM-Controller) auf CPLD/FPGA Basis. Als Nebenprodukt habe ich
mir gedacht, koennte ich auch eine Version synthetisieren, die man in
eine billige CPLD (<2 Euro) packen kann, um damit Standard (Alt-)PC
SIMM RAM an den AVR anzuschliessen und insbesondere zu entlasten. Nicht
die Rechenleistung fuers Refresh, sondern die Anzahl (eher Unzahl) an
Pins die die Beispiele benoetigen, finde ich verbesserungswuerdig.

Jetzt meine Frage:
Welches Interface waere fuer einen AVR an den DRAM-Controller
zweckmaessig? Die Idee ist, dass diese eine moeglichst geringe
Pin-Anzahl braucht und leicht zu benutzen ist.

Anregungen nehme ich gern entgegen!

Gruesse aus London

Thorsten

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einen Sinn macht ein DRAM nur, wenn dieser folgende Punkte erfüllt:
- Speicher größer als verfügbarer SRAM (also 1MB aufwärts, was bei SIMM
Modulen gegen ist)
- Speicher leicht nutzbar, also entweder linearer Adressraum, oder
unterteilt in viele 32kB Blöcke, mit Mapping im CPLD.
- Möglichst ansteuerbar über XMEM Interface (was Probleme bereiten
könnte, da der AVR keinen Wait Eingang hat)
- Alternative zum XMEM Interface: SPI um möglichst wenige Leitungen zu
verbrauchen. Dies macht aber aufgrund von billig verfügbaren Flash
Speichern mit I2C/SPI wenig Sinn bei Verwendung in Datenloggern.

Das sind zumindest die Punkte, die ich versucht hatte.
Mit einem 8051 und vielen HCMOS ICs ging das auch ganz gut, aber beim
AVR ist das Timing und der ALE Impuls etwas ungünstig: Es ging etwa 1
von 10 SIMM Riegeln.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Statt einem (nicht vorhandenen) Wait-Eingang könnte der CLPD ja buffern
während er gerade refreshed.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Interface ähnlich T6963C wäre auch nicht zu verachten.
Es kann ja zusätzlich auf SPI umschaltbar sein.

Dann noch die Logik für Auto-Increment(/Decrement) mit getrennten
Pointern für Read und Write und schon wäre FIFO-Betrieb oder
Stack-Betrieb (nicht so wichtig wie FIFO) möglich.

Es ist nicht so, dass ich das Teil unbedingt und sofort brauchen würde,
aber wenn schon darüber diskutiert wird, sollte man auch an diesen
Aspekt denken.

Da das Teil eine Platine erfordert, die nicht jeder Bastler mit
Heim-Mitteln realisieren kann, sollte auch daran gedacht werden, dass
man die Platine (vielleicht schon mit CPLD und SIM-Sockel bestückt) zu
einem fairen Preis (fair für beide Seiten) kaufen kann.

...

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hätte ich aufjedenfall auch Spass dran. So richtig toll wirds aber erst
ab 16Mb Speicher :-)

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aber das geht ja leider nich mit dem XMEM Interface :-(

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nunja, für XMEM-Interface sollte auch gleich ein XMEM-fähiger AVR mit
auf das Board. Ansonsten werden das zu viele Strippen...

Ich denke aber, dass an einem eigenständigen (großen) FIFO mehr
Interesse besteht, als an der Nutzung des XMEM-Bereiches. Die meisten
Programmierer hatten noch keinen Mangel an RAM für normalen Zugriff.
Ein großes FIFO (vielleicht mit mehreren Pointerpaaren) schafft aber
völlig neue Perspektiven (Logik-Analyzer, schneller Datenlogger...).

Die Initialisierung der Pointer (vielleicht sind ja auch mehrere
Pointerpaare möglich?) und deren Bereiche (Grenzpunkte, falls mehrere
Pointerpaare implementiert sind) kann ja im "Command-Mode" (Pin
"Command/Data") vorgenommen werden, die eigentlichen
Schreib/Lesezugriffe erfolgen dann über OUT/IN am Port und L-Impuls an
/WR und /RD.

Aber die Idee ansich ist schonmal gut. Und die Idee, das vorher zur
Diskussion zu stellen, ist noch besser.

...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Interface ist für mich erstmal völlig nebensächlich.

Was mich brennend interessiert, für welche Anwendungen kann man
überhaupt DRAM sinnvoll benutzen ???

Nur deshalb DRAM an den AVR dranpappen, damit man ihn mal drangepappt
hat, finde ich persönlich völlig witzlos.


Der AVR ist auch ne äußerst ungünstige Wahl, da er nur max 64kB RAM
adressieren kann.

Ich würde mindestens nen 8051-er nehmen, z.B. den P89C669, der kann 8MB
adressieren. Oder gleich nen ARM.


Peter

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die 8051 haben AUCH nur eine 64k adressraum. Also WIE macht der 8MB
linear? GARNICHT. Also wieder der 'alte' trick mit memory banking.
Und dies kann man dann in den CPLD einbauchen um den kompletten DRAM
anzusprechen über XMEM.
Ich erinnere mich an die Z80 maschienen mit 512k Ram, 256k Rom...

  Olaf

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DRAM kann man sinnvoll nutzen, wenn man z.B. Dateisysteme verarbeitet,
z.B. um die FAT Tabelle abzulegen.
Ein ARM ist für einen kleinen mp3 Player etwas oversized, bzw. nicht
ganz so leicht zu verwenden wie ein AVR.

Hier wird z.B. ein normaler 8051 mit >32MB DRAM verwendet, und das
reicht für einen mp3 Player:

http://www.pjrc.com

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Olaf

"Also wieder der 'alte' trick mit memory banking."


Nein !

Der P89C669 hat 8 (2 je Registerbank) 3Byte-Pointer um damit sämtlichen
Speicher linear adressieren zu können (code, idata, xdata).

Von Maxim gibt es den DS80C390 mit 24Bit-Adressen.

Man braucht allerdings einen nicht zu alten Keil C51, der die
24Bit-Adressierung unterstützt.


Peter

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

schonmal vielen Dank fuer die lebendige Diskussion und die
konstruktiven Beitraege.

Eine kurze Zusammenfassung meinerseits:
* Adressierung logisch
1) Adressierung wie XMEM-Interface (bis 64 KiB)
   2 Byte Adresse
2) Adressierung wie XMEM-Interface mit Banking
   2 Byte Adresse und n Bits Bank
3) Adressierung linear:
   2 Byte-Pointer: 64 KiB; 3 Byte-Pointer: bis 16 MiB
4) `Adressierung' als FIFO
   getrennte Pointer fuer Lesen/Schreiben, Auto Increment/Decrement

* Adressierung Hardware:
5) `Viele' Pins: Adress/Datenbus, XMEM, 1), 2), 3) ...
6) SPI/I2C
7) T6963C aehnlich
8) FIFO mit Data/Command, /WR, /WD, Bus

Kurz noch zu meiner Intention: Das boese Wort mit L ist ja schon
gefallen ... Irgendwann (2010?) soll es darauf hinauslaufen. Aber fuer
ein sinnvolles (Vor-)Project mit FPGA/CPLD wollte ich erstmal einen
kleinen unscheinbaren Memorycontroller machen.

zu 1)
Nicht so interessant, da SRAM bis 64 KiB billiger ist, als CPLD +
DRAM.
Quelle: Reichelt:
628128-70 128Ki x 8, 2.20 Euro
CPLD XC 9536XL VQ44: 1.80 Euro

zu 2) Banking
Bei PICs habe ich das Banking gehasst. Der hatte nur 8 Bit (?) Adressen
und auch die Control Register liegen deshalb in verschiedenen Baenken.
Beim Debuggen bin ich fast wahnsinnig geworden.
Wenn man das fuer `Bulk-'RAM (grosse Bereiche, um Daten, z.B.
Messwerte) nutzt, ist es wohl OK.

zu 1), 2) und 3) Timing beim XMEM
Da ist vom Timing schon anspruchsvoll ;-) Bei einem 16 MHz AVR ist die
Zykluszeit 62.5 ns. SIMM aus alten Computern hat ueblicherweise 70 ns
Zugriffszeit, wenn man ROW und COL setzen will. Ist man im Page-Mode
(nur COL veraendern, eine Page ist 256 Byte in einem Modul), dauerts
kuerzer.

@Simon: was hast Du genau gemeint mit
> könnte der CLPD ja buffern während er gerade refreshed.
Bei wirklich wahlfreiem Zugriff auf den gesamten Speicherbereich per
XMEM Interface muss ich jedes Byte binnen 70ns bereitstellen koennen.
Wie kann das Buffern da helfen?

@Benedikt:
Wie hast Du das denn mit den HCMOS ICs gemacht? Bisher hab ich eine
State-Machine, die alle 20 ns den State wechselt und entsprechend das
Timing realisiert (natuerlich in Schritten zu 20, 40, 60 ns: Also: ROW
setzen, RAS, COL setzen, CAS, wait, Byte einlesen. So macht es auch der
SDRAM Controller von Xilinx, app134. Aber da braucht man ja auch eine
Taktquelle 1/20ns).
Kann man das Timing noch anders erzeugen? Mit Gatterlaufzeiten
pfuschen? Das Problem ist ja, dass die Adresse stabil sein muss,
bevor das Adressstrobe kommt => serieller Ablauf, oder nicht?

zu 4)
wo ich ja eigentlich drauf hinaus will ...

zu 5)
Wenn man schon viele Pins am AVR benutzen will/muss, kann man das
Timing auch gleich im AVR machen. So viel kostet das Refresh ja
wirklich nicht. Das einzig schoene waere das XMEM Interface, da es sehr
transparant zu programmieren waere (keine put/gut Routinen). Dann muss
man aber noch einen Port fuers Banking spendieren (weil 64 KiB
uninteressant sind, siehe 1) und das Timing ist nicht ohne.

zu 6)
da schliess ich mich Benedikt an: Flash ist da ne gute Wahl.

zu 7)
Ja, ein brauchbares Interface. Der Adress-/Datenbus spart schonmal
knapp die Haelfte der Pins ein.
Hab sogar mal Code gesehen, bei dem der Grafikspeicher eines Displays
zum (Mess-Daten)-Ablegen genutzt wurde ;-)

zu 8)
Da ist die Frage nach der maximalen Daten-Rate: Wenn man die Row
wechseln will/muss, brauchts etwas laenger, das limitiert die
Datenrate. Ein aynchrones Beschreiben (DRAM buffert in diesem Fall
zwischen, bis Row gewechselt) ist fuer ne kleine CPLD etwas zu viel
glaube ich.

Den Code aus http://www.mikrocontroller.net/forum/read-1-240689.html
habe ich mal um einen `Enhanced-Page-Mode-Write-Cycle' und
`Enhanced-Page-Mode-Read-Cycle' (alle Cols in einer Row in einem
Durchgang lese/schreiben) ergaenzt. Das hab ich aus dem Datenblatt zum
TMS44400. Koennen das eigentlich alle SIMM-Bausteine?

Zur Platine: ich komm an alles dran und koennte da ggf. was fertig
machen. Mit SIMM mein ich die 30 poligen aus 486er Zeiten, ich hoffe
alle anderen auch?

Gruss

Thorsten

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

Bewertung
0 lesenswert
nicht lesenswert
Mein DRAM Interface für den 8051 sieht so auf und funktioniert je nach
DRAM mehr oder weniger gut. Für die RAS\CAS Umschaltung verwende ich
das sowiso schon vorhandene ALE Signal.
IC6 dient als Latch fürs Banking. Insgesamt unterstützt die Schaltung
2MByte, aufgeteilt auf 64 Bänke.
Ich verwende immer die oberen 32kB des Adressraums für den Speicher und
den unteren für I/O (LCD, IDE, Speicher Mapping Register usw.)

Wenn ich mir das AVR Timing anschaue, dann steht das Highbyte der
Adresse schon einen oder einen halben Takt vor Aktivierung des WR\
bzw. RD\ Signals an. Daher hätte man 93ns für einen DRAM Zugriff, was
eigentlich reichen sollte. Falls das nicht reicht, es gibt immer noch
Wait States die man einschalten kann...

Wie willst du das Problem mit dem Refresh lösen ?

>die man in eine billige CPLD (<2 Euro) packen kann

Wo bekommt man einen CPLD für <2€ ? Reichelt hat die Preise für die
Xilinx 5V CPLDs stark erhöht...

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter:
Ok. Da habe ich wohl blödsinn erzählt.
Nun ja ich bin kein fan der 8051 und so nicht mit allen vertraut. Hätte
wohl man die features des P89C669 vorher ansehen sollen. ;)

Olaf

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Benedikt: danke fuer den Plan.
Aber das die Schaltung kann kein RAS und CAS in einem Zyklus, muss also
der Prozessor wieder ran ...

3,3 Volt CPLDs sollten es auch tun ... Fuer die Spartan 3 FPGAs von
Xilinx hab ich schon nachgeguckt: mit richtigen Vorwiderstaenden (zur
Strombegrenzung) akzeptieren die auch 5 Volt Eingang. Der SIMM hat ein
VIH von 2.4 Volt, was auch passt.

Ein Schreiben oder Lesen in einer Row refreshed die ganze Row. Und
sonst muss zwischendurch ein Timer im CPLD ein CBR refresh machen. Die
CPLD koennte an den Takt des uC angschlossen werden. Wie hast Du das
mit dem Refresh beim 8051 gemacht? Muss doch der Prozessor machen?

Gruss

Thorsten

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Refresh habe ich ziemlich trickreich gemacht:
Das Latch IC7A bekommt als Datensignal ein Refresh_Enable\ vom uC.
Da das Latch während der steigenden Flanke speichert, wird der Ausgang
und damit CAS\ Low, während ALE (=RAS\) auf High liegt. So wird ein
CAS before RAS Refresh gestartet. Mit jedem uC Takt wird ein CBR
gemacht. Ist zwar nicht Stromsparend, funktioniert aber. Der uC muss
als aktiv nicht refreshen, sondern er muss den Refresh nur
einschalten.
So ist es dem Benutzer überlassen, wann er den Refresh laufen lässt.

Wie willst du das ganze machen ?
Wenn der CPLD am Refreshen ist, und der uC ein Byte haben möchte ?

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wenn der CPLD am Refreshen ist, und der uC ein Byte haben möchte ?
Hmm, wie macht das denn ein DRAM Controller auf meinem Mainboard? Oder
halt bei den alten 486ern?

Im Zweifel muss der Controller dann den CBR abbrechen, also /CAS und
/RAS high ziehen, Row, RAS, ... normales Spielchen halt.
Wie das Verhalten bei einem abgebrochenen CBR ist, konnte ich aber
nicht finden. Vielleicht korrupiert das die Daten??
Wenn der Read/Write Zyklus fertig ist, kann man mit dem CBR ja
weitermachen, die Refresh-Adresse wird ja im DRAM selbst gespeichert.

Den CBR zu Ende machen geht nicht, da im unguenstigsten Fall der gerade
begonnen wurde und 130 ns braucht. Die maximale Zeit von der ersten
Adresse bis zum Liefern der Daten ist beim XMEM 190 ns. Fuer den
Speicherzugriff sind dann noch 60 ns ueber, zu knapp :-(


Was passiert aber, wenn der uC staendig und immerzu Daten haben will,
so dass der Controller gar nicht zum refreshen kommt? Wie ist sowas bei
nem `richtigen' DRAM Controller geloest?

Schoene Gruesse

Thorsten

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eventuell ein Puffer?

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Simon
Leider versteh ich Deine Idee immer noch nicht ...
Was soll der CPLD denn buffern? Will der uC ein Byte, so ist es
innerhalb von xxx ns faellig. Welches Byte das ist, kann man nicht
vorhersagen. Was soll der Buffer denn buffern? Den ganzen DRAM kann es
ja nicht buffern ...

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh, ans Lesen habe ich garnicht gedacht. Hätte der CLPD das schreiben
nur etwas verzögert, wäre es ja nicht das Problem gewesen.

Hmm..

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und das XMEM-Interface wird wohl mit sowas wie "Busy" nicht umgehen
können...

- Nix iss vollkommen...

...

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir ist noch folgende unsinnige Idee gekommen:
aktuelle Page (16, 32 oder 64KiB) wird in SRAM geladen und wird dort
gelesen/beschrieben. Der DRAM wird im `Hintergrund' nur refreshed.
Beim Page-wechsel wird der aktuelle Inhalt des SRAM in den DRAM (an
entsprechender Stelle kopiert und die neue Page aus dem DRAM in den
SRAM geladen.
--> Dauert zu lange??
[ Nebenrechnung:
64 KiB = 65536 B
Row, Col waehlen und 1 Byte schreiben: 130ns
die naechsten 255 Byte der Row schreiben (`burst'): 255 * 50ns = 12880
ns
das ganze mal 256  Rows: 3330560 ns}
Mal zwei (Schreiben und Lesen) = 6.6 ms???

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie siehts aus, gibt es schon erste Fortschritte ?

Mir ist da noch eine Idee wegen dem Refresh gekommen:
Sobald ALE auf High geht, wird der Refresh unterbrochen, der
Datentransfer ausgeführt und der Refresh fortgesetzt.
Mit einem Wait sollte das Timing auch passen.

Autor: Tassilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
abo

Autor: Der Techniker (_techniker_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Idee gestorben? Oder doch schon realisiert?

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.