Spartan 6 MCB refresh timing

[Stefan Huebner]

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

 

[Tim Wescott]

On Wed, 10 Oct 2012 00:33:28 +0200, Stefan Huebner wrote:

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

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.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

 

[glen herrmannsfeldt]

Tim Wescott <tim@seemywebsite.com> wrote:

On Wed, 10 Oct 2012 00:33:28 +0200, Stefan Huebner wrote:

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.

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.

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).

But: I dunno if SDRAM does that.

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

 

[Gabor]

glen herrmannsfeldt wrote:

Tim Wescott <tim@seemywebsite.com> wrote:
On Wed, 10 Oct 2012 00:33:28 +0200, Stefan Huebner wrote:

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.

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.

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).

But: I dunno if SDRAM does that.

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

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