---
title: "DRAM 쓰기 데이터가 들어갔다고 셀이 다 기록된 것은 아니다"
author: "브레이브브라우저쓰자"
published_at: "2026-10-06T13:30:03.017Z"
updated_at: "2026-10-05T14:05:13.286Z"
tags: ["twr"]
canonical_url: "https://ariser.io/@writer_a9817d5a8de0/dram-%EC%93%B0%EA%B8%B0-%EB%8D%B0%EC%9D%B4%ED%84%B0%EA%B0%80-%EB%93%A4%EC%96%B4%EA%B0%94%EB%8B%A4%EA%B3%A0-%EC%85%80%EC%9D%B4-%EB%8B%A4-%EA%B8%B0%EB%A1%9D%EB%90%9C-%EA%B2%83%EC%9D%80-%EC%95%84%EB%8B%88%EB%8B%A4"
ai_assisted: true
---

# DRAM 쓰기 데이터가 들어갔다고 셀이 다 기록된 것은 아니다

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

[원문](https://ariser.io/@writer_a9817d5a8de0/dram-%EC%93%B0%EA%B8%B0-%EB%8D%B0%EC%9D%B4%ED%84%B0%EA%B0%80-%EB%93%A4%EC%96%B4%EA%B0%94%EB%8B%A4%EA%B3%A0-%EC%85%80%EC%9D%B4-%EB%8B%A4-%EA%B8%B0%EB%A1%9D%EB%90%9C-%EA%B2%83%EC%9D%80-%EC%95%84%EB%8B%88%EB%8B%A4)

쓰기 명령을 보냈고 데이터도 DRAM pin으로 모두 넘어갔다. 곧 다른 행을 읽어야 한다면 지금 행을 닫고 싶다. 이때 tWR을 WRITE 명령 시각부터 세면 너무 일찍 닫는 일정이 만들어질 수 있다. tWR은 쓰기 명령이 도착한 뒤 막연히 기다리는 시간이 아니라, 마지막 쓰기 데이터 이후 셀에 기록 상태를 충분히 남기는 write recovery 시간이다.

WRITE 명령과 쓰기 데이터는 동시에 들어가지 않는다. 명령 뒤 write latency를 기다린 다음 데이터 burst가 시작된다. DDR은 clock의 양쪽 edge에서 데이터를 보내므로 burst length가 8이면 전송 구간은 기본적으로 4clock이다. 이 데이터가 들어간 뒤에도 내부 bitline과 셀을 최종 저장 상태로 만드는 시간이 필요하다.

## 명령 완료와 기록 완료 사이

[AL-DRAM 원 논문 2.2절](https://people.inf.ethz.ch/omutlu/pub/adaptive-latency-dram_hpca15.pdf)은 WRITE 뒤 추가 셀 복원 시간을 tWR과 연결한다. [Alliance DDR4 데이터시트의 Write Burst Operation과 그림 139 주석](https://www.alliancememory.com/wp-content/uploads/AllianceMemory_8Gb_DDR4_AS4C1G8D4A-62BIN-62BCN_Datasheet_ver1.1_-Aug-2025-1.pdf)은 tWR과 tWTR의 기준을 마지막 write data 뒤 첫 rising clock edge로 명시한다. “마지막 데이터 뒤”를 얼핏 같은 뜻으로 사용해도 어느 clock edge에서 세는지는 실제 schedule에 중요하다.

PRE를 보내면 해당 행이 bitline에서 분리되고 다음 행을 위한 precharge가 시작된다. 너무 빠른 PRE는 데이터를 전달받은 뒤 충분히 저장시키는 구간을 잘라 낸다. 특히 시험에서 즉시 읽은 값만 정상이라고 확인했다면, 이후 보존 여유가 줄어드는 영향을 놓칠 수 있다. 외부 전송 성공이 모든 내부 저장 상태의 완료를 증명하지는 않는다.

## 가상 쓰기 일정에서 빠진 시간을 찾기

clock period 1ns, AL=0, CWL=10clock, BL8, tWR=12ns인 가상 조건을 쓰자. CRC와 추가 명령 latency는 없고 write preamble은 기본 조건으로 단순화한다. WRITE를 20ns에 보냈다면 첫 데이터 구간은 30ns부터 시작한다. 8beat가 4clock을 차지하므로 마지막 데이터 뒤 recovery를 세는 rising-edge 기준점은 34ns다. 가장 이른 PRE 후보는 34+12=46ns가 된다.

WRITE 시각부터 tWR만 더하면 32ns가 나온다. 이때는 쓰기 burst가 아직 진행 중이다. CWL을 포함하고도 BL/2를 빠뜨리면 42ns로 계산해 4ns를 놓친다. 올바른 구조는 이 단순 조건에서 다음과 같다.

WRITE→PRE 최소 간격 = CWL×tCK + (BL/2)×tCK + tWR

| 놓친 항목 | 가상 PRE 후보 | 문제 |
|---|---:|---|
| CWL과 burst 모두 누락 | 32ns | 데이터 전달 중 행 닫기 |
| burst만 누락 | 42ns | recovery 기준점을 잘못 잡음 |
| latency·burst·recovery 포함 | 46ns | 세 항목을 포함한 후보 |

46ns가 무조건 최종 정답도 아니다. ACT→PRE minimum인 tRAS가 50ns까지 행을 유지하도록 요구했다면 PRE는 50ns 이후여야 한다. 명령이 들어갈 clock edge와 다른 제약도 함께 적용한다. 실제 제품에서 CRC, preamble, AL 같은 모드를 바꾸면 관련 timing 식과 mode-register setting도 원문에 따라 다시 확인해야 한다.

## tWR과 tWTR을 같은 대기시간으로 읽지 않기

tWR은 쓰기 뒤 행을 닫기 위한 조건이다. tWTR은 쓰기에서 읽기로 넘어갈 때의 조건이며 bank group 관계 등에 따라 적용 값이 달라질 수 있다. 두 값이 같은 기준 edge 근처에 표시된다고 목적이 동일한 것은 아니다.

다른 bank를 읽고 싶어도 공유 경로의 write-to-read 조건은 남을 수 있다. 반대로 현재 행을 닫는 것이 아니라 같은 방향 WRITE를 이어 가는 schedule에는 다른 column 간격 규칙이 먼저 중요하다. “write 다음에는 항상 tWR만큼 모든 동작을 쉬어야 한다”는 식으로 해석하면 합법적인 병렬 작업까지 막는다.

write recovery를 줄이면 다른 행으로 넘어가는 준비가 빨라질 수 있지만, 기록할 충분한 전하와 제품 timing margin을 함께 확인해야 한다. 특정 온도·모듈에서 관측한 여유를 모든 셀·온도의 보증으로 바꿀 수 없다. vendor minimum을 유지한 스케줄 개선과 minimum 자체를 바꾸는 실험은 요구하는 검증이 다르다.

쓰기 뒤 지연을 해석할 때 가장 먼저 표시할 것은 마지막 데이터 이후의 규정된 기준 edge다. 그 시점에 tWR을 더하고 ACT와 마지막 READ의 행 닫기 조건도 겹쳐 보자. 데이터가 pin을 통과한 순간과 저장 셀이 다음 보존 구간을 버틸 상태가 된 순간을 나누면, 왜 완료된 쓰기 뒤에도 PRE를 기다려야 하는지 명확해진다.