If I'm doing my math right, each RAM chip only has two data pins attached to it. So you could cut the number of RAM chips in half (or even fewer) and still keep the same throughput.
In other words, these same ultra-fast buffer chips could be added to an otherwise normal module. Or you could put the transceivers from them into normal RAM chips. Having so many chips is for capacity reasons, not speed reasons. There's no need to have more "channels".
How does feature size and scaling of memory compare with logic? It looks like leading edge memory is made by three companies - Samsung, Hynix and Micron - no TSMC. Do they use EUV? Do they use ASML machines?
DRAM/NAND processes are optimized for different things than logic, so there isn't much cross application. My understanding is that it would be hard to make a general compute chip with a DRAM process due to a low number of metal layers, transistor types, etc. Micron [1] and Samsung have both investigated doing massively parallel compute in the memory cell, but the technology never panned out.
Regarding EUV, according to Micron's most recent quarterly report (March 20th) [2]
"We continue to mature our production capability with extreme ultraviolet lithography (EUV), and have
achieved equivalent yield and quality on our 1α as well as 1ß nodes between EUV and non-EUV flows. We
have begun 1γ (1-gamma) DRAM pilot production using EUV and are on track for volume production in
calendar 2025."
It's called "package on package". The RAM is different chip, however it's located very close to the CPU chip and both are under a single cover. The end result is a "package".
It's hard to tell because DRAM vendors talk about things like "1x nm" or "1a nm" but it sounds like they are still above 10 nm which is fairly far behind logic processes. DRAM typically sells for much cheaper than logic so they may not be able to invest as much as TSMC.
Consumer PCs aren't relevant here because they only use unbuffered DIMMs and cannot accept RDIMMs, LRDIMMs, MCRDIMMs, etc., which is part of why consumer desktops are limited to much lower memory capacities than servers. (The other limitation being the number of memory channels.)
Are you referring to the status quo of consumer PCs not supporting ECC memory, or the status quo of consumer PCs not supporting buffered memory of various flavors? Because AMD's not doing anything about the latter, and DDR5 made it even harder to support both buffered and unbuffered modules on the same platform.
5 columns of chips on each side indicates an extra 8 bits for each 32-bit subchannel, which is pretty common for DDR5 RDIMMs. But the article mentions a 72-bit interface (the standard for DDR5 ECC UDIMMs and earlier ECC DIMM standards) rather than an 80-bit interface, so there's at least some cause for doubt about which level of ECC these modules provide.
Sure, it is, but that doesn't explain how it works. Previous generations made it simple, they did SECDED ECC (or sometimes chipkill) one transfer at a time no matter what the transaction size was. DDR5 EC4 can't do that, so what does it do?
And does EC8 do SECDED one transfer at a time, or does it do something more resilient?
(And sure technically it's up to the memory controller to implement, but are different controllers doing different things with DDR5?)
AIUI, I don't think folks will be able to read the ECC values from these chips. They may/should silently fix issues but you won't be able to monitor the chips like you can with regular ECC RAM using tools like ras. So they may help with bit flips but won't help identifying bad sticks, I think.
The ECC used by buffered modules is the "regular ECC RAM" where the memory bus is widened (and chip count increased) to accommodate carrying the extra ECC information between the DRAM controller on the CPU and the memory modules, with the ECC calculations and corrections done on the CPU and errors surfaced to the firmware and/or OS, giving ECC protection not just for data at rest but also in transit. But the actual ECC bits computed, transferred and stored for each word of DRAM are never directly exposed to software to access.
There is also on-die ECC used by all recent DRAM as a consequence of shrinking memory cell sizes and spacing in the latest DRAM fabrication processes. That on-die ECC is what's unfortunately invisible to the host system, and only really useful for protecting data at rest, not in transit. The existence of on-die ECC has most commonly been publicized in the context of DDR5, but really has nothing to do with what DRAM interface standard is used because the on-die ECC happens entirely on each individual die.
