Anyone know if we will see CUDIMM technology in the server dimm space ?
CU-DIMMs are buffering the clock signal, but not the command, address, and data signals. (Because that would add latency, and BOM cost obviosuly.)
On the R-DIMMs used in server space, clock, command, and address signals are buffered. LR-DIMMs buffer the data signals in addition. FB-DIMMs do so too but have a different bus with fewer pins per module. That is, R-, LR-, and FB-DIMMs' features are a superset of CU-DIMMs'.
The motive for clock buffering on CU-DIMMs is to achieve higher data bus speeds, at same latencies and capacities. The motive for the more extensive buffering on R-DIMMs is to allow for larger memory capacity per module and for more memory slots per processor socket, while maintaining quite high data rates but sacrificing a little WRT latency. (LR-DIMMs and FB-DIMMs exist for even larger memory capacity than R-DIMMs.)
In other words:
CU-DIMM is a cherry-picked feature from R-DIMMs. You won't ever see CU-DIMMs in regular servers due to their constraints with respect to channel count and memory capacity whuch U-DIMMs and CU-DIMMs have in common. Small-socket servers (Intel Xeon-E, but not EPYC 4004 and 4005) which are limited to U-DIMMs presently could technically adopt this technology. But will that happen? I don't know. ECC CU-DIMMs would be a niche within a niche.
Edit:
Socket SP5, and thus Turin, supports R- and LR-DIMMs only. I don't know if it is technically possible to make an SP5 board with only about 4 DIMM slots in order to use unregistered DIMMs. If so, nobody is going to make such a board. And even so, the IMCs in the Turin I/O die wouldn't support the high data rates which CU-DIMMs enable anyway.
Edit 2:
EPYC 4004 (and if it is brought to market, EPYC 4005) in socket AM5 is not going to adopt CU-DIMM technology either, because the client I/O die in them does not support such speeds either. AMD is not going to make a new I/O die in the Zen 5 generation anymore (except for the Strix Halo mobile CPU). And even if AMD changed the IMCs in the I/O die to support higher data rates, they also would likely have to change the IFOP and the CCDs too for higher data rates on their side. Technically, they could change the client I/O die to support "wide GMI" with existing CCDs. But I am sure they won't bother anymore, before first Strix Halo and then Zen 6 move to different packaging technology.