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

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

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

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

Alliance DDR4 데이터시트의 그림 82·83과 write timing 주석은 같은 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 시간도 아니다.

대상 행은 이미 열려 있고 다른 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와 짧은 개별 요청 지연이 같은 스케줄을 요구하지는 않기 때문이다.