𝗘𝗖𝗖 │ 읽은 값은 고쳤는데, DRAM은 왜 그대로일까?
ECC corrected read versus stored-codeword repair and on-the-fly/background scrubbing
DDR의 correctable ECC 오류 카운터가 올라갔습니다. 그런데 CPU가 읽은 데이터는 정상입니다. 이때 “ECC가 고쳤으니 메모리도 복구됐다”고 판단해도 될까요?
ECC에는 두 동작이 있습니다. 첫째는 read path에서 오류를 정정해 요청자에게 정상 데이터를 돌려주는 것. 둘째는 손상된 주소에 정정된 데이터와 ECC를 다시 써서 저장 상태를 복구하는 scrubbing입니다. 첫째가 일어났다고 둘째까지 실행됐다는 뜻은 아닙니다.
한 ECC codeword에서 D[5] 한 bit가 뒤집혔다고 가정해 보겠습니다. SECDED가 이 오류를 정정하면 이번 read 결과는 정상입니다. 하지만 scrub이 꺼져 있는 컨트롤러라면 저장된 codeword에는 여전히 D[5] 오류가 남습니다. 같은 위치를 다시 읽을 때도 정정이 필요할 수 있습니다.
그 상태에서 같은 codeword의 다른 bit까지 뒤집히면 상황이 달라집니다. SECDED가 보장하는 것은 1-bit 정정과 2-bit 검출입니다. 두 오류가 쌓이면 읽는 쪽에서 정상값으로 복구할 수 없습니다. 그래서 “정정된 read data”와 “복구된 메모리”를 구분해야 합니다.
On-the-fly scrub을 지원하고 켜 둔 컨트롤러는 correctable read 오류를 발견하면 해당 주소에 read-modify-write(RMW)를 수행해 복구합니다. Background scrub은 소프트웨어가 오랫동안 읽지 않는 주소도 순회하며 점검합니다. 다만 두 기능의 지원 범위와 실행 시점은 컨트롤러 설정에 따라 다르고, scrub 자체도 메모리 접근을 사용합니다.
리뷰할 때는 ECC enable만 보지 말고 세 가지를 확인합니다. 정정된 read data가 반환되는가? 정정 뒤 writeback이 실제로 수행되는가? 한동안 읽지 않는 주소까지 background scrub이 도는가? 그리고 ECC가 적용되는 메모리 영역은 최초 read 전에 유효한 ECC와 함께 초기화됐는지도 확인해야 합니다.
AMD의 Zynq-7000 DDR 컨트롤러 문서는 correctable read에서 정정 데이터를 반환하지만, DRAM으로의 RMW는 scrubbing이 켜졌을 때만 수행한다고 명시합니다. DDR5 컨트롤러 문서도 on-the-fly와 background scrub의 동작을 따로 설명합니다. 설계 중인 IP의 문서와 오류 주입 결과로 두 경로를 각각 확인하는 게 안전합니다.
근거: AMD UG585, ECC Error Behavior (2026); AMD PG456, ECC Scrubbing (2026).
https://docs.amd.com/r/en-US/ug585-zynq-7000-SoC-TRM/ECC-Error-Behavior
https://docs.amd.com/r/en-US/pg456-integrated-mc/ECC-Scrubbing