5
\$\begingroup\$

I'm trying to understand how SDRAM hardware works if it also has ECC capability.

If a memory system has ECC capability it will be able to correct a single bit error in a block of memory and detect, but not correct, a multi-bit error. The way I understand it is that when the block of memory is read, the Error Correcting Code for that block is also read, and if there is a single bit flipped from what was originally written, it is automatically corrected by the memory controller.

Now SDRAM, by its nature, must refresh the data it holds or it will be corrupted over time. So it needs to read its memory cells and then rewrite the data back on a regular basis. From what I've read, this refresh read is slightly different from a regular memory read since it doesn't actually have to send data over the bus to the CPU so the refresh happens a whole bank at a time and just reads and writes the data back into the same cells without touching the bus.

My question is, does the ECC process come into play during the regular SDRAM refresh reads, or is that process bypassed in order to make the refreshes as fast as possible so that they won't tie up the memory system and inhibit regular memory accesses? If I have ECC SDRAM, do the single bit errors get automatically corrected on every refresh cycle or does the memory controller wait until an official memory access to detect and correct single bit errors?

Perhaps the answer might depend on the particular memory controller. I'm reading through the datasheet for an Intel 855GM/855GME Graphics and Memory Controller Hub to see if that particular controller does what I'm describing, but I haven't found an answer yet.

\$\endgroup\$

2 Answers 2

7
\$\begingroup\$

For starters, SDRAM Refresh does not technically move the data outside of the chip. At an academic level it is reading the data and writing the data back, but the SDRAM Data pins does not see that data-- it is done internally to the SDRAM chip itself. The SDRAM controller tells the SDRAM to do the refresh, but that is all that is seen externally.

ECC is done outside the SDRAM chip, in the SDRAM controller (usually located inside the CPU or chipset). There are also many different SDRAM controllers that support ECC, so it is hard to make general statements that are always correct. But I'll give it a shot.

When a memory location is read, and the data is corrupted but correctable, the corrected data is usually written back to RAM.

Some ECC controllers will use "inactive" time to read every memory location and, if there is a correctable error, write the corrected data back. The idea here is that this prevents a single bit error that is correctable from turning into an uncorrectable multi-bit error due to further "bit rot". There is a term for this feature that I am forgetting at this moment.

Reading every memory location is a nice idea, but on more modern computers this cannot be relied upon for effectively refreshing the SDRAM. Modern machines have a lot of memory and it takes a lot of time to read it. The built in refresh of the SDRAM chips works quite well. And doing this takes away valuable memory bandwidth from the CPU.

It is much better to just use the normal refresh, and then scan memory for errors in a low-priority task.

\$\endgroup\$
3
  • 3
    \$\begingroup\$ The term for continuously reading ECC memory to detect and correct single bit errors before it is too late is "memory scrubbing". \$\endgroup\$
    – Pentium100
    Jun 21, 2013 at 5:29
  • \$\begingroup\$ How hard would it be for an SDRAM device to incorporate its own ECC logic into its row read/write logic? Guarding 128 bits against a single bit failure would require 8 check bits (1/16 overhead); by contrast, one could guard 32768 bits against a single bit failure using only 16 check bits (1/2048 overhead); if one wanted to have e.g. 1/256 overhead, one could guard against arbitrary multi-bit failure; further, more scrubbing data on every refresh could reduce the likelihood of errors accumulating enough to be uncorrectable. \$\endgroup\$
    – supercat
    Jun 21, 2013 at 16:06
  • \$\begingroup\$ @supercat I have no idea how hard it would be to incorporate ECC into an SDRAM. My guess is that the larger the "block size", the harder it is to incorporate it. I also guess that this feature doesn't make business sense, otherwise it would have been done by now in an industry where everyone wants to differentiate themselves from the competition. \$\endgroup\$
    – user3624
    Jun 21, 2013 at 16:17
3
\$\begingroup\$

Refreshing the SDRAM has no effect on errors and cannot be used to help an ECC system; the two features are separate systems.

However the opposite may work; implementing a certain type of ECC scheme, you can also refresh the memory as a side effect, and switch off the "auto-refresh" logic. This means you can get a little more value from the "wasted" time spent refreshing the memory.

It uses the effect that opening a bank with RAS, (accessing it if you wish) then closing that bank ("precharging" it) has the same effect as refreshing that bank. For more details, read the memory datasheet (book!) paying attention to that topic.

So if you have a background process that accesses every bank of memory in turn, at least once every 64ms, then that process will also refresh memory without needing any additional refresh logic.

In the 1980s it was common for small systems to share DRAM between CPU and video, so that the video scanning would automatically refresh the memory for free!

Now a high integrity ECC scheme involves "scrubbing" memory - that is, reading and correcting errors as a background process, so that single bit errors cannot accumulate and develop into uncorrectable double-bit errors.

The background process is:
Open a bank; read and (if necessary) correct one or a few columns; close the bank; sleep for 8 us.
When that column has been scrubbed in every bank (in under 64 ms), increment the column address and start again.

Get the scheduling correct (8 us and 64ms are examples and your SDRAM may vary!) and this ECC scheme will also refresh your memory for free.

\$\endgroup\$
3
  • \$\begingroup\$ How long will it take to read out full opened rows ("read" step of process)? As ECC scheme is usually in DRAM controller of CPU SoC or in North Bridge, all read data to check ecc should go over memory bus (DDR*). Full readout on refresh will have more performance losses than classic refresh commands (without sending all data over bus). \$\endgroup\$
    – osgx
    May 25, 2018 at 2:42
  • \$\begingroup\$ Patrol memory scrubbing on servers with ECC memory will (if enabled in BIOS) do "Reading every cache line once a day to check for errors." and "If errors are found, the correct data is written back to memory" - psnow.ext.hpe.com/doc?id=4aa4-3490enw.pdf (2017). "DRAM Scrubber" for AMD with unknown frequency - amd.com/system/files/2017-06/… (configurable for 1-48 hours in gzhls.at/blob/ldb/0/5/f/a/… - "DRAM Scrub Time") \$\endgroup\$
    – osgx
    May 25, 2018 at 2:52
  • \$\begingroup\$ Time to read a full opened row is (a) too long and (b) completely irrelevant. In the scheme above, you would read (and very rarely write back) 1 word per refresh operation (= opening a row). In the linked schemes, which scrub about once a day, refresh and scrubbing must be entirely independent functions. \$\endgroup\$
    – user16324
    May 25, 2018 at 12:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.