---
title: "tRCD가 막고 있는 DRAM 행 활성화의 미완성 작업"
author: "브레이브브라우저쓰자"
published_at: "2026-10-06T05:55:00.939Z"
updated_at: "2026-10-05T13:57:39.732Z"
tags: ["trcd"]
canonical_url: "https://ariser.io/@writer_a9817d5a8de0/trcd%EA%B0%80-%EB%A7%89%EA%B3%A0-%EC%9E%88%EB%8A%94-dram-%ED%96%89-%ED%99%9C%EC%84%B1%ED%99%94%EC%9D%98-%EB%AF%B8%EC%99%84%EC%84%B1-%EC%9E%91%EC%97%85"
ai_assisted: true
---

# tRCD가 막고 있는 DRAM 행 활성화의 미완성 작업

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

[원문](https://ariser.io/@writer_a9817d5a8de0/trcd%EA%B0%80-%EB%A7%89%EA%B3%A0-%EC%9E%88%EB%8A%94-dram-%ED%96%89-%ED%99%9C%EC%84%B1%ED%99%94%EC%9D%98-%EB%AF%B8%EC%99%84%EC%84%B1-%EC%9E%91%EC%97%85)

DRAM 읽기 요청이 도착했는데 데이터는 아직 나오지 않는다. clock은 돌고 있고 데이터 버스도 비어 있다. 그렇다면 즉시 READ 명령을 보내면 될까? 필요한 행이 열려 있지 않다면 먼저 그 행의 작은 저장 전하를 읽을 수 있는 상태로 바꿔야 한다. ACT와 READ 사이의 최소 시간인 tRCD는 이 준비 작업을 기다리는 제약이다.

이 이름은 행 주소에서 열 주소로 넘어가는 지연이라는 뜻을 담고 있다. 현대 명령 인터페이스에서는 ACT가 bank와 row를 선택하고 READ가 column을 지정한다. 중요한 점은 tRCD가 외부에서 관찰되는 명령 간격이라는 것이다. 내부 트랜지스터 하나의 switching 시간이나 데이터 출력까지 걸리는 전체 시간과는 구분해야 한다.

## 열 주소를 알기 전에 행을 읽을 준비가 필요하다

DRAM 셀은 작은 커패시터의 전하로 정보를 저장한다. 행을 열면 그 행의 셀들이 bitline에 연결되고 전하를 공유한다. bitline에서 생긴 작은 변화는 센스 증폭기에 의해 크게 확대된다. 한 행의 센스 증폭기들이 잡아 둔 데이터가 row buffer, 즉 열린 행의 데이터 저장 상태가 된다.

column READ는 준비된 row buffer의 일부를 외부로 꺼내는 요청이다. 따라서 다른 행을 처음 열 때와 이미 열린 행에서 다른 column을 읽을 때는 거치는 작업이 다르다. [AL-DRAM 원 논문 그림 2·3](https://people.inf.ethz.ch/omutlu/pub/adaptive-latency-dram_hpca15.pdf)는 cell charge 공유와 sensing 이후 읽기가 가능한 시점, 셀 복원이 완료되는 시점을 구분한다. tRCD는 앞의 준비 시간에 대응하며, 행 전체를 완전히 복원하는 최소 active 시간과 동일하지 않다.

공개된 [Alliance Memory DDR4 데이터시트](https://www.alliancememory.com/wp-content/uploads/AllianceMemory_8Gb_DDR4_AS4C1G8D4A-62BIN-62BCN_Datasheet_ver1.1_-Aug-2025-1.pdf)의 ACTIVATE·READ 설명과 AC timing도 ACT 이후 해당 bank에서 읽기 명령을 보내기 전 tRCD를 만족하도록 요구한다. 규격 숫자의 단위를 clock cycle로 적었는지 ns로 적었는지도 확인해야 한다. 어떤 minimum은 두 표현을 함께 만족해야 한다.

## 첫 데이터 지연을 나누어 계산해 보자

제품을 모사하려는 것이 아닌 설명용 조건으로 tCK=1ns, tRCD=14ns, CL=14cycle을 놓자. CL은 READ를 보낸 뒤 첫 데이터까지의 CAS latency다. Additive Latency와 다른 추가 latency는 0, 요청 queue와 bus 충돌은 없다고 가정한다.

행이 이미 열려 있는 row hit라면 시각 0에 READ를 보낼 수 있다. 첫 데이터는 약 14ns 뒤다. bank가 idle인 row miss라면 시각 0에 ACT를 보내고 14ns 뒤 READ를 보낸다. 첫 데이터는 약 28ns 뒤다. 같은 CL을 가진 같은 메모리라도 초기 bank 상태만으로 준비 구간이 하나 추가된다.

다른 행이 열려 있는 row conflict는 더 복잡하다. 기존 행을 닫는 PRE, 다음 행을 열기 전의 tRP, 이후 tRCD가 추가된다. 현재 행의 최소 active 시간이나 write recovery가 아직 끝나지 않았다면 PRE 자체도 늦춰진다. 그래서 모든 miss의 첫 데이터 시간을 항상 tRCD+CL로 놓는 계산은 부족하다.

| 초기 bank 상태 | 가상 조건의 첫 데이터 시간 |
|---|---:|
| 원하는 행이 이미 열림 | 14ns |
| bank idle, 원하는 행 새로 열기 | 28ns |
| 다른 행이 열림 | PRE 가능 시점 + tRP + 28ns |

이 표에서 CL을 14에서 12cycle로 줄여도 새 행의 준비 14ns는 그대로다. row hit는 14→12ns, idle-bank miss는 28→26ns로 줄어든다. 절대 개선 2ns는 같지만 접근 전체의 개선 비율은 다르다. 반대로 tRCD만 2ns 줄이는 가상 변경은 이미 열린 행을 읽는 구간에 직접적인 이득을 주지 않는다.

## 낮은 tRCD와 빠른 시스템은 다른 주장이다

tRCD가 짧을수록 새 행에 빨리 접근할 수 있다는 사실은 맞다. 하지만 실제 요청은 다른 bank 준비와 겹치거나 controller queue에서 기다리고, data bus를 공유한다. 여러 bank의 ACT와 READ를 겹치면 한 bank의 tRCD 일부를 다른 bank의 전송으로 숨길 수 있다. 이런 조건에서 tRCD 개선이 그대로 전체 throughput 개선으로 나타나지는 않는다.

또한 timing 여유는 셀 전하, 온도, 배열 편차와 연결된다. 연구에서 일부 조건의 timing을 줄였다는 결과를 모든 제품·온도에서 같은 값으로 적용할 수 없다. vendor minimum을 줄이는 작업은 명령 schedule 최적화와 다르다. 전자는 지정 조건 밖의 정확성 검증을 요구하고, 후자는 지정 minimum을 유지하며 준비 작업을 다른 요청과 겹치는 일이다.

오류를 볼 때도 ACT 직후의 실패인지, 출력 sample 시점의 실패인지 구분해야 한다. tRCD는 row 준비 구간이고 CL이나 DQ training은 다른 경로의 조건이다. 모든 읽기 오류를 하나의 timing 숫자로 설명하면 원인도 수정 위치도 흐려진다.

읽기 시간을 비교할 때 먼저 bank 상태를 표시하자. row hit인지, idle bank에서 새 행을 여는지, 기존 행을 바꾸는지에 따라 비용 항목이 달라진다. 그다음 tRCD와 CL을 같은 시간 단위로 옮기면 어느 숫자가 실제 질문의 병목인지 보인다. tRCD가 기다리는 것은 막연한 메모리 속도가 아니라, 선택한 행의 정보를 column 경로가 사용할 수 있도록 만드는 준비 작업이다.