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

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

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

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

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

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

On Wed, 24 Oct 2007 07:15:08 -0000, 
Antti <Antti.Lukats@googlemail.com> wrote:

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

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.

A DRAM row is effectively a cache.  When you access a row, 
you read the whole row into the DRAM's row buffer as a free 
side-effect, and can then make very fast column accesses
to anly location in the row.  It's preposterous to throw 
away that massive free bandwidth just to save yourself 
some refresh effort - unless you're trying to design 
a $80 home computer/toy in the early 1980s.

In those days, the video buffer was a sufficiently
large fraction of the overall DRAM that it was 
reasonable to lay out the video memory so that 
every row was automatically visited by the video
scan, giving a refresh cycle every 20ms (16.7ms
in the USA).  That was out-of-spec for many DRAMs
of the day (8ms refresh cycle) but in practice it
worked in almost all cases - and the manufacturers
of those computers had a shoddy enough warranty
policy that they weren't going to worry about a 
handful of customers complaining about occasional 
mysterious memory corruption on a hot day.

-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.