Changing refresh rate for DRAM while in operation?

Hi,

I'm trying to control a SDR SDRAM (Micron 64Mbit chip) using an Altera
DE2 board. I've gotten the hardware interface squared away (thanks
everyone for your help!).

Now it's the tricky stuff. Any one have an idea how I can change the
refresh rate while the RAM is in operation?

I have the DRAM interface built using the SOPC builder that comes with
Quartus II using the NIOS II system.

I know you can change the refresh rate during the build but I need a
way to change the refresh rate during operation. The only thing I can
think of is maybe change the clock speed? I have it running off a
50Mhz clock....

Thanks,
Eric

<sendthis@gmail.com> wrote in message 
news:1193118296.434575.124270@k35g2000prh.googlegroups.com...
> Hi,
>
> I'm trying to control a SDR SDRAM (Micron 64Mbit chip) using an Altera
> DE2 board. I've gotten the hardware interface squared away (thanks
> everyone for your help!).
>
> Now it's the tricky stuff. Any one have an idea how I can change the
> refresh rate while the RAM is in operation?
>
The most obvious question would be 'Why?'

> I have the DRAM interface built using the SOPC builder that comes with
> Quartus II using the NIOS II system.
>
That will limit your options (as would probably most other vendor IP DRAM 
controllers).

> I know you can change the refresh rate during the build but I need a
> way to change the refresh rate during operation. The only thing I can
> think of is maybe change the clock speed? I have it running off a
> 50Mhz clock....
>
A simpler way would be to simply have a DRAM controller that has an explicit 
'Refresh Request' input that would cause the controller to perform a 
refresh.  Then connect that input up to any programmable timer or other 
logic that you would like to use.  Changing the clock rate would be far down 
on my list of ways to accomplish your goal....but again, it begs the 
original question about why you would want to change the refresh rate 
dynamically at all.

KJ 

> Now it's the tricky stuff. Any one have an idea how I can change the
> refresh rate while the RAM is in operation?

Why?

KJ wrote:
> <sendthis@gmail.com> wrote in message 
> news:1193118296.434575.124270@k35g2000prh.googlegroups.com...
>> Hi,
>>
>> I'm trying to control a SDR SDRAM (Micron 64Mbit chip) using an Altera
>> DE2 board. I've gotten the hardware interface squared away (thanks
>> everyone for your help!).
>>
>> Now it's the tricky stuff. Any one have an idea how I can change the
>> refresh rate while the RAM is in operation?
>>
> The most obvious question would be 'Why?'
> 
>> I have the DRAM interface built using the SOPC builder that comes with
>> Quartus II using the NIOS II system.
>>
> That will limit your options (as would probably most other vendor IP DRAM 
> controllers).
> 
>> I know you can change the refresh rate during the build but I need a
>> way to change the refresh rate during operation. The only thing I can
>> think of is maybe change the clock speed? I have it running off a
>> 50Mhz clock....
>>
> A simpler way would be to simply have a DRAM controller that has an explicit 
> 'Refresh Request' input that would cause the controller to perform a 
> refresh.  Then connect that input up to any programmable timer or other 
> logic that you would like to use.  Changing the clock rate would be far down 
> on my list of ways to accomplish your goal....but again, it begs the 
> original question about why you would want to change the refresh rate 
> dynamically at all.

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.

sendthis@gmail.com wrote:
> 
> I'm trying to control a SDR SDRAM (Micron 64Mbit chip) using an
> Altera DE2 board. I've gotten the hardware interface squared away
> (thanks everyone for your help!).
> 
> Now it's the tricky stuff. Any one have an idea how I can change
> the refresh rate while the RAM is in operation?
> 
> I have the DRAM interface built using the SOPC builder that comes
> with Quartus II using the NIOS II system.
> 
> I know you can change the refresh rate during the build but I need
> a way to change the refresh rate during operation. The only thing
> I can think of is maybe change the clock speed? I have it running
> off a 50Mhz clock....

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.

What are you trying to do?

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

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.

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.

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

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.