DRAM은 왜 여러 bank를 한꺼번에 활성화하지 못할까
DRAM에는 여러 bank가 있다. 서로 다른 bank의 행을 미리 열어 두면 이후 요청을 빠르게 처리할 수 있다. 그런데 bank들이 모두 비어 있어도 ACT를 원하는 만큼 촘촘하게 보낼 수는 없다. tFAW는 일정한 길이의 시간 창 안에서 허용하는 활성화 수를 제한한다. 두 명령 사이 간격만 지키는 schedule로는 이 규칙을 표현할 수 없다.
ACT는 주소를 기록하는 작은 제어 동작만이 아니다. 행의 셀들을 연결하고 많은 센스 증폭기가 저장 상태를 읽고 복원하는 작업을 시작한다. bank의 논리 상태가 독립적이어도 동일 rank 안의 활성화 집중도를 제한하는 규칙은 남는다. Four Activate Window라는 이름은 네 번의 활성화를 허용하는 창을 뜻한다.
Alliance DDR4 데이터시트의 tFAW timing 그림과 AC timing 표는 연속 ACT의 tRRD 제약과 네 ACT에 대한 창 제약을 함께 표시한다. 적용 범위와 값은 해당 device의 조직과 speed 조건으로 확인해야 한다. bank가 다르다는 이유만으로 tFAW에서 서로 무관한 명령으로 세면 안 된다.
다섯 번째가 기다리는 시점을 직접 찾기
설명용으로 clock period 1ns, ACT의 공통 최소 간격 4ns, tFAW=24ns를 놓자. 이 예에서는 bank group에 따른 short/long 간격의 차이를 생략하고 모든 ACT에 동일한 4ns 조건을 적용한다. 서로 다른 idle bank에 ACT를 0, 4, 8, 12ns에 보냈다. 다음 bank를 16ns에 열면 각 이웃 명령 사이의 4ns 간격은 만족한다. 그러나 0~16ns 안에 다섯 ACT가 모이므로 24ns 창 제한을 만족하지 못한다.
다섯 번째 ACT는 가장 오래된 첫 ACT에서 24ns 지난 시점 이후에 가능하다. 24ns에 보내면 다음 여섯 번째의 창 기준은 두 번째 ACT인 4ns가 되고, 가장 이른 시점은 28ns다. 이후도 같은 방식으로 최근 활성화 기록을 이동시킨다.
| ACT 순서 | 인접 간격만 본 후보 | 창까지 적용한 후보 |
|---|---|---|
| 1~4번째 | 0, 4, 8, 12ns | 0, 4, 8, 12ns |
| 5번째 | 16ns | 24ns |
| 6번째 | 20ns | 28ns |
| 7번째 | 24ns | 32ns |
정확한 경계 edge 적용은 제품과 controller 표현으로 확인해야 하지만 논리는 분명하다. 다음 후보는 이전 ACT+tRRD와 네 번째 이전 ACT+tFAW 중 더 늦은 시점이다. 같은 bank를 다시 여는 경우에는 tRC와 PRE 조건도 추가된다. 위 표는 이미 idle인 서로 다른 bank들의 활성화 집중도만 분리한 가상 예다.
고정된 묶음 창으로 검사하면 빠지는 경우
“024ns에 네 번, 2448ns에 네 번”처럼 시간을 고정 구간으로 나눠 개수만 세면 경계 부근의 집중을 놓칠 수 있다. 첫 구간 끝에 네 ACT, 다음 구간 처음에 네 ACT를 배치하면 각 구간은 네 개씩이어도 경계를 가로지르는 짧은 창에는 더 많이 모인다.
그래서 tFAW는 움직이는 창으로 이해해야 한다. controller는 최근 ACT 시점들을 기억하거나 이에 동등한 상태로 다음 발행 가능 시점을 판단한다. “네 번째 ACT 뒤 tFAW만큼 쉰다”는 해석도 틀린다. 창의 시작은 보통 가장 오래된 관련 ACT이고, 네 번째 뒤에 전부를 다시 기다리면 필요 이상으로 느려진다.
가상 조건에서 tRRD만 보면 장기 활성화율은 4ns마다 한 번이다. tFAW는 24ns마다 최대 네 번에 해당하므로 장기 평균은 ACT당 6ns 수준의 더 강한 상한을 만든다. 반대로 tFAW가 충분히 짧으면 다른 간격 제약이 지배할 수 있다. 모든 timing 숫자가 언제나 동시에 성능을 제한하는 것은 아니다.
열린 행을 잘 쓰는 요청에는 영향이 다르다
tFAW가 제한하는 것은 ACT의 집중도다. 같은 열린 행에서 여러 column을 읽는 요청은 매번 ACT를 추가하지 않는다. 그런 작업 부하는 column 간격이나 데이터 bus가 먼저 막힐 수 있다. row miss가 많은 작은 무작위 요청은 훨씬 자주 활성화 창을 소모한다. 따라서 tFAW 변경의 영향을 해석하려면 요청 수보다 실제 ACT 수를 먼저 세야 한다.
여러 bank를 늘리면 병렬 작업의 후보는 많아진다. 그래도 동일 rank의 활성화 창이 공유 제약이면 무한한 시작 속도를 얻지는 못한다. controller가 다른 bank의 전송을 겹쳐 지연을 숨기는 것과 활성화율 상한을 없애는 것도 다르다.
다섯 번째 ACT가 기다리는 이유를 찾을 때는 최근 네 ACT의 timestamp를 나란히 적어 보자. 이웃 간격과 움직이는 창을 따로 검사하면 bank 충돌이 없는 schedule에도 생기는 대기 시간이 설명된다. tFAW는 개별 bank의 준비 시간보다, 여러 bank의 시작 동작이 얼마나 좁은 구간에 모이는지를 관리하는 제약이다.