If a large bank of external RAM is required by a project, perhaps 256 kilobytes or more, one might consider the use of Dynamic RAM. The greatest advantage of DRAM is its tremendously low cost, probably due to its increased use in PCs due to the outrageously huge resource requirements of the typical Microsoft Windows application. Besides prices hovering close to the $5 per Megabyte range, DRAMs are also very "dense"--small packeges contain large amounts of memory. A typical SRAM cell required 5 transistors, while a DRAM cell only one.

If DRAM is so great, why does SRAM exist? As with every case in engineering, there is some comprimise involved. SRAM can be made to work much faster than DRAM (keep in mind that the primary mode of storage in DRAM is the inter-electrode capacitance of the MOSFET used for the cell, and capacitance and ultra-high speed are not exactly compatible).

To fit the DRAM in such a tiny, low cost package, designers chose to use a multiplexed address bus. That is, only half the address pins are present, and the address must be supplied in two parts--row and column. The two halves of the address correspond to a "coordinate" in the 2-D array of memory cells. The process of accessing DRAM is not too difficult, but it does add to the complexity and time requred to retrieve data.

Finally, DRAM doesn't actually work. The tiny capacitance is leaky and will only store a bit for a few scant milliseconds at best. Increasing the capacitance makes data retention better, but causes the aformentioned speed problem to worsen, in addition to requiring more physical space. Not only that, but reading the data actually destroys the data. To solve this problem, the DRAM designers provide circuitry to re-charge the cells with the proper value after each read (in actuality the entire row of cells in the grid is re-charged). The system using the DRAM must use this mechanism to constantly "refresh" the DRAM by reading each row in the array within a specified time, before the data is lost.

Accessing data from DRAM

The detailed timing diagrams of a typical DRAM are presented in this data sheet from Alliance Semiconductors. In addition to providing basic read, write and refresh timing, it also covers "fast page" mode, which allows faster access to adjacent memory locations. Fast Page mode is not covered in this application note.

Although there is a lot of maintenance involved with DRAM, extra external circuitry is not required. A VHDL module can be used to interface directly to the FPGA. In fact, A DRAM Controller is an ideal use for an FPGA.

The major difference between the read/write cycles of DRAM and SRAM is the multiplexed addressing scheme used by DRAM to access a memory location. The following process is used (see page 8 of the data sheet):

1. The "row" half of the address is presented to the address pins
2. The Row Address Strobe (RAS*) line is brought low
3. The "column" half of the address is presented to the address pins. If a write operation is being executed, the data is presented on the data lines and WE* is broght low. If a read is being executed, the WE* line is left high and the data lines are not driven.
4. The Column Address Strobe (RAS*) line is brought low. If a read is being done, the Output Enable line (G*) id brough low.
5. The data operation is completed and RAS* and CAS* are brought high to signify the end of operation (the order usually isn't important). Generally, G* and WE* will also be brought high at this point to keep things straight.

RAS-Only Refresh (page 11 of datasheet)
The most primitive of refresh schemes, this method was the rule with first generation DRAMs. The premise of RAS-only refresh is that an entire row of cells in a DRAM array are re-charged with each data access (thus a read or write cycle is also a refresh cycle). With RAS-only refresh, a row-address counter is used to cycle through all the rows. When a refresh is to occur (usually every 10 to 100 clock cycles per row us sufficient), RAS* and CAS* are forced high, the address on this counter is placed on the address bus, and RAS* is then broght low. For a 64K DRAM, 256 such cycles (and an 8-bit refresh counter) are required, and 256 cells are refreshed at once. Refresh is a constant and pervasive task, but it usually doesn't take any more than 1% of system clock cycles away from the CPU.

CAS-before-RAS Refresh (page 11 of datasheet)
Almost all current DRAMs support this mode of refresh. In this case, the DRAM has an internal refresh address counter, so an external counter is not required. CAS-before-RAS is opposite of the sequence required to do a normal memory access, and signifies to the chip that a refresh is to be done and the internal counter updated. A refresh sequence is triggered by bringing CAS* and RAS* high, then lowering CAS*, followed by RAS* some short time later.

Hidden Refresh (page 12 of datasheet)
Hidden refresh is a form of CAS-before-RAS refresh, and is also supported by most current DRAMs. The only significant difference is that the operation may take place immediately after a data access, before CAS is brought high. To do a refresh, the RAS line is simply pulsed high-low while the CAS line is low. When the refresh operation is complete, the RAS and CAS lines are brought high. By pulsing RAS several times, a "burst" refresh may be done. The great advantage with hidden refresh is that it does not affect the data bus--the data remains valid throughout the procedure (unlike the above two methods). That is why it is a "hidden" refresh--less logic is required by the rest of the system to ensure the signal on the data line has not been corrupted by a refresh.

When to refresh?

There are several times when a refresh may be done. Generally, the complete DRAM only needs refreshing one every few milliseconds (within thousands of system clock cycles). It may be satisfactory to interrupt the system every 5 ms and do a "burst" refresh (all rows done in a row). This is usually too intrusive though, so smaller bursts, or even individual rows, are refreshed on a slower refresh clock (a division of the system clock--10 kHz is usually fast enough), allowing system accesses to "sneak in" wherever they need to happen.