> There's also the concern that DDR memory must have a very high level of data integrity, bit-flip errors are severely problematic, and it can't wear out even after trillions of cycles. Flash has more pervasive error correction, and while wear is a minor concern, it's still possible to exhaust it if you really, really try.
The reason why we can't do the pervasive and extremely aggressive error correction [1] that is used in flash storage to increase usable densities with DRAM is that forward error correction (FEC) is based on blocks, so to read a couple bytes from a block you will have to read the entire block [2], decode it and then you can have your bytes.
This does not work well for RAM ®
Memory fetching is fundamentally based on cache lines; but the overhead in both bandwidth and latency(!) to fetch-and-decode, say, 64K instead of 64 bytes would be completely unacceptable in most applications.
[1] It's one of the major factors contributing to device endurance.
[2] Simplification: Practical FEC is multi-tiered, ie. there are different block sizes involved and multiple layers of EC at these block sizes.
You cannot do this kind of error correction it like ECC checking in the CPU because it would require multiple clocks or too many pins.
You cannot do this kind of error correction across multiple DRAM chips on board because it would require too many pins.
But you could do this kind of error correction on-chip because you could just read 1024 bits (or more) in parallel from multiple areas (or even mutliple stacked silicon slices).
One problem, however, is that each small read would induce a high energy cost due to the many bits fed into the extensive error correction circuitry. While it shouldn't be a problem for consecutive reads, random-access would indeed lead to a high power consumption which in most cases would not be acceptable.
The reason why we can't do the pervasive and extremely aggressive error correction [1] that is used in flash storage to increase usable densities with DRAM is that forward error correction (FEC) is based on blocks, so to read a couple bytes from a block you will have to read the entire block [2], decode it and then you can have your bytes.
This does not work well for RAM ®
Memory fetching is fundamentally based on cache lines; but the overhead in both bandwidth and latency(!) to fetch-and-decode, say, 64K instead of 64 bytes would be completely unacceptable in most applications.
[1] It's one of the major factors contributing to device endurance. [2] Simplification: Practical FEC is multi-tiered, ie. there are different block sizes involved and multiple layers of EC at these block sizes.