Changing refresh rate for DRAM while in operation?

Peter Alfke wrote:

> Jonathan, why so aggressive?
> I was just pointing out that certain applications naturally perform
> sufficient refresh operations in their normal addressing sequence. I
> can't see why this is "completely ridiculuous"...
> Peter Alfke
> 
> On Oct 24, 12:40 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
> wrote:
> 

>>Yes, and it's a completely ridiculous way to do it.  The
>>added cost of making frequent additional row accesses is
>>far greater than the cost of the necessary refresh.
>>

>>
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.

On Wed, 24 Oct 2007 14:39:16 -0700, MitchAlsup <MitchAlsup@aol.com>
wrote:

>On Oct 23, 4:04 pm, CBFalconer <cbfalco...@yahoo.com> wrote:
>> Since the only purpose of the refresh circuitry is to avoid the
>> memory dropping bits, it should already be running at the slowest
>> possible rate, and speed reduction will be harmful, while speed
>> increase will do no good.  So this is not a good idea.


>But I will state the overall performance differences are a fraction of
>the refresh overhead anyways.
>
>> What are you trying to do?
>
>That is the real question.

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
 

Paul Keinanen wrote:
> 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.
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...

On Oct 24, 1:40 pm, Dave Pollum <vze24...@verizon.net> wrote:
> On Oct 24, 2:15 am, Antti <Antti.Luk...@googlemail.com> wrote:
>
>
>
> > On 24 Okt., 07:50, Peter Alfke <al...@sbcglobal.net> wrote:
>
> > > On Oct 23, 5:27 pm, "David Spencer" <davidmspen...@verizon.net> wrote:
>
> > > > <MikeShepherd...@btinternet.com> wrote in message
>
> > > >news:1evsh3ds7i44iqhrsc4kldthlo2vb0tul2@4ax.com...
>
> > > > > Although it's not expressed in DRAM specs and you wouldn't want to
> > > > > rely on it, the effect of reducing refresh rate is to increase the
> > > > > access time.  I'm not up-to-date with DRAM technology, but my
> > > > > experience with devices 30 years ago was that you could turn off
> > > > > refresh (and all other access) for 10s or more without losing the
> > > > > contents, provided you weren't pushing the device to its access time
> > > > > limits.
>
> > > > > So, it's not impossible that reducing refresh rate would have a use
> > > > > (albeit outside the published device spec).  But, as you suggest, it
> > > > > would help if he would just tell us what he's trying to do.
>
> > > > > Mike
>
> > > > Although that may well be the case for asynchronous DRAMs (because the
> > > > reduced charge in the memory cell capacitor would mean that the sense
> > > > amplifier took longer to register the state), this would not be the case for
> > > > SDRAM since this registers the outputs a fixed number of clocks after the
> > > > access starts. If the underlying access time increased by too much then the
> > > > data would just be wrong.
>
> > > For certain addressing patterns, the refresh can be eliminated
> > > alltogether, when the addressing sequence is such that all (used)
> > > memory cells are naturally being read, and thus refreshed, within the
> > > required time.
> > > Peter Alfke- Zitierten Text ausblenden -
>
> > > - Zitierten Text anzeigen -
>
> > Sinclair ZX?
> > at least some old Z80 homecomputers used refresh by video scan
>
> > Antti
>
> If I recall, the Apple II also refreshed its RAM this way, too.
> -Dave Pollum

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

MitchAlsup wrote:
> CBFalconer <cbfalco...@yahoo.com> wrote:
>
>> Since the only purpose of the refresh circuitry is to avoid the
>> memory dropping bits, it should already be running at the slowest
>> possible rate, and speed reduction will be harmful, while speed
>> increase will do no good.  So this is not a good idea.
> 
> I disagree (softly), having designed several memory controllers,
> I always found it easier to just insert a READ DATA command into
> the DRAM when a refresh was needed, rather than insert a refresh
> command. The timing differences between refresh and a loosly
> coupled string of READS is such that one can refresh ahead with
> READs easier and then be in a position to absorb a longer string
> of demand requests by not using the REFRESH commands. Thus while
> running at the slowest overall rate, one can bunch and distribute
> the refresh mechanics to better interleave same with the demand
> memory requests and gain something.
> 
> But I will state the overall performance differences are a
> fraction of the refresh overhead anyways.
> 
>> What are you trying to do?
> 
> That is the real question.

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.
   <http://cbfalconer.home.att.net>



-- 
Posted via a free Usenet account from http://www.teranews.com

"CBFalconer" <cbfalconer@yahoo.com> wrote in message 
news:4720A006.98AA398B@yahoo.com...

>>> What are you trying to do?
>>
>> That is the real question.
>
> Since the OP seems to have disappeared to wherever OPs go, I
> suspect we will never find out.
>
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.

On Oct 25, 12:59 pm, "David Spencer" <davidmspen...@verizon.net>
wrote:
> "CBFalconer" <cbfalco...@yahoo.com> wrote in message
>
> news:4720A006.98AA398B@yahoo.com...
>
> >>> What are you trying to do?
>
> >> That is the real question.
>
> > Since the OP seems to have disappeared to wherever OPs go, I
> > suspect we will never find out.
>
> 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.


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...

On Oct 25, 1:25 pm, Gabor <ga...@alacron.com> wrote:
> On Oct 25, 12:59 pm, "David Spencer" <davidmspen...@verizon.net>
> but thinks it would have been nice if one of the 25 replies answered
> his original question...

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

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

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.

> Assuming he has a good reason to change it,
> the safest thing to do would be to call a
> routine in flash to change it.- Hide quoted text -
>

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