Do you need DDR4 Write CRC?

A customer asked us, “Do I need DDR4 write CRC beyond a certain frequency?”

The answer is far from simple; it’s dependent on many factors including the type of system it is, the other types of error correction (ECC) that may be in use, the system’s tolerance of errors, and the system’s ability to spare the bandwidth required for the write CRC function. Since I’ve been asked a few times and since the answer is so complex, I created the flowchart here to show some paths through the possible choices.

Write CRC was added to the JEDEC Standard for DDR4 (JESD79-4), the first time that DDR had any kind of function like this. The basic premise is that the SoC memory controller generates a Cyclical Redundancy Check (CRC) code from the data transmitted in a write burst and then transmits that CRC code following the data. The CRC code received from the memory controller is not stored in the DRAM, rather, the DRAM checks the CRC code it received against the data that the DRAM received; if there’s a mismatch detected then the DRAM asserts the ALERT_n pin shortly after the write, indicating that a problem has occurred. The system may then choose to retransmit the data or follow some error recovery procedure (Synopsys’s uMCTL2 memory controller can automatically retry the write transaction).

Write CRC can consume up to 25% of the total write bandwidth in the system, making it a rather “expensive” function. Many people wonder if it’s worth it. There’s a much longer discussion required on why and how it’s been implemented, but instead of making a really long blog post, here is the summary in “a picture is worth a thousand words” format! Please click on the image to fully expand it.

For more information on DDR4 RAS (Reliability, Availability, Serviceability) topics, please check out my whitepaper at https://www.synopsys.com/dw/doc.php/wp/ddr_ras_for_memory_interfaces_wp.pdf