Wie kann ich ein DRAM o. SDRAM mit einen Spartan 2 betreiben

Zum basteln kaufe Dir lieber ein Evaluationboard und fange "klein" an.

Gruß Henning

Für die Anwendung bringt FPGA wenig.

Kurz skizziert:

Einige Steuerleitungen nicht eingezeichnet. Von links kommt das Target rein, die Treiber sind z.B. 74HCT244 oder moderner. Der 8 Bit Controller in DIL40 hat normalerweise nur mehrere 8 Bit Ports. Mit denen kann man aber mit ca. 3 externen Registern ( z.B. 74HC374) für die Adressleitungen einen Mikroprozessorbus simulieren. Damit kann er aufs SRAM zugreifen. Die Treiber fürs Target müssen derweil tristate geschaltet sein.

Im Grundausbau müsste man nur 1M x 8 ( fürs SRAM ) adressieren können. Wenn man aber 2Mx8 adressieren kann, kann man unten SRAM und oben EPROM in der simulierten externen Memorymap des 8 Bit Controllers haben. Dann kann er vom EPROM ins SRAM Byte für Byte die Daten kopieren. Genau wie Speicherverschiebung in normalem Mikroprozessor.

MfG JRD

Danke f=FCr die Skizze.

Sieht interessant aus. Also wenn ich das richtig versteht wird der Adress - und Datenbus eigentlich gemultiplext. Also das Zielsystem und der uC Teile sich das SRAM. W=E4hrend der uC auf das SRAM zugreift ist der Ausgangswert f=FCr das Target in einem Latch gespeichert ?

Die Zugriffszeit vom SRAM muss einfach sehr schnell sein. Wie schnell m=FCsste dann das SRAM sein? w=FCrden 20ns reichen wenn das Zielsystem ein 50ns EPROM h=E4tte ?

Ein AVR mit 16 MHz braucht f=FCr einen Takt 62.5ns und w=FCrde somit nicht ausreichen.

Hast du dies schon mal umgesetzt ?

Er würde voll ausreichen: das Ding ist kein "Dualport-RAM" sondern ein "EPROM-Simulator". Es gibt zwei Betriebsphasen:

• Schreiben des RAM durch den Controller. Das kann beliebig langsam sein, wird nur durch die Geduld des Benutzers begrenzt. In dieser Zeit funktioniert das Zielsystem nicht, muß z.B. durch Reset angehalten werden. Danach wird Betriebsart umgeschaltet. Es folgt:

• Lesen des RAMs durchs Zielsystem. In dieser Zeit tut der Controller nichts. Kann man in power-down schalten.

Anzunehmen: das RAM plus Verzögerung der Treiber ( Nennwert für 74HC244 wäre 14nsec ) soll kleiner 50nsec sein.

MfG JRD

Das Zielsysstem muss aber weiterlaufe. Wir k=F6nnen nicht weil wir einen einzigen Wert ge=E4ndert haben den ganzen Motor abstellen und wieder anwerfen.

Das w=E4re viel zu aufwenig. Deshalb muss die =C4nderung in Echtzeit passieren. Das ist ebe das aufwendige. Nach einem Reset kann es relativ lange gehen bis der Motor wirder anl=E4uft da vielfach das Ger=E4t initialisiert in dieser Zeit passiert relativ viel.

Wenn man bei laufendem Zielsystem den EPROM-Simulator laden wollte: Einen weiteren Satz EPROMs ( etwas schneller als 50nsec ) mit dem Orginalprogramm in den EPROM-Simulator integrieren. Dieser hängt mit Adreßbus und den meisten Steuerleitungen direkt am Target. Am Datenbus hat er auch 74HC244 Treiber die aktiviert werden, wenn die Verbindung SRAM-auf-Target deaktiviert ist, weil man das RAM durch den Controller lädt. Damit hat das Zielsystem immer einen gültigen Speicher. Das Umschalten zwischen beiden Speicherseiten muß aus Flankenwechsel an Steuerleitungen des Targets gewonnen werden ( d.h. unmittelbar nach Lesezugriff ), damit Umschalten synchron zum Betrieb des Targets erfolgt.

MfG JRD

Rafael Deliano schrieb:

Naja, man beachte die, wenn auch sehr geringe Möglichkeit, dass gerade in dem Moment, wo ein neuer Wert geschrieben wird dieser auch gelesen wird. Da kann ordentlich Datenmüll rauskommen. Wenn da mal der Motor nicht allergisch reagiert.

Klingt brauchbar.

MfG Falk

schrieb im Newsbeitrag news: snipped-for-privacy@h48g2000cwc.googlegroups.com...

Hallo Thomas,

die Lösung parallel zu schreiben ist "einfach", wenn ein Signal vorhanden ist an dem man jeden Lesezugriff einzeln erkennen kann. Dann nimmt RAM das so schnell ist, daß ein Schreibzyklus nur z.B. 15ns benötigt. Entweder ist gerade kein Lesezugriff, dann kommt der Schreibzyklus gleich dran. Falls gerade schon ein Zugriff läuft, dann wird kurz gewartet bis er fertig ist und dann der Schreibzyklus ausgeführt. Das Ganze muß über etwas Zusatzlogik gesteuert werden. Dafür wäre dann ein schnelles CPLD genau das Richtige.

Gruß Helmut

Verzögerung der Treiber hier doppelt.

MfG JRD

Muß vom Controller eine Handshakelogik mit einem externen FlipFlop ( 74HC74 ) rein:

• Controller fordert per Portpin/Output Umschalten an

• FlipFlop kippt wenn Umschalten nach nächstem Lesezugriff von Target tatsächlich erfolgt ist

• Controller pollt über Portpin/Input Zustand des FlipFlops und weiss damit ob er jetzt das RAM hat. Schalten in die andere Richtung ähnlich.

Gehen aber wohl nicht bis 1MByte x 8. Würde man von

aber vermutlich in Kleinmengen bekommen. Allerdings sind die Preise wohl gesalzen und man sollte das Kleingedruckte im Datenblatt lesen.

MfG JRD

Warum dann nicht gleich 2 RAMbänke syncron umschalten? Das ist zwar ein riesen Verdrahtunggsaufwand sollte aber machbar sein. Mit etwas glück lässt sich das umschalten über RD oder CS syncronisieren.

Ich würd zuerst diese 2 Signale ansehen ob nicht doch irgendwann Zeit zum schreiben eines einzelnen RAMs ist.

--
MFG Gernot

Muß man sie zweimal laden. Was ja eigentlich ( ehedem wie heute ) wegen der langen Wartezeit das unangenehme an EPROM-Simulatoren ist. Nur EPROM und ein power-up-reset-IC würde sicherstellen, daß das Target sofort bei Einschalten loslaufen kann. Ich gehe davon aus, dass der EPROM-Simulator aus dem Target versorgt wird.

Zum Laden mit 115kBit/sec per UART: man kann statt der im Controller die meist nicht so schnell ist auch in die Memorymap von EPROPM, SRAM ein UART-IC mit FIFO a la TL16C550 hängen.

Ich kann mich bei 50nsec für keine Spielart von Zeitmultiplex erwärmen: die nötigen Bauteile werden exotisch/teuer, das Entwicklungsrisiko bezüglich Timingproblemen steigt.

MfG JRD