Discussion:
Changing refresh rate for DRAM while in operation?
(too old to reply)
s***@gmail.com
2007-10-23 05:44:56 UTC
Permalink
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
KJ
2007-10-23 11:44:36 UTC
Permalink
Post by s***@gmail.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?'
Post by s***@gmail.com
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).
Post by s***@gmail.com
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
Jim Stewart
2007-10-23 17:03:53 UTC
Permalink
Post by KJ
Post by s***@gmail.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?'
Post by s***@gmail.com
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).
Post by s***@gmail.com
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.
s***@gmail.com
2007-10-25 23:24:02 UTC
Permalink
Post by Jim Stewart
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
David Spencer
2007-10-23 12:36:48 UTC
Permalink
Post by s***@gmail.com
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?
CBFalconer
2007-10-23 21:04:03 UTC
Permalink
Post by s***@gmail.com
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
MitchAlsup
2007-10-24 21:39:16 UTC
Permalink
Post by CBFalconer
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.
Post by CBFalconer
What are you trying to do?
That is the real question.
Paul Keinanen
2007-10-25 05:35:06 UTC
Permalink
Post by MitchAlsup
Post by CBFalconer
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.
Post by CBFalconer
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
Sean Durkin
2007-10-25 08:34:52 UTC
Permalink
Post by Paul Keinanen
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...
CBFalconer
2007-10-25 13:54:14 UTC
Permalink
Post by MitchAlsup
Post by CBFalconer
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.
Post by CBFalconer
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
David Spencer
2007-10-25 16:59:18 UTC
Permalink
Post by CBFalconer
Post by MitchAlsup
Post by CBFalconer
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.
Gabor
2007-10-25 17:25:00 UTC
Permalink
Post by David Spencer
Post by CBFalconer
Post by MitchAlsup
Post by CBFalconer
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...
KJ
2007-10-25 18:19:00 UTC
Permalink
Post by Gabor
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
glen herrmannsfeldt
2007-10-25 23:39:27 UTC
Permalink
Gabor wrote:

(snip)
Post by Gabor
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...
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
s***@gmail.com
2007-10-25 23:31:05 UTC
Permalink
Post by glen herrmannsfeldt
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.
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).
Del Cecchi
2007-10-26 14:14:58 UTC
Permalink
Post by s***@gmail.com
Post by glen herrmannsfeldt
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.
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).
Yes it will. The charge in the cell decreases over time. So running
with a faster refresh rate will, at least somewhat, increase the minimum
charge in a cell and increase the signal on the bit line.

Have you reviewed the literature on this? I can't believe that this type
of experiment hasn't already been done.

del
s***@gmail.com
2007-10-25 23:20:38 UTC
Permalink
Post by CBFalconer
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.
Peter Alfke
2007-10-26 05:00:27 UTC
Permalink
Post by s***@gmail.com
Post by CBFalconer
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
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
Post by s***@gmail.com
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.
Antti
2007-10-26 06:07:16 UTC
Permalink
Post by Peter Alfke
Post by s***@gmail.com
Post by CBFalconer
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
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.
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
Post by s***@gmail.com
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.- Zitierten Text ausblenden -
- Zitierten Text anzeigen -
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
msg
2007-10-26 06:28:49 UTC
Permalink
Antti wrote:

<snip>
Post by Antti
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
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
s***@gmail.com
2007-10-26 07:07:53 UTC
Permalink
Post by Peter Alfke
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.
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.
David Spencer
2007-10-26 11:53:53 UTC
Permalink
Post by s***@gmail.com
Post by Peter Alfke
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.
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.
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.
CBFalconer
2007-10-26 13:20:34 UTC
Permalink
David Spencer wrote:
... snip ...
Post by David Spencer
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.
Things may be much 'worse' than that. I remember one of the first
16k RAM chips developed, which we found (by accident) could retain
information for days with power off. This couldn't be trusted.
Those chips were actually static memory 2k x 8 bits, not dynamic.
--
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
Gabor
2007-10-26 12:05:27 UTC
Permalink
Post by s***@gmail.com
Post by Peter Alfke
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.
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.
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
Ed Prochak
2007-10-26 14:07:45 UTC
Permalink
On Oct 26, 8:05 am, Gabor <***@alacron.com> wrote:
[]
Post by Gabor
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
I think you may be addressing his real problem as he mentions in
another post.


On Oct 25, 7:31 pm, ***@gmail.com wrote:
[]
Post by Gabor
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).
I think your test is a difficult one since you are looking for
failures due to discharge by random radiation effects. Slowing down
the refresh and finding one or few cells that tend to discharge more
quickly than the rest as a few others have suggested does not really
apply to the problem.

You haven't specified what kind of radiation you are testing for (high
energy cosmic rays, background radiation, BETA radiation, Nuclear
power plant radiation(monitoring or robotic device?), or nuclear bomb)
This is not a simple test rig. The programming of the refresh rate is
a minor problem. The problem, if I understand your description
correctly, is
measure the failure rate DUE TO RADIATION versus refresh rate.
Since radiation induced failures are random, you'll have to do a good
number of test runs at various refresh rates to get a handle on the
range of failure rate (to be able to say
there were Y failures +/-y at refresh rate X) You need to be able to
sort out what failures are due to the memory device itself and what is
due to the radiation.

The supplier of your memory may be able to give some advice on this
test setup. (or are you working for the memory manufacturer?) I think
you do not need to change the refresh rate dynamically. You should be
able to do test runs at a fixed refresh rate, get the failure rate,
reboot with a new refresh rate and start again. Depending on the
radiation source you may need to replace the memory modules in a
controlled way, to deal with the cases of permanent damage by the
radiation.

I'm not trying to be offensive with this final question/comment, but I
take it your background is computer science only, right? You may need
to get someone with a background in physical sciences (a physicist) to
help design the experiment. (I have a BS in physics, but nuclear
physics is not one of my strong points.)

HTH,
Ed
s***@gmail.com
2007-10-26 18:23:45 UTC
Permalink
Post by Ed Prochak
I think your test is a difficult one since you are looking for
failures due to discharge by random radiation effects. Slowing down
the refresh and finding one or few cells that tend to discharge more
quickly than the rest as a few others have suggested does not really
apply to the problem.
No, I'm looking at the retention. How does radiation effect the
retention characteristics of the DRAM. As mentioned in another reply,
it makes sense to change DRAM refresh rates at different temperatures.
Does this help in a radiation environment?
Post by Ed Prochak
You haven't specified what kind of radiation you are testing for (high
energy cosmic rays, background radiation, BETA radiation, Nuclear
power plant radiation(monitoring or robotic device?), or nuclear bomb)
This is not a simple test rig. The programming of the refresh rate is
a minor problem. The problem, if I understand your description
correctly, is
We are using gammas for this test. Following students will use other
radiation sources.
Post by Ed Prochak
The supplier of your memory may be able to give some advice on this
test setup. (or are you working for the memory manufacturer?) I think
you do not need to change the refresh rate dynamically. You should be
able to do test runs at a fixed refresh rate, get the failure rate,
reboot with a new refresh rate and start again. Depending on the
radiation source you may need to replace the memory modules in a
controlled way, to deal with the cases of permanent damage by the
radiation.
Not working for the mfg. I wish I was, then I'd have more resources.
I'm working for a university (as in, I'm a student).
Post by Ed Prochak
I'm not trying to be offensive with this final question/comment, but I
take it your background is computer science only, right? You may need
to get someone with a background in physical sciences (a physicist) to
help design the experiment. (I have a BS in physics, but nuclear
physics is not one of my strong points.)
I have a nuclear engineer helping me with this. Actually, it's the
other way around since this isn't really related to the deliverables
for my thesis.
davewang202
2007-10-29 02:18:05 UTC
Permalink
Post by s***@gmail.com
Post by CBFalconer
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.
I think it would be really tough to do what you want to do. The
reason is that DRAM cell retention time charcteristics are not always
deterministic. Some cells will retain data for hundreds of
milliseconds, while other cells will retain data for tens of seconds,
and they don't always stay in the "hundreds of millisecond" bit or the
"tens of seconds" bin.

Ravi Venkatesan's paper has some numbers of DRAM cell retention time
characteristics [Venkatesan2006].

What this paper doesn't talk about, and what will hurt you is the
Variable Retention Time (VRT) characteristics of DRAM cells. That is,
a given DRAM cell can retain data for tens of seconds most of the
time, but once in a while, it can become a leaky cell that only
retains data for tens of milliseconds. End users sometimes refer to
this as being a "weak bit".
[Yaney1987,Restle1992,Ueno1998,Mori2005,Kim2004]

Now, if you're trying to use the DRAM device as a SEU detector of some
sort, it depends on how much radiation you expect. If there are a lot
of radiation in your environment, then you don't need to do a lot of
work beforehand to prepare your sample. If, however, you want to
measure something that's very subtle, and maybe someone that would
occur no more frequent than once per X minutes, then you'd really have
to spend a couple of months with a DRAM device and a tester in a cave
50 feet below ground (need to make sure that there are no neutrons
hitting the DRAM while you're characterising it), then characterise it
to the level so that you'll be able say with some level of
mathematical confidence that you know where all the weak bits in the
DRAM device are.

Then, once you know what your device looks like, then you take it to
the environment where you want to use it to measure your SEU rate,
then you'd be able to (to some degree) distinguish between a cell that
failed "early" because it has some built-in VRT characteristic, as
opposed to a cell that failed because of a SEU.

Good luck
David

@INPROCEEDINGS{Venkatesan2006, author = {Ravi K. Venkatesan, Stephen
Herr, Eric Rotenberg}, title = {Retention-Aware Placement in DRAM
(RAPID):Software Methods for Quasi-Non-Volatile DRAM}, booktitle =
{Proceedings of the 12th International Symposium on High Performance
Computer Architecture}, year = {2006}, pages = {157-167}}

@INPROCEEDINGS{Yaney1987, author = {D. S. Yaney, C. Y. Lu, R. A.
Kohler, M. J. Kelly, J. T. Nelson}, title = {A Meta-Stable Leakage
Phenonmenon in DRAM Charge Storage - Variable Hold Time}, booktitle =
{International Electron Devices Meeting Technical Digest}, year =
{1987}, pages = {336-338}}

@INPROCEEDINGS{Restle1992, author = {P. J. Restle, J. W. Park, B. F.
Lloyd}, title = {DRAM Variable Retention Time}, booktitle =
{International Electron Devices Meeting Technical Digest}, year =
{1992}, pages = {807-810}}

@INPROCEEDINGS{Ueno1998, author = {S. Ueno, T. Yamashita, H. Oda, S.
Komori, Y. Inoue, T. Nishimura}, title = {Leakage Current Observation
on Irregular Local Pn Junction Forming the Tail Distribution of DRAM
Retention Time Characteristics}, booktitle = {International Electron
Devices Meeting Technical Digest}, year = {1998}, pages = {153-156}}

@INPROCEEDINGS{Mori2005, author = {Yuki Mori, Kiyonori Ohyu, Kensuke
Okonogi, Ren-ichi Yamada}, title = {The Origins of Variable Retention
Time in DRAM}, booktitle = {International Electron Devices Meeting
Technical Digest}, year = {2005}, pages = {1057-1060}}

@INPROCEEDINGS{Kim2004, author = {Y. I. Kim, K. H. Yang, W. S. Lee},
title = {Thermal Degradation of DRAM Retention Time: Characterization
and Improving Techniques}, booktitle = {Proceedings of the 42nd Annual
International Reliability Physics Symposium}, year = {2004}, pages =
{667-668}}
s***@gmail.com
2007-10-29 22:37:07 UTC
Permalink
Post by davewang202
Post by s***@gmail.com
Post by CBFalconer
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.
I think it would be really tough to do what you want to do. The
reason is that DRAM cell retention time charcteristics are not always
deterministic. Some cells will retain data for hundreds of
milliseconds, while other cells will retain data for tens of seconds,
and they don't always stay in the "hundreds of millisecond" bit or the
"tens of seconds" bin.
Ravi Venkatesan's paper has some numbers of DRAM cell retention time
characteristics [Venkatesan2006].
What this paper doesn't talk about, and what will hurt you is the
Variable Retention Time (VRT) characteristics of DRAM cells. That is,
a given DRAM cell can retain data for tens of seconds most of the
time, but once in a while, it can become a leaky cell that only
retains data for tens of milliseconds. End users sometimes refer to
this as being a "weak bit".
[Yaney1987,Restle1992,Ueno1998,Mori2005,Kim2004]
Now, if you're trying to use the DRAM device as a SEU detector of some
sort, it depends on how much radiation you expect. If there are a lot
of radiation in your environment, then you don't need to do a lot of
work beforehand to prepare your sample. If, however, you want to
measure something that's very subtle, and maybe someone that would
occur no more frequent than once per X minutes, then you'd really have
to spend a couple of months with a DRAM device and a tester in a cave
50 feet below ground (need to make sure that there are no neutrons
hitting the DRAM while you're characterising it), then characterise it
to the level so that you'll be able say with some level of
mathematical confidence that you know where all the weak bits in the
DRAM device are.
Then, once you know what your device looks like, then you take it to
the environment where you want to use it to measure your SEU rate,
then you'd be able to (to some degree) distinguish between a cell that
failed "early" because it has some built-in VRT characteristic, as
opposed to a cell that failed because of a SEU.
Good luck
David
@INPROCEEDINGS{Venkatesan2006, author = {Ravi K. Venkatesan, Stephen
Herr, Eric Rotenberg}, title = {Retention-Aware Placement in DRAM
(RAPID):Software Methods for Quasi-Non-Volatile DRAM}, booktitle =
{Proceedings of the 12th International Symposium on High Performance
Computer Architecture}, year = {2006}, pages = {157-167}}
@INPROCEEDINGS{Yaney1987, author = {D. S. Yaney, C. Y. Lu, R. A.
Kohler, M. J. Kelly, J. T. Nelson}, title = {A Meta-Stable Leakage
Phenonmenon in DRAM Charge Storage - Variable Hold Time}, booktitle =
{International Electron Devices Meeting Technical Digest}, year =
{1987}, pages = {336-338}}
@INPROCEEDINGS{Restle1992, author = {P. J. Restle, J. W. Park, B. F.
Lloyd}, title = {DRAM Variable Retention Time}, booktitle =
{International Electron Devices Meeting Technical Digest}, year =
{1992}, pages = {807-810}}
@INPROCEEDINGS{Ueno1998, author = {S. Ueno, T. Yamashita, H. Oda, S.
Komori, Y. Inoue, T. Nishimura}, title = {Leakage Current Observation
on Irregular Local Pn Junction Forming the Tail Distribution of DRAM
Retention Time Characteristics}, booktitle = {International Electron
Devices Meeting Technical Digest}, year = {1998}, pages = {153-156}}
@INPROCEEDINGS{Mori2005, author = {Yuki Mori, Kiyonori Ohyu, Kensuke
Okonogi, Ren-ichi Yamada}, title = {The Origins of Variable Retention
Time in DRAM}, booktitle = {International Electron Devices Meeting
Technical Digest}, year = {2005}, pages = {1057-1060}}
@INPROCEEDINGS{Kim2004, author = {Y. I. Kim, K. H. Yang, W. S. Lee},
title = {Thermal Degradation of DRAM Retention Time: Characterization
and Improving Techniques}, booktitle = {Proceedings of the 42nd Annual
International Reliability Physics Symposium}, year = {2004}, pages =
{667-668}}- Hide quoted text -
- Show quoted text -
You brought up some interesting points that I didn't know. I knew that
different cells had different retention times but I was not aware
there was variation in the same cell. That's definitely a problem...
Brian Drummond
2007-10-26 13:09:13 UTC
Permalink
Post by s***@gmail.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?
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
Andy
2007-10-26 14:35:32 UTC
Permalink
Post by Brian Drummond
Post by s***@gmail.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?
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
If it is an up counter with a comparator, be careful: if it is an
equality rather than a greater-than comparator, and the CPU sets the
trigger value to less than the current value of the counter, then the
counter will have to roll all the way over, and likely miss a refresh,
with potential data loss resulting.

Andy
Brian Drummond
2007-10-27 12:18:36 UTC
Permalink
Post by Andy
Post by Brian Drummond
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).
If it is an up counter with a comparator, be careful: if it is an
equality rather than a greater-than comparator, and the CPU sets the
trigger value to less than the current value of the counter, then the
counter will have to roll all the way over, and likely miss a refresh,
with potential data loss resulting.
Good point: if doing that, it's advisable to reset the counter (and
issue a refresh) whenever you set the trigger value.

- Brian
s***@gmail.com
2007-10-26 18:26:19 UTC
Permalink
Post by Brian Drummond
Post by s***@gmail.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?
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
Actually that sounds like a good idea. I'll look into that, thanks.

-Eric
Continue reading on narkive:
Loading...