---
title: "DRAM 읽기와 쓰기를 섞으면 데이터 버스가 쉬는 이유"
author: "브레이브브라우저쓰자"
published_at: "2026-10-07T06:41:00.959Z"
updated_at: "2026-10-05T23:18:53.959Z"
tags: ["twtr"]
canonical_url: "https://ariser.io/@writer_a9817d5a8de0/dram-%EC%9D%BD%EA%B8%B0%EC%99%80-%EC%93%B0%EA%B8%B0%EB%A5%BC-%EC%84%9E%EC%9C%BC%EB%A9%B4-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%B2%84%EC%8A%A4%EA%B0%80-%EC%89%AC%EB%8A%94-%EC%9D%B4%EC%9C%A0"
ai_assisted: true
---

# DRAM 읽기와 쓰기를 섞으면 데이터 버스가 쉬는 이유

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

[원문](https://ariser.io/@writer_a9817d5a8de0/dram-%EC%9D%BD%EA%B8%B0%EC%99%80-%EC%93%B0%EA%B8%B0%EB%A5%BC-%EC%84%9E%EC%9C%BC%EB%A9%B4-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%B2%84%EC%8A%A4%EA%B0%80-%EC%89%AC%EB%8A%94-%EC%9D%B4%EC%9C%A0)

메모리 요청을 모두 읽기나 모두 쓰기로 보내면 잘 나오던 대역폭이, 둘을 섞자 떨어진다. 같은 주소 범위이고 요청 수가 같아도 방향을 바꾸는 일정에는 별도 비용이 있다. tWTR은 쓰기 뒤 읽기로 넘어갈 때 적용하는 timing이며, WRITE 명령 시각에서 단순히 이 값만 기다리는 것으로 해석하면 안 된다.

쓰기 명령은 먼저 들어가고 데이터는 write latency 뒤에 도착한다. 쓰기 burst가 끝난 뒤 규정된 기준 edge에서 write-to-read 시간을 센다. 읽기 명령을 받은 뒤 실제 output data가 나오는 시간도 별도다. 명령 버스, 입력 데이터, 출력 데이터의 시점을 한 줄로 뭉치면 전환 비용을 잘못 계산한다.

## 쓰기 데이터가 언제 끝났는지부터 표시하기

[Alliance DDR4 데이터시트의 그림 82·83과 write timing 주석](https://www.alliancememory.com/wp-content/uploads/AllianceMemory_8Gb_DDR4_AS4C1G8D4A-62BIN-62BCN_Datasheet_ver1.1_-Aug-2025-1.pdf)은 같은 bank group과 다른 bank group의 tWTR을 나누며 마지막 write data 뒤 첫 rising edge를 기준으로 보여 준다. AL, preamble, CRC 등 모드를 바꾸면 관련 조건도 다시 읽어야 한다.

원리를 분리하기 위해 tCK=1ns, CWL=10clock, AL=0, BL8, CL=12clock을 가상으로 놓자. WRITE를 0ns에 보내면 data burst는 10ns부터 4clock을 차지한다. 마지막 write data 뒤 첫 rising-edge 기준은 14ns다. 다른 group의 tWTR_S=4ns, 같은 group의 tWTR_L=8ns를 가정하면 READ 후보는 각각 18ns와 22ns가 된다.

첫 읽기 데이터는 여기에 CL 12ns를 더해 30ns와 34ns다. WRITE 명령 뒤 4ns만 기다리고 READ를 보내는 계산은 데이터 입력이 시작하기도 전의 후보를 만든다. tWTR 값은 전체 WRITE→READ 명령 간격도, WRITE→첫 read data 시간도 아니다.

| 가상 다음 읽기 대상 | READ 후보 | 첫 읽기 데이터 후보 |
|---|---:|---:|
| 다른 bank group | 18ns | 30ns |
| 같은 bank group | 22ns | 34ns |

대상 행은 이미 열려 있고 다른 row timing이 막지 않는다고 가정했다. 실제 schedule에는 bank 상태, read latency의 추가 항목, ODT 전환과 정확한 mode 조건도 넣어야 한다. 위 표는 제품 설정값 제안이 아니라 전환 시간의 구성 요소를 확인하는 계산이다.

## 요청을 묶으면 방향 전환을 줄일 수 있다

W-R-W-R-W-R-W-R처럼 여덟 요청을 번갈아 내보내면 W→R 전환은 네 번, R→W는 세 번 생긴다. W-W-W-W-R-R-R-R로 묶으면 W→R 한 번만 남는다. 같은 방향 요청 사이에도 column 간격이 있지만 방향 전환 제약은 줄어든다.

그렇다고 두 번째 순서가 모든 시스템에서 더 좋지는 않다. 첫 read가 들어왔는데 write queue를 크게 비우느라 오랫동안 기다리게 하면 그 요청의 latency가 커진다. 대역폭을 높이려는 묶음 정책이 반대 방향의 작은 긴급 요청을 막을 수 있다. 실시간 요구나 fairness가 있다면 묶음 크기와 최대 대기시간을 함께 제한해야 한다.

전환 비용을 두 순서의 전체 시간 차로 곧바로 계산하기도 어렵다. W→R과 R→W는 서로 다른 식을 갖고, CL과 CWL 때문에 데이터 구간이 명령 뒤에 이동한다. bank와 group의 관계, burst 간격도 포함해야 한다. 단순히 전환 개수에 tWTR을 곱한 값이 전체 실행 시간은 아니다.

## 다른 bank라고 공유 전환이 사라지는 것은 아니다

bank를 바꾸면 해당 bank의 행 상태 충돌을 줄일 수 있다. 하지만 데이터 I/O 경로는 공유한다. 앞의 write burst가 입력으로 흐르고 있는데 뒤의 read가 output을 내보내는 일정은 합법적인 turn-around 조건을 만족해야 한다. 다른 bank group에 짧은 tWTR이 적용되더라도 제한 자체가 0이 되는 것은 아니다.

이 제약을 tWR과 혼동해서도 안 된다. tWR은 쓰기 뒤 같은 행을 닫기 위한 recovery 조건이다. tWTR은 뒤의 읽기 방향 전환을 위한 조건이다. 현재 행을 닫지 않고 다른 bank를 읽는 경우에도 후자는 중요할 수 있다. 목적이 다른 minimum을 하나의 “쓰기 후 휴식”으로 합치면 불필요한 대기를 만들거나 필수 간격을 빠뜨린다.

읽기와 쓰기를 섞을 때의 손실을 보려면 WRITE 발행, 마지막 데이터 이후 기준 edge, READ 발행, 첫 출력 데이터 네 시점을 표시하자. 그다음 group 관계와 반대 방향 요청의 대기시간을 함께 계산한다. tWTR을 줄이거나 방향별로 묶는 이득은 이 시간선 안에서 평가해야 한다. 높은 throughput와 짧은 개별 요청 지연이 같은 스케줄을 요구하지는 않기 때문이다.