SDRAM AutoPrecharge and Refresh
in [FPGA]
|
From: siriokds on 29 Jul 2010 07:05 As a newbie I'm working on an SDR SDRAM controller in VHDL and looking at datasheet of the chip I read how to set CAS latency to 2. I'm just using only simple READA/WRITA (with autoprecharge) commands avoiding refresh/autorefresh ones. My answer is simple, Does "AutoPrecharged" commands (READA/WRITA) issue dram refresh also avoiding me to performs ALSO the refresh command? I've looked at OneChip MSX SDRAM controller and refresh command is used only during initialization ... Thanks in advance for any help! Saverio --------------------------------------- Posted through http://www.FPGARelated.com
From: maxascent on 29 Jul 2010 07:44 You need to send refresh commands at the period it gives in the data sheet. It will be something like every 7.8 us. Jon --------------------------------------- Posted through http://www.FPGARelated.com
From: Gabor on 29 Jul 2010 11:04 On Jul 29, 7:05 am, "siriokds" <siriokds(a)n_o_s_p_a_m.gmail.com> wrote: > As a newbie I'm working on an SDR SDRAM controller in VHDL and looking at > datasheet of the chip I read how to set CAS latency to 2. > I'm just using only simple READA/WRITA (with autoprecharge) commands > avoiding refresh/autorefresh ones. > > My answer is simple, > > Does "AutoPrecharged" commands (READA/WRITA) issue dram refresh also > avoiding me to performs ALSO the refresh command? > > I've looked at OneChip MSX SDRAM controller and refresh command is used > only during initialization ... > > Thanks in advance for any help! > > Saverio > > --------------------------------------- > Posted throughhttp://www.FPGARelated.com Precharge and refresh are two different things. You can think of a row of memory haveing two operating states, Active, and Precharged. Issuing a row activate command places the row in the active state. Issuing a precharge comand or using a read or write with autoprecharge places the row in the precharged state. The row must be active to perform read or write. All rows must be precharged before issuing auto-refresh commands. For SDR SDRAM you don't necessarily have to issue refresh at a constant rate because it doesn't have a DLL like the DDR parts. However you must meet the refresh rule that all rows are refreshed within the refresh period specified, usually 32 ms or 64 ms. This generally works out to an average of one auto-refresh command every 15.6 us for smaller parts or every 7.8 us for the larger ones. Also for SDR SDRAM (but not DDR) you can effectively refresh the part by performing row activates to all rows within the refresh period. Note that row activate works on one bank at a time, while auto-refresh works on all four banks at once. So in effect it takes four times as many row activates to refresh the part. However there are some applications like video buffer memory where this much access would occur anyway and then you can avoid using refresh commands altogether. If the controller you looked at doesn't perform auto-refresh cycles after initialization, it should either have a way to request a refresh cycle once it is operational, or have some other method of making sure all rows get refreshed (some controllers do "scrubbing" refresh consisting of reading out data, performing error correction, and writing it back). I seem to recall that Fujitsu had a good data sheet that showed a state diagram of the SDRAM. But it's been a while since I first looked at these parts and the whole thing has become ingrained in my head since then. HTH, Gabor
From: siriokds on 29 Jul 2010 18:12 Thank you for your fast answer. I'm using an Altera DE1 demo board with SDRAM A3V64S40ETP from Zentel. It's a normal 64Mbit chip with 4096 rows to be refreshed in 64ms. 4 banks x 1M x 16bit. The VHDL SDRAM controller I'm looking at is included in OneChip MSX core and it's clocked at 85Mhz. It's uses board PLL to manage clock skew (3ms). It's set in CL2, Single location access, burst length ONE and burst type sequential. Pratically it's only a byte READER/WRITER. No refresh commands are present during normal operations but only during initialization. Every operation is manager in 8 cycles. CAS latency is set to 2 BUT data are read after 3 cycles!!! 1) ACT/RAS 2) NOP 3) READA/CAS 4) NOP 5) NOP 6) DATA-READ 7) (precharge?) 8) (precharge?) Naturally single byte access is enough for the specific purpose but I was expecting different behavior (refresh commands and correct cycles for reads). Datasheet of this SDR SDRAM part indicates expected behavior and it's almost the same as ISSI. Thank you in advance for any support. I can provide you the source code to look at... Saverio >On Jul 29, 7:05=A0am, "siriokds" <siriokds(a)n_o_s_p_a_m.gmail.com> wrote: >> As a newbie I'm working on an SDR SDRAM controller in VHDL and looking at >> datasheet of the chip I read how to set CAS latency to 2. >> I'm just using only simple READA/WRITA (with autoprecharge) commands >> avoiding refresh/autorefresh ones. >> >> My answer is simple, >> >> Does "AutoPrecharged" commands (READA/WRITA) issue dram refresh also >> avoiding me to performs ALSO the refresh command? >> >> I've looked at OneChip MSX SDRAM controller and refresh command is used >> only during initialization ... >> >> Thanks in advance for any help! >> >> Saverio >> >> --------------------------------------- =A0 =A0 =A0 =A0 >> Posted throughhttp://www.FPGARelated.com > >Precharge and refresh are two different things. You can think of a >row of memory >haveing two operating states, Active, and Precharged. Issuing a row >activate >command places the row in the active state. Issuing a precharge >comand or >using a read or write with autoprecharge places the row in the >precharged state. > >The row must be active to perform read or write. > >All rows must be precharged before issuing auto-refresh commands. > >For SDR SDRAM you don't necessarily have to issue refresh at a >constant >rate because it doesn't have a DLL like the DDR parts. However you >must >meet the refresh rule that all rows are refreshed within the refresh >period >specified, usually 32 ms or 64 ms. This generally works out to an >average >of one auto-refresh command every 15.6 us for smaller parts or every >7.8 us >for the larger ones. > >Also for SDR SDRAM (but not DDR) you can effectively refresh the part >by performing row activates to all rows within the refresh period. >Note that >row activate works on one bank at a time, while auto-refresh works on >all four banks at once. So in effect it takes four times as many row >activates >to refresh the part. However there are some applications like video >buffer >memory where this much access would occur anyway and then you can >avoid using refresh commands altogether. > >If the controller you looked at doesn't perform auto-refresh cycles >after >initialization, it should either have a way to request a refresh cycle >once it is operational, or have some other method of making sure all >rows get refreshed (some controllers do "scrubbing" refresh consisting >of reading out data, performing error correction, and writing it >back). > >I seem to recall that Fujitsu had a good data sheet that showed a >state diagram of the SDRAM. But it's been a while since I first >looked at these parts and the whole thing has become ingrained >in my head since then. > >HTH, >Gabor > --------------------------------------- Posted through http://www.FPGARelated.com
|
Pages: 1 Prev: USB3.0 device detection Next: Data-path accuracy in IIR filters? |