Spartan 6 MCB refresh timing

Hi there,

I'm designing a memory solution with a Spartan 6 talking to 2 128MByte

16-bit-wide DDR3 RAMs. As my application is timing critical I can most probably not use auto refresh, so my question is how long the refresh command issued to the MCB takes and which parameters do influence this timing parameter.

regards Stefan Huebner

Reply to
Stefan Huebner
Loading thread data ...

While you're pondering, check the data sheet carefully: the old 4116 style DRAM would refresh on _any_ access (either row or column, I can't remember which); so all you had to do was cycle through the correct subset of memory and you'd never have to do an explicit refresh.

But: I dunno if SDRAM does that.

--
My liberal friends think I'm a conservative kook. 
My conservative friends think I'm a liberal kook. 
 Click to see the full signature
Reply to
Tim Wescott

Yes. Especially convenient if the RAM was used for both video display and computer memory, as the raster scan would get through all rows (or columns).

I am pretty sure it is true of all DRAM forms if you can find out the refresh pattern.

DRAM does a destructive read, so it has to rewrite after read.

The usual geometry reads the data from one column (I believe) into a register, gives you the bit(s) from the appropriate row, then writes back the whole column.

In the 4116 days it was really a whole column. Now, at higher densities, it is usually closer to an array of much smaller squares, each of which has rows and columns.

If you can't be sure of the access pattern, though, you have to refresh.

-- glen

Reply to
glen herrmannsfeldt

Refresh is by row, not column, but otherwise as Glen says. For SDRAM there are multiple "banks" which behave like multiple chips, i.e. any access refreshes a row from the selected bank only. Auto-refresh refreshes one row of each bank using an internal row counter. DDR SDRAM added a condition that you must run auto-refresh at a minimum rate so the chip can use this time to update its DLL while the data lines are not active. Micron says its chips don't really need this, but it's in the JEDEC spec, so memory controllers generally abide by it. By the way, you don't actually need to read or write to refresh a row, the minimum requirement is just row activate followed by row precharge.

My first question would be why are you using DDR3 for a random-access application? Do you really need the 128 MBytes? If you're only using a small portion of the memory, you might want to think of using a static RAM, or even a single-data-rate SDRAM, which is much simpler to interface and wouldn't require the MCB or SSTL I/O. Otherwise I think you're going to need to spend a lot of time with the simulator finding out how the MCB works at a level lower than what you read in the documents.

-- Gabor

Reply to
Gabor

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.