---
title: "잠든 DRAM을 깨운 뒤 바로 읽지 못하는 이유"
author: "브레이브브라우저쓰자"
published_at: "2026-10-08T04:58:04.740Z"
updated_at: "2026-10-05T23:29:40.379Z"
tags: ["self refresh exit"]
canonical_url: "https://ariser.io/@writer_a9817d5a8de0/%EC%9E%A0%EB%93%A0-dram%EC%9D%84-%EA%B9%A8%EC%9A%B4-%EB%92%A4-%EB%B0%94%EB%A1%9C-%EC%9D%BD%EC%A7%80-%EB%AA%BB%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0"
ai_assisted: true
---

# 잠든 DRAM을 깨운 뒤 바로 읽지 못하는 이유

이 글은 AI가 활용됐습니다.

[원문](https://ariser.io/@writer_a9817d5a8de0/%EC%9E%A0%EB%93%A0-dram%EC%9D%84-%EA%B9%A8%EC%9A%B4-%EB%92%A4-%EB%B0%94%EB%A1%9C-%EC%9D%BD%EC%A7%80-%EB%AA%BB%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0)

대기 전력을 줄이려고 DRAM을 Self Refresh에 넣었다. 프로세서가 다시 일을 시작할 때 CKE를 올렸는데, controller는 곧바로 READ를 보내지 않는다. 저장 정보가 이미 보존돼 있으니 바로 꺼내도 될 것 같지만, 데이터 보존과 고속 외부 인터페이스의 준비는 서로 다른 상태다. Self Refresh Exit 지연은 이 둘을 다시 연결하는 시간이다.

Self Refresh 동안 DRAM은 내부 timer로 저장 전하를 관리한다. 외부 clock을 계속 받아 일반 요청을 처리하는 상태와 달리 내부 clock 경로와 출력 timing에 필요한 회로가 쉬고 있을 수 있다. 따라서 나오는 절차에는 진행 중이던 내부 refresh 완료, clock 안정, DLL 재동기화가 포함된다. DLL은 외부 clock과 내부 출력 timing의 관계를 맞추는 회로다.

[Alliance DDR4 데이터시트 43~44쪽의 Self Refresh Operation](https://www.alliancememory.com/wp-content/uploads/AllianceMemory_8Gb_DDR4_AS4C1G8D4A-62BIN-62BCN_Datasheet_ver1.1_-Aug-2025-1.pdf)은 명령을 locked DLL이 필요한 경우와 그렇지 않은 경우로 나눈다. ACT 등의 대기 기준은 tXS이고 READ에는 tXSDLL이 적용된다. 이 구분을 빼면 깨우기 지연을 과소평가하거나 모든 명령을 불필요하게 늦출 수 있다.

## 행 준비와 첫 데이터 준비는 동시에 끝나지 않는다

다음은 제품 설정을 권하는 값이 아니라 차이를 분리한 가상 시간선이다. 안정된 clock에서 SRX를 0ns에 등록하고 tXS=360ns, tXSDLL=600ns, tRCD=14ns, CL=14clock, tCK=1ns, AL=0이라고 하자. 대상 bank가 닫혀 있고 다른 제한이 없다고 놓는다.

ACT를 360ns에 보내면 행 준비는 374ns에 끝날 수 있다. 그래도 READ는 DLL 조건 때문에 600ns까지 기다린다. 첫 데이터 후보는 614ns다. 계산은 다음처럼 두 조건의 최대값을 취한다.

`READ 후보 = max(SRX+tXSDLL, ACT+tRCD)`

반대로 행 준비가 늦어 ACT가 595ns에 발행됐다면 READ는 max(600,609)=609ns 이후가 된다. tXSDLL을 만족했다고 tRCD까지 생략할 수는 없다. 같은 식이 두 준비 경로를 나란히 보여 준다.

| 가상 상황 | ACT | 행 준비 완료 | READ 후보 | 첫 데이터 후보 |
|---|---:|---:|---:|---:|
| 행 준비를 먼저 시작 | 360ns | 374ns | 600ns | 614ns |
| 다른 이유로 ACT가 늦음 | 595ns | 609ns | 609ns | 623ns |

데이터시트의 실제 값에는 nCK와 ns 조건이 함께 들어갈 수 있다. 표의 600ns를 어떤 제품에 그대로 적용하면 안 된다. 여기서는 controller가 기다려야 할 조건들의 결합만 계산했다.

## 빨리 나오는 mode에도 남는 의무

Self Refresh Abort는 진행 중인 내부 refresh를 중단해 DLL lock이 필요 없는 명령의 출발을 앞당길 수 있다. 그러나 이것을 모든 READ의 깨우기 지연을 삭제하는 기능으로 이해하면 안 된다. locked DLL이 필요한 경로의 조건은 여전히 별도로 확인해야 한다. 문서는 재진입 전에 필요한 추가 refresh도 설명한다. 지금의 대기를 줄이는 선택이 이후 관리 작업까지 없애지는 않는다.

전압이나 온도가 변했다면 I/O 보정도 검토해야 한다. Self Refresh에서 나왔다는 사실만으로 새 조건에 맞는 ZQ calibration이 자동으로 수행되는 것은 아니다. calibration을 DLL 대기와 겹칠 수 있는 경우에도 시작 허용점과 quiet time을 따로 지켜야 한다.

또한 SRX의 0ns는 clock을 켠 순간이 아니다. clock이 안정된 뒤 필요한 선행 조건을 만족하고 exit를 등록한 순간이다. 시스템 resume latency를 측정한다면 oscillator 또는 PLL의 준비 시간, controller 복원과 초기 명령을 포함해야 한다. DRAM의 tXSDLL 하나로 전체 resume 시간을 설명할 수 없다.

## 잠들어 있을 시간과 깨우기 비용을 함께 비교하기

전력 정책은 쉬는 동안 아낀 에너지와 entry·exit 비용을 비교해야 한다. 짧은 idle 구간마다 Self Refresh에 들어가면, 절전 구간보다 깨우기 과정이 자주 반복될 수 있다. 반대로 충분히 긴 대기에서는 같은 exit 비용이 전체 에너지에서 작은 비중이 된다. 실제 판단에는 대기시간 분포와 첫 요청의 지연 요구가 필요하다.

Self Refresh Exit를 디버깅할 때는 SRX, 명령 종류별 허용점, ACT, READ, 첫 데이터를 한 줄씩 적자. 저장 상태는 유지됐지만 인터페이스는 아직 준비 중이라는 차이가 드러난다. 깨운 DRAM에서 바로 읽지 못하는 이유는 데이터가 사라졌기 때문이 아니라, 그 데이터를 정해진 timing으로 전달할 경로가 다시 안정돼야 하기 때문이다.