Articles, Blog

Memory Chip Organization Part 2 – Georgia Tech – HPCA: Part 4

Memory Chip Organization Part 2 – Georgia Tech – HPCA: Part 4

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.


these videos of your are badly tagged/SEOed they rarely appear in search unless searched specifically for udacity videos

Leave a Comment

Your email address will not be published. Required fields are marked *