Changing refresh rate for DRAM while in operation?

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

Gabor wrote:

(snip)

> 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

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

On Oct 25, 4:20 pm, sendt...@gmail.com wrote:
> > 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

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

On 26 Okt., 07:00, Peter Alfke <al...@sbcglobal.net> wrote:
> On Oct 25, 4:20 pm, sendt...@gmail.com wrote:> > 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
>
>
>
> > 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

Antti wrote:

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

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

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.