Reply by October 29, 20072007-10-29
On Oct 28, 10:18 pm, davewang202 <davewang...@gmail.com> 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 > > 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...
Reply by davewang202 October 28, 20072007-10-28
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 > 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}}
Reply by Brian Drummond October 27, 20072007-10-27
On Fri, 26 Oct 2007 07:35:32 -0700, Andy <jonesandy@comcast.net> wrote:

>On Oct 26, 8:09 am, Brian Drummond <brian_drumm...@btconnect.com> >wrote:
>> 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
Reply by October 26, 20072007-10-26
On Oct 26, 9:09 am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Mon, 22 Oct 2007 22:44:56 -0700, sendt...@gmail.com wrote: > >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
Reply by October 26, 20072007-10-26
> 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?
> > 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.
> > 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).
> > 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.
Reply by Andy October 26, 20072007-10-26
On Oct 26, 8:09 am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Mon, 22 Oct 2007 22:44:56 -0700, sendt...@gmail.com wrote: > >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
Reply by Del Cecchi October 26, 20072007-10-26
<sendthis@gmail.com> wrote in message 
news:1193355065.572064.187420@y42g2000hsy.googlegroups.com...
> >> 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
> >
Reply by Ed Prochak October 26, 20072007-10-26
On Oct 26, 8:05 am, Gabor <ga...@alacron.com> wrote:
[]
> > 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, sendt...@gmail.com wrote: []
> 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
Reply by CBFalconer October 26, 20072007-10-26
David Spencer wrote:
>
... snip ...
> > 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
Reply by Brian Drummond October 26, 20072007-10-26
On Mon, 22 Oct 2007 22:44:56 -0700, sendthis@gmail.com wrote:

>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