How does a SDRAM controller work?

Dear all, Normally SDRAM needs tens of MS to refresh bank of memory,while what happens when I happened to visit this memory address,either read or write. Dose the SDRAM controller(say,IP core from Xilinx) makes this read/write operation waiting for this refresh period and execute read/write command afterwards(That's unacceptable in term of time or speed for this read/write operation!)? Or it handles such condition in another way? Thanks for your information. regards

Reply to
jeffsen
Loading thread data ...

happens when I happened to visit this memory address,either read or write. Dose the SDRAM controller(say,IP core from Xilinx) makes this read/write operation waiting for this refresh period and execute read/write command afterwards(That's unacceptable in term of time or speed for this read/write operation!)? Or it handles such condition in another way? Thanks for your information. regards

You misunderstand. Each memory row needs to be refreshed every milliseconds, but the refresh cycle itself only takes a few clock cycles.

I'd recommend reading one of the Micron SDRAM datasheets as they have pretty good explanations of SDRAM.

Reply to
Mike Harrison

Just out of curiosity, is it possible to pipeline successive reads and writes to SDRAM? For example, I want to send a read command and then a write command, where the memory address will be different for reads and writes. After the necessary latency after the first read command, will there also be a delay between when I clock in data from that read and when I can start outputting write data?

Reply to
savingsandloan

As far as I remember, there is no delay if the write is to a row that is currently active. In SDRAM you have 2 or 4 banks and each bank can have one row active at a time. There are special commands to activate a row and precharge (store back) a previously activated row. You can only read/write to an activated row.

SDRAM datasheets from Micron, ISSI, and others have nice timing diagrams illustrating different cases.

-- Georgi

Reply to
Georgi Beloev

and

then a

and

will

and

is

have

row

cycle when switching between read and write in order to avoid overlapping drive on the DQ pins. If you're continuing to just write (or just read) you can burst continuously by "burying" the row precharge. This requires switching banks whenever you start a new row, however if you define "sequential" addresses such that the bank address bits are lower than the row address, you will be able to burst write or read the entire memory without any NOP cycles on the data lines. Also when switching from write - which presents data and command on the same cycle - to read, which has the "CAS latency" between the read command and the data cycle you will have multiple unused data cycles if you stay on the same bank (i.e. one bank cannot have a read command issued during a write burst).

diagrams

Reply to
Gabor

"you will be able to burst write or read the entire memory without any NOP cycles on the data lines."

Also, when bursting like this you need to make sure you touch an individual row at least once every 64ms. This depends on the clock frequency you're running the SDRAM at and the size of the SDRAM. You also have to be careful with what you do once you exit your bursting state. If you then revert to using a refresh command and the SDRAMs internal refresh counters, you'll have to assume that you come out of bursting with the worst case alignment between the row you last accessed while bursting and the internal refresh counters used by the refresh commands.

Reply to
a

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.