Dynamic Rams : Do all the refresh possibilities have to counted through ?

Toby Seckshund

I am pondering on trying some dynamics, instead of the usuall statics.

It has been years since I touched any of them, and back then there were only 7 or 8 address pins to worry about, so refresh (on a Z80) was not a problem. The modern sort have vastly greater capacity and so more refresh cycles to get through.

Does anybody know if it is permissable to only partially refresh ? If I were only to want say 64KB and only cycled through 8 bits for the refreshing (and left the other, unused areas, to fade away) would it upset the wanted areas ??

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point

jazzed

The idea of refresh has advanced a little since the z80 days [noparse];)[/noparse] Read here: en.wikipedia.org/wiki/SDRAM

Toby Seckshund

I was scanning through tha artical last night, and hoped that it was for the mass storage types destined for PCs. Farnell do not do any of the "old" sort.

I wanted to try using a DRAM of the DracBlade and spoof two of the latches with the /ras and /cas signals. I have some hm514400 chips but they are 1Mx4bits so two would be needed (or some shifting).
At least they seem to have the "old" ways about them. I saw that Jesper used simular ones on an AVR (sorry for swearing)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point

AntoineDoinel

Hi

I've done some tests with an old·1MB 30pin SIMM, FastPage type, 70ns access time.

I've got 26 of those for some $8 from e-bay, so while waiting for RamBlade to arrive it seemed a good idea to me

Fewer pin count·it's possible: 10 address lines to access 1MB (it's kinda like having the '373·latch embedded).
It's not possible to go further reduce pins by sharing address and data lines without modification to the memory module, as all SIMM30 unfortunately have /OE permanently tied low.

As expected, access is trickier and slower than SRAM,·but still not so bad:

SPIN loop calling PASM ReadByte/WriteByte: approx.·37 KByte/sec (most overhead in SPIN->PASM call)
SPIN loop calling PASM ReadPage/WritePage: approx. 1.2 MByte/sec (pages of 256 bytes read in fast page mode)

Interrupting everything to make a bunch of refreshes every few msecs seems the preferred way on the net with PICs and AVRs, but I don't think it's pratical to do without a real interrupt or·task scheduler. Instead I used a single·CBR refresh cycle in the PASM loop that awaits for command from the SPIN program, which leads to latency and higher access time for single byte ops, but it's acceptable·if accessing DRAM in·256-byte pages.

There has been some discussion about caching XMM in HUB RAM: I think that if ever implemented, while not reaching the speed of·dedicated SRAM solutions with 1:1 pins,·that method would·render DRAM (and other burst-based RAM types) useful to some extent.

Toby Seckshund

The chips I have here are still bolted onto the video printer board, because I forgot to take them into work and hot air them off. but they are very simular to the ones on your SIM with four bunches of 5 leads. It's a shame that they are 1Mx4, 512Kx8 would have been more convienient.

With Clusso's ccts like the ProtoBlade, it's probably a waste of effort chip count wise, but I would learn something, perhaps ...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point

AntoineDoinel

Toby

If you feel daring, you could try some piggy-back of the two chips, all signals can go tied together except the 4+4 data lines.
Also if you manage to free the /OE pin, data and address sharing could be attempted, but I would leave that for later eventually.

Two things:

- Always check with the chip datasheet, not only for the main timings, but also for some less obvious details: out of the many modules I had available, I found that some had 5ns min settling time for things like "address to strobe" and "CAS to WE", the one I'm using has 0ns minimum, and this allows for simultaneous output of a combined CAS+WE pin mask.

- It's very likely that·your chips·have 5V supply. I didn't even try with 3.3V (fearing that it *might* work but adverese effect on timings), instead I used serial resistors on data lines (I took advantage of the ones already soldered on the protoboard and added the others, 240R is small but the datasheet for my chips reports Voh as low as·3.6V even with 5V supply).

If you think it might be useful to you, I can post the code I used for testing (a quick hack of the HX512 PASM driver and test program, used as skeleton in the end).

Regards
Alessandro

Toby Seckshund

Thanks, I would like a look at that code to see if what I am thinking is anything like what is needed. I will look to see what othe types are kicking around at work. There are three or four old LCD projectors to be torn apart yet

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point

AntoineDoinel

Toby

Here it goes...

Consider that it's in a very bad shape, there are pieces of butchered and/or unused code all around... I quickly edited the heading credits·to avoid any harm to the innocent (the original author Andre LaMothe).

The relevant stuff however should be readable: initialization, main command loop with refresh, ReadByte, WriteByte, ReadPage and WritePage in DRAM_PASM_DRV_010.spin.

In case you should wonder, CASP signal is same as CAS but for the parity bit, I was considering the·use of the parity bit from the 1Mx1 DRAM chip on the SIMM·as RAM disk.

Pin usage:

P0..P9 -> A0..A9
(P10..P11 -> A10..A11 for extended address range, or free pins)
P12 -> nRAS
P13 -> nCAS
P14 -> nWE
(P15 -> nCASP not used if no parity)
P16..P23 <-> D0..D7
(P24 <-> PD & PQ of SIMM joined with resistor, not used if no parity)

...or 21 pins total for 1Mx8

Regards
Alessandro

Toby Seckshund

Thanks for that. Bored at work at the present but I will look at it when I get home.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point

Ale

Toby: While you wait for a command you could do CAS-before RAS refresh, it doesn't need an address. Another way is to use hidden refresh toggling RAS while CAS is still asserted during a read cycle. in the latter RAS has to be asserted the same time as the DRAM's access time say 60 or 70 ns (or more...) so a couple xor's with another instruction in between... just an idea.

btw, partial array refresh shouldn't pose a problem, but irrelevant using hidden or CAS-before-RAS refresh, just one of them. I do not believe they can be mixed.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU

Toby Seckshund

Ale

Thanks, it is all these different types of refreshes that I now want to sort out in my mind. The last time I used a dynamic it was a 16Kx1 non MUX ADDR on a Z80. So it has nothing to do with the modern types, but it was the MUX bit that I remembered and thought could be used as the latches on Dr_A's board

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point

Ale

Yes, the latches are inside the DRAM but they will sort of work as if they where external... 10 bits (for a 1M) are loaded with the falling of RAS and 10 more with the falling of CAS then you either write asserting W or read asserting OE. You shouldn't need any delays but check the waveforms in the datasheet for the type you use. I finf alldatasheet.com to be a nice repository of them. (search for EDO DRAM if the type you have is not there).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU