I've been trying to work with an SDRAM chip. I
see that I need to 
refresh every 64 ms. I can do this using Auto Refresh. 

Supposedly, Auto Refresh uses an internal counter to count the 
row addresses so I don't have to use an external one. However, I 
still need to use a counter to count how many Auto Refresh 
commands I need to give, which, quite logically, is the number of 
rows!

So are we just duplicating a counter here? What am I missing?

Giorgos Tzampanakis <g...@hw.ac.uk> wrote
in 
news:Xns9D8CF3586BF9Dfdnbgui7uhu5h8hrnuio@81.169.183.62:

> I've been trying to work with an SDRAM chip. I see that I need to 
> refresh every 64 ms. I can do this using Auto Refresh. 
> 
> Supposedly, Auto Refresh uses an internal counter to count the 
> row addresses so I don't have to use an external one. However, I 
> still need to use a counter to count how many Auto Refresh 
> commands I need to give, which, quite logically, is the number of 
> rows!
> 
> So are we just duplicating a counter here? What am I missing?
> 

If there are N rows, don't you just refresh every 64/N ms (or a little less 
for margin) ?  You may need a counter to get the timing, but you don't need a 
counter for counting rows.

I admit to being puzzled about how you get started, unless you wait 64 ms 
before making first use of the SDRAM.

On Thu, 3 Jun 2010 22:55:18 +0000 (UTC), Giorgos
Tzampanakis
<g...@hw.ac.uk> wrote:

>I've been trying to work with an SDRAM chip. I see that I need to 
>refresh every 64 ms. I can do this using Auto Refresh. 
>
>Supposedly, Auto Refresh uses an internal counter to count the 
>row addresses so I don't have to use an external one. However, I 
>still need to use a counter to count how many Auto Refresh 
>commands I need to give, which, quite logically, is the number of 
>rows!
>
>So are we just duplicating a counter here? What am I missing?

It's normal to not generate all the refresh pulses at once. So if your
datasheet informs you that there are 8192 rows to refresh, you generate
1 refresh pulse every 64ms/8192, or every 7.8 us approx, instead of 8192
at once.

In any case a refresh pulse places a huge demand on the PSU, so a burst
of 8192 at once may cause PSU troubles or thermal problems in the DRAM.
Check the datasheet for restrictions on the interval between refresh
pulses. 

Newer technologies (DDR,DDR2 etc) are quite restricted in the interval
between refresh pulses. They typically require at least one every 70 us
(not ms) which effectively means you can defer up to 8 refresh pulses
and burst them after 70us, but data integrity is not guaranteed if you
get further behind than that.

It is probably 10 years since I looked at a SDRAM datasheet, but it is
quite likely they have a similar restriction.

- Brian

On Jun 3, 7:40=A0pm, Brian Drummond
<brian_drumm...@btconnect.com>
wrote:
> On Thu, 3 Jun 2010 22:55:18 +0000 (UTC), Giorgos Tzampanakis
>
> <g...@hw.ac.uk> wrote:
> >I've been trying to work with an SDRAM chip. I see that I need to
> >refresh every 64 ms. I can do this using Auto Refresh.
>
> >Supposedly, Auto Refresh uses an internal counter to count the
> >row addresses so I don't have to use an external one. However, I
> >still need to use a counter to count how many Auto Refresh
> >commands I need to give, which, quite logically, is the number of
> >rows!
>
> >So are we just duplicating a counter here? What am I missing?
>
> It's normal to not generate all the refresh pulses at once. So if your
> datasheet informs you that there are 8192 rows to refresh, you generate
> 1 refresh pulse every 64ms/8192, or every 7.8 us approx, instead of 8192
> at once.
>
> In any case a refresh pulse places a huge demand on the PSU, so a burst
> of 8192 at once may cause PSU troubles or thermal problems in the DRAM.
> Check the datasheet for restrictions on the interval between refresh
> pulses.
>
> Newer technologies (DDR,DDR2 etc) are quite restricted in the interval
> between refresh pulses. They typically require at least one every 70 us
> (not ms) which effectively means you can defer up to 8 refresh pulses
> and burst them after 70us, but data integrity is not guaranteed if you
> get further behind than that.
>
> It is probably 10 years since I looked at a SDRAM datasheet, but it is
> quite likely they have a similar restriction.
>
> - Brian

The single datarate parts don't have any timing restrictions on
refresh other than meeting the 64 ms between refresh to any
row.  In fact under some circumstances, like video frame
buffers where all rows are accessed anyway, you don't need
to do auto-refresh at all.

DDR parts are a different beast altogether.  They contain delay
locked loops and the JEDEC spec recommends refresh
every 15 microseconds because the refresh time is used to
update the loop lock.  Individual manufacturers, including
Micron have less stringent requirements, but it can't hurt
to design for the JEDEC case.  Anyway if you just figure out
the rate and spread out the refreshes you don't need the
row counter.  You still need some sort of counter to time the
refresh interval, though.

Regards,
Gabor