HBM 주소를 고르게 퍼뜨려도 같은 bank에서 막히는 이유
HBM으로 배열을 옮기고 여러 pseudo-channel에 똑같은 양을 배분했는데 특정 stride만 느리다. 총 byte 수와 channel별 요청 수는 균등하다. 빠진 정보는 각 pseudo-channel 안에서 어느 bank와 row로 갔는지다. HBM Bank Conflict는 넓은 대역폭을 갖춰도 한 bank의 열린 row 자원이 하나라는 사실에서 시작한다.
bank에는 한 번에 하나의 active row를 둔다. 요청한 row가 이미 열려 있으면 column 접근을 진행할 수 있고, 같은 bank의 다른 row라면 이전 row를 닫고 새 row를 준비해야 한다. bank가 다른 요청은 일부 준비를 겹칠 수 있다. bank 수가 많다는 것은 병렬 후보가 많다는 뜻이지 임의의 주소열이 그 후보를 고르게 쓴다는 뜻은 아니다.
AMD PG313의 HBM Address Mapping은 기본 map의 필드 순서를 RAx-SID-BAx-BG1-CAx-BG0로 설명하고 BG0를addr[5]에 둔다. PG276의 protocol 설명은 같은 bank의 새 row 전에 precharge가 필요함을 명시한다. map은 IP·device 구성에 따라 달라지므로 실제 생성 설정을 확인해야 한다.
channel 배분 뒤에도 남는 주소 bit
위 PG313의4H·16bank 구성에서 SID가 없는 기본 map을 사용한다고 하자. 하위5bit는32byte transfer 안의 위치이고, 그 위에 BG0 한bit, CA 다섯bit, BG1 한bit, BA 두bit가 놓인다. 이 조건에서는 row field가 bit14부터 시작한다. 여기서의 bit 위치는 그 필드 순서를 해당 구성에 적용해 계산한 것으로 custom map이나 다른 density에 그대로 사용하면 안 된다.
동일 pseudo-channel에서0x0000,0x4000,0x8000,0xC000을 차례로32byte씩 읽으면 lower 14bit는 모두 0이다. bank와column이 같고 row만 0, 1, 2, 3으로 바뀐다. 16KiB stride는 주소를 멀리 퍼뜨렸지만 bank 병렬도를 늘리지 않은 셈이다.
반대로0x0000,0x0020은BG0가 달라 해당 기본 map에서 다른 bank group으로 향한다. 가까운 주소가 더 많은 병렬 후보를 사용할 수 있다. 주소 사이의 숫자 거리가 아니라 map이 어느bit를 어떤 자원으로 해석하는지가 핵심이다.
같은 bank의 행 전환을 계산하기
가상으로 PRE가 이미 허용된 상태에서 tRP=12ns, tRCD=14ns라고 놓자. 같은 bank의 새 row를 읽으려면 column 명령 전에 최소26ns의 준비 구간이 생긴다. 실제 HBM timing값이 아니라 PRE와ACT 비용을 분리한 toy다. 앞선WRITE recovery, row active minimum, group·command제약이 남아 있으면 더 늦어진다.
앞의 네 row를 순서대로 읽을 때 첫 준비 뒤 세 번의 row 전환에는 단순 준비량으로 3×26=78ns가 들어간다. 이는 전체 요청의 serial latency나 benchmark 시간을 뜻하지 않는다. 다른 bank 작업과 겹칠 수 있는지, queue에 무엇이 있는지에 따라 체감 대기는 달라진다. 그래도 한 bank만 반복 사용하면 그 bank의 준비 구간을 내부적으로 독립 bank의 작업으로 바꿀 수는 없다.
bank를 흩으면 locality도 평가해야 한다
주소를 무조건 다른 bank로 보내면 성능이 좋아지는 것도 아니다. 연속 column을 같은 row에서 여러 번 읽을 수 있었는데 row를 과하게 분산하면 필요한 ACT 수가 늘 수 있다. bank 분산과 row 재사용은 같이 평가해야 한다. 작은 random 요청과 긴 sequential burst에 동일 map을 강제하는 것이 최적인지는 workload로 확인해야 한다.
진단에는 요청별 pseudo-channel, group, bank, row, column을 출력하고 같은 bank에서 row가 바뀐 횟수를 세는 방법이 유용하다. 그다음 data 전송 공백에 PRE·ACT가 겹치는지 확인한다. channel별 byte가 균등하다는 통계보다 병목의 위치를 더 정확하게 알려 준다.
HBM Bank Conflict를 해결하려면 넓은 버스에 더 많은 요청을 넣기 전에 주소가 bank의 열린 행을 어떻게 소비하는지 봐야 한다. stride와 mapping을 함께 읽으면 멀리 떨어진 주소가 같은 bank를 반복하는 이유, 가까운 주소가 group을 번갈아 쓰는 이유가 드러난다. 병렬도의 숫자를 실제 접근의 병렬성으로 바꾸는 것은 주소 해석과 row 상태의 조합이다.