So is the Row buffer's purpose to be a fast-access cache at the DRAM level?
Fantasy
I am not ECE/EE major, so my answer may be inaccurate. Personally, I think the main reason why there is a row buffer is that we need a way to get the result out of the memory chip. Row buffer saves the result of the row we selected. It just happens to have an effect of cache as well.
PIC
There's an interesting problem with DRAM which causes arbitrary lines to be corrupted simply by reading and writing. A professor here wrote a paper about it.
@Calloc @Fantasy The design of row-buffer indeeds utilizes locality and hopes to save access time with this cache-like buffer. On a memory read, the row-buffer loads an entire page from DRAM (a DRAM page, maybe larger than the OS page size) and that page is opened until explicitly closed if another read on a different page occurs.
mrrobot
Does read from capacitors to row buffer also destroy the charge on the original cells or do we write-back to the cells only in the case of writes?
jrgallag
@mrrobot It was mentioned in lecture that reading is destructive, necessitating a write back into the original row. This adds some additional latency when swapping out the row buffer.
jhibshma
Is the fact that we load all the bits in a row meant as an optimization for locality or is it due more to what's easy/hard to make in hardware?
Given that we generally use virtual memory, does this mean that some virtual memory systems need to be designed with DRAM physical locality in mind?
How long does the pre-charge last? Because it looks like by reading from the same row, we save not only row selection, but also on precharge. But how long can we make use of the precharge?
randomized
@fleventyfive: Same question here. Any answer?
emberspirit
@fleventyfive If the next read is from the same row, it would basically skip the step 1 and 2 in the previous slide (which is total of 18 cycles), and since this lecture makes no other specific assumptions about the hardware aspect of "precharge" (whether it would automatically "decharge" after certain amount of cycles), I think it's kind of safe to assume that the precharge is valid until a read from another row.
So is the Row buffer's purpose to be a fast-access cache at the DRAM level?
I am not ECE/EE major, so my answer may be inaccurate. Personally, I think the main reason why there is a row buffer is that we need a way to get the result out of the memory chip. Row buffer saves the result of the row we selected. It just happens to have an effect of cache as well.
There's an interesting problem with DRAM which causes arbitrary lines to be corrupted simply by reading and writing. A professor here wrote a paper about it.
http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
@Calloc @Fantasy The design of row-buffer indeeds utilizes locality and hopes to save access time with this cache-like buffer. On a memory read, the row-buffer loads an entire page from DRAM (a DRAM page, maybe larger than the OS page size) and that page is opened until explicitly closed if another read on a different page occurs.
Does read from capacitors to row buffer also destroy the charge on the original cells or do we write-back to the cells only in the case of writes?
@mrrobot It was mentioned in lecture that reading is destructive, necessitating a write back into the original row. This adds some additional latency when swapping out the row buffer.
Is the fact that we load all the bits in a row meant as an optimization for locality or is it due more to what's easy/hard to make in hardware?
Given that we generally use virtual memory, does this mean that some virtual memory systems need to be designed with DRAM physical locality in mind?
Relevant!
row-buffer hit (typically less than ten processor cycles) - See more at: http://www.futurechips.org/chip-design-for-all/what-every-programmer-should-know-about-the-memory-system.html#sthash.nFg5chtT.dpuf
How long does the pre-charge last? Because it looks like by reading from the same row, we save not only row selection, but also on precharge. But how long can we make use of the precharge?
@fleventyfive: Same question here. Any answer?
@fleventyfive If the next read is from the same row, it would basically skip the step 1 and 2 in the previous slide (which is total of 18 cycles), and since this lecture makes no other specific assumptions about the hardware aspect of "precharge" (whether it would automatically "decharge" after certain amount of cycles), I think it's kind of safe to assume that the precharge is valid until a read from another row.