JEDEC Publishes Update to DDR5 SDRAM Standard Used in HPC Applications

[btarunr]

JEDEC Solid State Technology Association, the global leader in standards development for the microelectronics industry, today announced publication of the JESD79-5A DDR5 SDRAM standard. This update to the JEDEC DDR5 SDRAM standard includes features designed to enhance reliability and performance in a wide range of applications involving client systems and high-performance servers. JESD79-5A is now available for download from the JEDEC website.

Added features designed to meet industry demand for improved system reliability include bounded fault error-correction support, Soft Post-Package Repair (sPPR) undo and lock, Memory Built-In Self-Test Post Package Repair (MBIST and mPPR), Adaptive RFM, and an MR4 extension. JESD79-5A expands the timing definition and transfer speed of DDR5 up to 6400 MT/s for DRAM core timings and 5600 MT/s for IO AC timings to enable the industry to build an ecosystem up to 5600 MT/s. The nomenclature for core timing parameters and their respective definitions has been revamped to closely align with the upcoming JEDEC JESD400-5 DDR5 Serial Presence Detect (SPD) Contents V1.0 standard. The document can be accessed here.



"The fact that this update to DDR5 is being published so soon after the initial launch of DDR5 in July 2020 underscores JEDEC's ongoing commitment to continual improvement, and represents a collective effort on the part of all involved member companies to better serve the industry," said Mian Quddus, JEDEC Chairman.

Industry Support
"AMD is proud of our ongoing collaboration with JEDEC, driving the high-performance computing industry forward with powerful improvements to DDR5 features," said Joe Macri, Chief Technology Officer, Compute and Graphics Business Unit, AMD. "With the new JESD79-5A DDR5 standard, JEDEC offers the most advanced memory for high performance and reliability and continues our joint commitment to enabling the best possible experiences for end users."

"Intel is committed to advanced technology innovations that will greatly benefit the industry and our customers. DDR5 represents the next advancement in mainstream memory technology that will be featured in future client and server platforms. Working with our ecosystems partners and standards associations like JEDEC help end customers to accelerate adoption of new technologies and achieve breakthrough computing performance." said Carolyn Duran, VP - Data Platforms Group, GM - Memory and IO Technologies at Intel.

"Close collaboration is required to deliver the system-level reliability and scale-up performance that data-centric workloads demand from DDR5," said Frank Ross, lead architect at Micron. "Micron is proud to work with JEDEC and a broad ecosystem to advance memory standards that empower customers to turn their data into insights faster."

"This new update to DDR5 shows how the industry is committed to working together to build faster and more reliable memory solutions for the enterprise and client markets in a timely fashion," said Christopher Cox, Chairman of JC-42 Memory Committee and VP of Strategic Technologies at Montage Technology. "5G, Machine Learning, and AI are driving the computer industry's speeds and feeds at a staggering rate and the entire worldwide organization of JEDEC has come together to keep enhancing the DDR5 standard to meet those needs."

"Samsung is proud to see that DDR5 memory will be able to reach new heights in operating efficiency and self-correcting capabilities, something that we and other industry leaders have been working intently to standardize over the past 14 months," said Young-Soo Sohn, vice president of the DRAM Memory Planning/Enabling Group at Samsung Electronics. "With these enhancements, the industry is setting an extremely firm foundation for one of the most ambitious memory upgrades ever - an advancement particularly important for large server systems," he added.

"As new reliability features have now become part of the DDR5 standard, SK hynix is pleased to be able to provide a more robust memory solution to our customers. Furthermore, being able to deliver higher device speeds will bring the overall system performance to the next levels. SK hynix has been providing DDR5 DIMM samples to the industry since 2019 for ecosystem readiness, and will continue to actively participate in future JEDEC activities for continued open innovation and ecosystem enabling," said Uksong Kang, Head of DRAM Product and Planning at SK hynix.

View at TechPowerUp Main Site

 

[RoutedScripter]

Hopefully also for HEDT, especially the ECC fault protection stuff that Linus ranted rightfully about. I think I heard it'll be standard for all DDR5 (except perhaps low end)

 

[ncrs]

Hopefully also for HEDT, especially the ECC fault protection stuff that Linus ranted rightfully about. I think I heard it'll be standard for all DDR5 (except perhaps low end)

DDR5 mandates on-chip ECC, which is not the same technology as "normal" ECC. There will be DDR5 ECC and non-ECC sticks just like DDR4.

 

[RoutedScripter]

DDR5 mandates on-chip ECC, which is not the same technology as "normal" ECC. There will be DDR5 ECC and non-ECC sticks just like DDR4.

Yeah I later read about that, darn it, what an epic example of corporate and media misinformation and fake news.

I hope at least this will lead to more sub-segmentation into the higher end offerings for FULL ECC support, If enough people show interest and pressure reviewers to set up test benches to get FULL ECC reviewed, that might spark something.

I think now that more sub-categories of ECC moinker start to be included in the conversation, I don't think it's of any worth to stay with the old nomenclature of just "ECC". That could have been done before, but now we should be calling them by their respective category descriptors for clarification, even if the industry it self doesn't do it, they don't really care about naming or clarity, they don't have a profit from clairty, they profit more from confusion, so who cares what they officially call it in some proprietary standard "MAZ-13aef69bc.v01".

The FULL ECC thing is also relative to the context still, so it may not mean the same if we include a system-wide viewpoint in the future.
What about system wide, then transport between RAM-VRAM, CPU-VRAM, STORAGE-VRAM .... since it's "just" texture data I guess it won't matter much, "all" you would get is some corruption on screen, no? (but aren't there file's headers and other pointers/addresses/metadata and other things that could make bugs/exceptions larger than just a wrong color on a pixel); on the other hand GPUs aren't only for games and textures these days.

CPU-STORAGE should have already had ECC anyway, no? Sata? NVME ? I'd be surprised if they don't, that be a disaster for critical OS file stability, installations, etc, I never looked into this to make sure for some reason.

 

[ncrs]

Yeah I later read about that, darn it, what an epic example of corporate and media misinformation and fake news.

I hope at least this will lead to more sub-segmentation into the higher end offerings for FULL ECC support, If enough people show interest and pressure reviewers to set up test benches to get FULL ECC reviewed, that might spark something.

The problem with "full ECC" is that it requires more complex motherboards and modules. This has been deemed unneeded for the consumer market (thanks Intel).

I think now that more sub-categories of ECC moinker start to be included in the conversation, I don't think it's of any worth to stay with the old nomenclature of just "ECC". That could have been done before, but now we should be calling them by their respective category descriptors for clarification, even if the industry it self doesn't do it, they don't really care about naming or clarity, they don't have a profit from clairty, they profit more from confusion, so who cares what they officially call it in some proprietary standard "MAZ-13aef69bc.v01".

It is defined in the JEDEC standard, but as you said the marketing departments will twist it.

The FULL ECC thing is also relative to the context still, so it may not mean the same if we include a system-wide viewpoint in the future.
What about system wide, then transport between RAM-VRAM, CPU-VRAM, STORAGE-VRAM .... since it's "just" texture data I guess it won't matter much, "all" you would get is some corruption on screen, no? (but aren't there file's headers and other pointers/addresses/metadata and other things that could make bugs/exceptions larger than just a wrong color on a pixel); on the other hand GPUs aren't only for games and textures these days.

CPU-STORAGE should have already had ECC anyway, no? Sata? NVME ? I'd be surprised if they don't, that be a disaster for critical OS file stability, installations, etc, I never looked into this to make sure for some reason.

Most internal buses have some sort of error correction in them. For example PCI Express has multiple layers of error detection and correction. Same with SATA/AHCI. Storage devices use very sophisticated methods, especially for SSDs which are inherently unreliable internally due to the nature of very small NAND.
As for ECC on GPUs this is again a segmentation strategy. The mainstream devices are designed to be used mainly for gaming, while still being capable of compute, so increased cost and complexity of ECC doesn't make sense. Especially for quantity-limited GDDR6X used by Nvidia. Simply speaking making them ECC would reduce availability, for very little real-world benefit.