Pseudo-SRAM vs. SRAM, refresh, etc.

Ik heb hier twee Toshiba TC518512FL-70 pseudo static ram chips liggen in een laatje, en laat ik nu juist een 4Mbit SRAM nodig hebben.

Maar een pseudo SRAM is dus geen SRAM, hoewel het voordeel "SRAM-eenvoud van interfacing" zou zijn.

Heeft iemand ooit een SRAM gewisseld voor een pseudo-RAM?

De juiste datasheet is niet te vinden, familie echter wel. http://www.datasheetcatalog.org/datasheet/Sharp/mXrwtws.pdf

En een echte Toshiba maar dan 128kWord ipv 512k: http://www.datasheet4u.net/datasheet/T/C/5/TC518128A_Toshiba.pdf.html

Ik moet echt wel statisch kunnen werken, klok stilleggen (of zwaar terugschakelen), en de "self refresh" en "auto refresh" modes begrijp ik eigenlijk niet goed.

Iemand een mening?

Volgens mij heb je 1 extra lijn t.o.v. een SRAM: RFSH. Je moet zorgen voor refresh cycles. Dus 1x in de zoveel tijd aan dat lijntje trekken.

Super low-power wordt dat dus niet.

Is eigenlijk gewoon DRAM, maar dan zonder de gemultiplexte adreslijnen zoals voor DRAMs gebruikelijk...

Moet dus regelmatig een refresh-cycle doen. Wat die refresh modes betreft: in 1 geval geef je aan de chip een signaal 'nu refreshen', en dat doet 'ie dan. In een ander geval kan 'ie bv. intern een refresh cycle doen op het zelfde moment dat je data leest of schrijft. In de regel zal 'ie altijd intern een refresh adres genereren dus interfacing is wel iets simpeler als regulier DRAM.

Ik zie pseudo-SRAMs als: niet de voordelen van SRAM, wel de nadelen van DRAM.

Maw: alleen gebruiken als je er *erg* veel van hebt liggen, er super goedkoop aan kunt komen & de extra benodigde logica geen punt is (bv. als aansturing vanuit een CPLD of FPGA gedaan wordt). In alle andere gevalllen zou ik er vanaf blijven, gezien huidige (lage) prijzen van SRAM chips.

Ehh. Voorbeeldje: Ik wil 32Mbyte RAM aan een FPGA hangen. m.i. is sdram de enige optie: SRAM is veel te veel chippies.

Bedankt voor de antwoorden.

Ik wou het als videogeheugen gebruiken, en het probleem met video is dat je niet zoveel tijd hebt om te refreshen, behalve in mijn geval misschien tijdens de verticale sync. De glue logica is beperkt, en niet van het programmeerbare soort, dus complexiteit is belangrijk.

SRAM opties blijken toch niet zo abundant als ik gedacht had, ik heb minstens 4Mbit nodig, en liefst een veelvoud ervan omdat ik dan wat meer pages heb. Dan heb je niet veel SRAM opties, en goedkoop zijn ze nog minder. Ook zoals REW zegt, in de megabytes zit je met een aantal chips.

Het blijkt dat videogeheugen best dynamisch gebouwd wordt, ondanks de extra complexiteit.

Ik ben nu even een andere truuk aan het proberen: een paar supersnelle SPI SRAMs (!) die ik volgas parallel leegklok - dit zou best kunnen werken. Ik heb het nog niet gebouwd, maar de componenten heb ik al binnen. Het komt er nog van!

Op 23 september 2011 08:49:42 schreef rew:
Ehh. Voorbeeldje: Ik wil 32Mbyte RAM aan een FPGA hangen. m.i. is sdram de enige optie: SRAM is veel te veel chippies.

Tenzij je bereid bent BGA te gebruiken. http://www.cypress.com/?mpn=CY7C1512KV18-250BZI is een sram van 18MByte. Ook een stuk sneller dan de meeste sdram. Wel wat duurder...

Op 23 september 2011 17:50:44 schreef Bert_mc:

Ik wou het als videogeheugen gebruiken, en het probleem met video is dat je niet zoveel tijd hebt om te refreshen, behalve in mijn geval misschien tijdens de verticale sync.

Alle dynamische ram die ik ooit gezien heb mag je in bursts refreshen. De enige eis is dat je bijv. 8192 refreshes doet per 18ms. Dus je mag alles refreshen tijdens je vsync mits die vaak genoeg komt.

[Bericht gewijzigd door blurp op (38%)]

Als je het voor video gebruikt,zorgt het scannen van de data vanzelf voor de refresh,moet je wel zorgen da de rows/cols van het geheugen juist zijn aangesloten.

Als je het ganse geheugen "leeg" leest iedere keer, ja, maar als je meer dan 1 pagina hebt moet je toch een manuele refresh doen voor het niet aangesproken blok.