Changing refresh rate for DRAM while in operation?

And by not having to perform explicit refreshes, the bandwidth is slightly higher and latency is more predictable. If your application is one that always addresses all the memory that it uses (no need to refresh rows you are not using) within the minimum refresh interval, then this can sometimes be used to simplify the system. There are still plenty of FPGA applications that, for example, use the DRAM only for a video frame buffer.

Reply to
Ray Andraka
Loading thread data ...

If the idea is to reduce the refresh overhead on a busy bus, reducing the relatively slow refresh rate does not make much sense.

However, if the memory content is to be maintained for a long time without any data access in a battery powered device, it would make sense to reduce the refresh rate at low ambient temperatures. The high refresh rates are needed at the top end of the temperature range, but at lower temperatures, a slower refresh rate would be sufficient, which reduces the power consumption and increase battery life. Unfortunately, refresh rate figures are seldom available for lower temperatures.

Paul

Reply to
Paul Keinanen

If you were really aiming for long run time on battery power, I suppose you'd just use DRAM devices specifically made for such an application.

Mobile SDRAM devices often have a temperature compensated self refresh feature. You just enter a special suspend mode and the device does the refresh itself, and only as often as required according to the current temperature. You can also tell it to just refresh a part of the memory array, in case you don't use it all.

This is usually way better than anything one could do on his/her own.

So, the question still stands: What does the OP really want to do?

cu, Sean

--
My email address is only valid until the end of the month.
Try figuring out what the address is going to be after that...
Reply to
Sean Durkin

for

the

The TRS-80 Color Computer (Moto 6809 based) refreshed during the vertical retrace. But there was a bit in the system controller that could be set to turn it and video access off, while doubling the processor clock. As long as your Basic code was running, and not waiting on a keyboard input or other event, the ROM interpreter's RAM accesses managed to keep the RAM (at least the part of it being used) refreshed. But if/when the code hit an error (and thus waited for user response) you could watch the screen go from random pixels to all white. Once the coding errors were eliminated, it was a reliable way to double the processing speed when you did not need video.

Ah the good old days... but, I digress.

Andy

Reply to
Andy

Since the OP seems to have disappeared to wherever OPs go, I suspect we will never find out.

--
 Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
Reply to
CBFalconer

Don't you just hate it when that happens? Even if the OP now realises that what he was trying to do wasn't appropriate or necessary, it would be nice if he just explained his original intentions to us.

Reply to
David Spencer

He's probably sorry about the flame war he unintentionally created but thinks it would have been nice if one of the 25 replies answered his original question...

Reply to
Gabor

The very first reply to the original post did answer the OP's original question.

The rest of the thread has been for entertainment and educational value.

KJ

Reply to
KJ

I didn't disappear, I posted a reply but for some reason it didn't show up... I didn't want to accidentally spam the newsgroups by reposting and figured I'd wait to make sure it wasn't just my newsreader or ISP causing the problem.

Anyway, I guess I'll answer the reason why I want to do this in the same post.

I'm trying to characterize a DRAM device in certain environmental (radiation) conditions and see how that effects the retention characteristics. I'm not sure if there tests the industry uses to do this, but I needed to evaluate it realtime.

I'm using the core Altera provided but all the code is there (except for the NIOS II cpu). So I have direct access to the SDRAM controller.

Reply to
sendthis

Thanks for giving me the benefit of the doubt. I put this in another reply, but the reason I want to change it is to characterize the DRAM to get it's retention characteristics in a radiation environment. So I want to know how long the DRAM keeps it's charge given a specific and controlled environment.

Interfacing, programming, and DRAM definitely aren't my areas of study (materials is). This is for a small but time consuming part of my thesis project.

Thanks, eric

Reply to
sendthis

I know the mode register is initialized at the beginning with the refresh rate (and some other information). Is it possible to reload the mode register and will this do anything to the stored data (such as letting all the caps discharge)? Is this even possible?

I do appreciate everyone's replies and I certainly didn't mean to ignore your answers and questions that were trying to help me.

Paul mentioned in his reply that it makes sense to do it in different temperatures. This really is similar to what I am trying to do. I'm trying to figure out (partly) if the refresh rate will help with the radiation tolerance of the device (i.e. speeding it up).

Reply to
sendthis

(snip)

Probably so, but it isn't at all obvious how to answer. The DRAM doesn't care as long as every row is refreshed within the specified amount of time. Some refresh all rows in a big burst, others one at a time uniformly over the interval. You can refresh faster than the specified rate, but there is no system independent way to describe how to do that. For systems with a variable speed clock (such as power saving modes) one does have to design the refresh system appropriately.

-- glen

Reply to
glen herrmannsfeldt

Andy wrote: (snip)

I thought it was the display memory access that did the refresh. I probably still have the service manual around somewhere.

If I remember, there were three modes. Normal mode, one that doubled the clock speed some of the time, and one that doubled it all the time. I never tried turning the display off, though.

-- glen

Reply to
glen herrmannsfeldt

Here is a free suggestion (the price is right): I would write a specific word-pattern with an even mix of 1 and 0 into every location in the whole DRAM. Then read back sequentially at a slow pace through all addresses, always checking the readback. Sooner or later, you will pick up an error, becaue you exceeded the refresh delay. You may want to repeat this with different starting addresses and with different word patterns.

My opinion: SEU errors have little to do with refresh delay, since an ion can tip over even a fully charged bit. But that seems to be what you want to find out... Peter Alfke

Reply to
Peter Alfke

disappeared to wherever OPs go, I

eh, there used to be a special software that allows a DRAM to work as black white camera

it was using 64K x 1 military DRAMs, with REMOVED top lid, directly connected to PC LPT port.

the software measured the refresh of each cell, what is proportional to the light the author of that software had some "photos" taken with DRAM online too. and eh it wasnt me. but one of my first self-made homecomputers used the same military gold-ceramic packaged DRAMs

Antti

Reply to
Antti

Please see the thread entitled: "Poor Man's image sensor; Was: Re: Simple Still Camera components?" from June of this year (in comp.arch.embedded).

If anyone wants it and cannot find it, I have the archive of this project's code and documentation (in German, filename: kuckuck.zip).

Regards,

Michael

Reply to
msg

The problem is during the read (I'm assuming you mean by disabling the refresh altogether and relying solely on the refresh after read) is that it takes several seconds to read from the DRAM. This will always exceed the refresh time right? From the start_address to end_address it takes quite a while for a 64Mbit DRAM. The spec calls for a 64ms refresh.

Reply to
sendthis

A much bigger problem is that reading a DRAM location implicitly refreshes that entire row. Therefore, you can't poll to find out if your refresh is frequent enough because each read will perform a refresh.

You will probably find that if you disable refresh totally then most of the memory will stay intact for several seconds (and across power cycles!). If I was you, I would disable refresh totally, write a test pattern to memory and then check it after about five seconds to find one location that has failed. Once you've picked that one, use that as your test location. You can then write to it with various refresh rates and see if the data is still valid many seconds later. You probably won't have found the worst-case cell in the device, but that's rather academic because every device will be different anyway so this is far from a valid characterization test.

Reply to
David Spencer

The other problem is that the act of reading in fact performs a refresh so depending on the way you hooked up the address lines, you may actually refresh the entire chip many times over while reading through once.

But I think Peter's second statement is really important. When you think of the mechanism for a single-event upset, how much difference is a fully charged capacitor vs a capacitor allowed to drain for the specified 64mS (or some other refresh rate of your choice). If the standard refresh rate only allows a charge drop of say 20%, I don't see how doubling the rate and allowing a charge drop of only 10% will greatly reduce the percentage of events that cannot discharge a given capacitor. Under normal operating conditions I would imagine that the charge drain is much smaller than 20%.

In the old days, before the semiconductor manufacturers found radiation being emitted by some of the early ceramic packages, a lot of large memory systems used ECC with scrubbing refresh to make the system at all usable. In my opinion reducing the likelihood of uncorrectable multiple events via scrubbing is more effective than keeping your capacitors at peak charge.

Regards, Gabor

Reply to
Gabor

If you roll your own controller (easy enough for SDR SDRAM) or can understand the core you are given, you can find what controls the refresh rate; invariably a counter.

Replace the counter with an absurdly long one (say 32 bits), whose count length is controllable from a register accessible to whatever host CPU (NIOS in this case).

It's either a reloadable down counter, which reloads and generates a refresh cycle when it hits zero; in which case you reload it from the register; or an up-counter which refreshes and resets to zero when a comparator triggers; in which case the register holds the comparator value.

Then you have direct control of the refresh rate without messing with clock frequencies etc.

- Brian

Reply to
Brian Drummond

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.