DRAM refresh techniques

DRAM refresh techniques

DRAM needs to be periodically refreshed and to do this there are several methods that can be used. The basic technique involves accessing the DRAM using a special refresh cycle. During these refresh cycles, no other access is permitted. The whole chip must be refreshed within a certain time period or its data will be lost. This time period is known as the refresh time. The number of accesses needed to complete the refresh is known as the number of cycles and this number divided into the refresh time gives the refresh rate. There are two refresh rates in common use: standard, which is 15.6 µs and extended, which is 125 µs. Each refresh cycle is approximately twice the length of a normal access — a 70 ns DRAM typically has a refresh cycle time of 130 ns — and this times the number of cycles gives the total amount of time lost in the refresh time to refresh. This figure is typically 3–4% of the refresh time. During this period, the memory is not accessible and thus any processor will have to wait for its data. This raises some interesting potential timing problems.

Distributed versus burst refresh

With a real-time embedded system, the time lost to refresh must be accounted for. However, its effect is dependent on the method chosen to perform all the refresh cycles within the refresh time. A 4 M by 1 DRAM requires 1024 refresh cycles. Are these cycles executed in a burst all at once or should they be distributed across the whole time? Bursting means that the worst case delay is 1024 times larger than that of a single refresh cycle that would be encountered in a distributed system. This delay is of the order of 0.2 ms, a not inconsiderable time for many embedded systems! The distributed worst case delay due to refresh is about 170 ns.

Most systems use the distributed method and depending on the size of time critical code, calculate the number of refresh cycles that are likely to be encountered and use that to estimate the delay caused by refresh cycles. It should be remembered that in both cases, the time and access overhead for refresh is the same.

It is possible to use software to perform the refresh by using a special routine to periodically circle through the memory and thus cause its refresh. Typically a timer is programmed to generate an interrupt. The interrupt handler would then perform the re-fresh. The problem with this arrangement is that any delay in performing the refresh potentially places the whole memory and its contents at risk. If the processor is stopped or single stepped, its interrupts disabled or similar, the refresh is halted and the memory contents lost. The disadvantage in this is that it makes debugging such a system extremely difficult. Many of the debugging tech-niques cannot be used because they stop the refresh. If the proces-sor crashes, the refresh is stopped and the contents are lost.

There have been some neat applications where software refresh is used. The Apple II personal computer used a special memory configuration so that every time the DRAM blocks that were used for video memory were accessed to update the screen, they effectively refreshed the DRAM.

RAS only refresh

With this method, the row address is placed on the address bus, RAS* is asserted but CAS* is held off. This generates the recycle address. The address generation is normally done by an external hardware controller, although many early controllers required some software assistance. The addressing order is not important but what is essential is that all the rows are refreshed within the refresh time.

CAS before RAS (CBR) refresh

This is a later refresh technique that is now commonly used. It has lower power consumption because it does not use the address bus and the buffers can be switched off. It works by using an internal address counter stored on the memory chip itself which is periodically incremented. Each incrementation starts a refresh cycle internally. The mechanism works as its name sug-gests by asserting CAS* before RAS*. Each time that RAS* is asserted, a refresh cycle is performed and the internal counter incremented.

Hidden refresh

This is a technique where a refresh cycle is added to the end of a normal read cycle. The term hidden refers to the fact that the refresh cycle is hidden in a normal read and not to any hiding of the refresh timing. It does not matter which technique you use, refresh will still cost time and performance! What happens is that the RAS* signal goes high and is then asserted low. This happens at the end of the read cycle when the CAS* signal is still asserted. This is a similar situation to the CBR method. Like it, this toggling of the RAS* signal at the end of the read cycle starts a CBR refresh cycle internally.