So we just described how to read a row into the sense amplifier and
the row buffer, and then get 1 bit out of that row.
So let's suppose that the bits we had here were 1 0 1 1,
and let's say this was DRAM, so these bits drained into the bitline.
The sense amplifier amplifies them, outputs here 1 0 1 1, 1.
The row buffer now stores this value and starts outputting it here.
Let's say that the column address finally selects this bit to the output.
So we output a 0.
Remember, that DRAM reads are destructive.
Once we do that, we no longer have our bits here.
So what needs to be done is, after the sense amplifier determines what
the correct values of the bits are, and the cells by now have been exhausted,
we reverse the direction, and raise each of the bit lines to its proper value.
So now the sense amplifier is driving this correct values back into the cells,
and the cells get their values again.
So destructive reads from DRAM means that,
really, we have to read and then write each cell.
So we cannot just wait long enough to get the value,
we also have to wait long enough to put the value back in the cell.
This is one of the reasons why DRAM is slower than SRAM.
Another reason, of course,
is that the cell does not as strongly pull the bitline, so
the sense amplifier needs more time to figure out what it has.
After this read and then write approach,
the cells have the correct values for 1011, and have been refreshed.
Even if they have reduced to, let's say 90% of what they should have,
once we read them out and put it back in, we put back in the full value.
So now they can again leak for
awhile before we need to read and then write them again.
So refresh, is really,
to make sure that each of the rows is red every once in a while.
If the time for the cell to lose the value enough so
that we cannot recover it is some sort of time,
t, then every row needs to be read and then written within the time t.
A destructive read, and then a write, will refresh the row.
But we cannot rely on the processor to access every row in the memory so
that we don't have to do anything else.
In fact, when you have caches, it often happens that some rows that are very
popular, and accessed by the processor all the time,
are actually the ones that don't get refreshed this way.
And the reason is that those become cache hits, and
the cache keeps keeping that data because the processor wants it so often.
So we end up actually not accessing the memory for
things that the processor is accessing the most often.
So we can not even rely on the program to go through the whole memory.
So what needs to happen for refresh is that we have this refresh row counter.
It starts at 0, we use it to refresh this row, then it moves to 1.
We then use it to refresh this row, and so on.
If a row needs to be refreshed within some refresh period, let's say t,
and we have n rows, then every t over n seconds
we have to refresh one row, so that by the time we are done,
we are ready to refresh again, a row, which would only last for a period of t.
Modern DRMs have a lot of rows, and the refresh period is well under a second.
So we're actually seeing a lot of refreshes happen every second.
This is not something that happens occasionally.
This actually significantly interferes with when we can read and
write our memory.
because, while a refresh is going on, we cannot do a useful read, because the row
decoder, sense amps, and the row buffer are used by the refresh operation,
which is reading a row that we didn't need, and writing it back.
Meanwhile, we have to sit and wait with our real read until that gets done so
that we can move on.