Hey all, I am designing(trying to design) an sdram controller (for a PC133 module) to work as fast as it is possible and as I understand from the datasheet, if I read faster than I need to refresh, then I can avoid refresh altogether. i.e if the refresh period is 64ms and if i access the data every, say, 20ms then I dont have to refresh. Please tell me if this is true or if I am getting confused. Thanks in Advance.
If you accessed every row within each SDRAM at least once during the refresh period, you would not have to refresh explicitly.
If your access pattern is predictable and continuous, you could do this, but it requires some careful thought. In virtually all cases, you'd need a mighty good reason to dispense with conventional refresh cycles, which typically eat up only 2 to 3 percent of available memory bandwidth.
I have done successful designs which laid memory out in the application to avoid having hardware refresh. One such machine just laid the instruction and data fetches already executed by the clock/timer routine out in a straight line. To make this work, you must put low order address lines on the row portion of the address multiplexor. With memories that have a burst mode this may not always be the highest performance option. CPU's with caches also can cause problems. But in general for small cpu's, this isn't a problem.
You may find that the client is willing to take a slightly slower memory, with slightly higher software service latencies, and not accept this tradeoff. Just depends how cost sensitive the design is.
If the cost of slightly larger and faster fpga isn't a budget stopper, it's probably best not to do this, as it can cause other problems if not careful .... like memory randomly disappearing because some software bug occured.
Asserting RAS causes a row of capacitors to have their charge topped up.
If they are above the voltage sense threshold then the have at least some charge, and they are given a full charge.
Asserting CAS causes one capacitor to be connected to a column line, and this either drives charge in/out for writing, or senses it for a read.
Capacitors are not completely discharged when read, of course.
From the points above you can deduce what is going to happen and what needs to be done.
So long as every row gets strobed at least once every 64 ms, every capacitor is refreshed. It does not matter if this is done by a refresh cycle (RAS only), or a read/write cycles (RAS then CAS).
The original IBM PC had an interrupt routine to do a series of DRAM accesses to refresh the DRAM. It had no DRAM controller at all.
If you can arrange your system software so that every row is accessed every refresh period, that should do the trick.
If you are doing a non-PC embedded system, the CPU may be running code from ROM most of the time. You could try refreshing the rows with those cycles: i.e. the DRAM gets a RAS during DRAM _and_ ROM cycles, but CAS only for RAM access. The row address will be whatever the CPU address bus is driven to, so obviously you have to make the ROM cycles cover every row. For this reason, it is easier to do if you use the least-significant address bits for the row address.
Note that the number of accesses needed is the square root of the DRAM chip size. I don't think refreshing 64K DRAM chips is too bad (256 accesses), but you might not like doing a 16Mbit DRAM chip (2048 accesses).
So if its a 64Mb chip (4096 accesses and 64mx between accesses) and I can do some kind of a serial reading then its better to skip the refresh? I am looking to push the SDRAM to the limit and to get highest bandwidth. anything other than bank interleaving and getting rid of refresh that can be done to maximize performance? this is my first controller and any suggestion is greatly appreciated.
This is true provided you access every single row, well at least every row you have data in, within the refresh time. This can be used to advantage in video frame buffers, for example as long as the frame time does not exceed the refresh time. So yes, it can be useful. It doesn't save a lot of meory bandwidth or time, but it can substantially simplify the DRAM controller in your design.
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.