HBM pseudo-channel 둘은 어디까지 독립적으로 일할까
HBM의 두 pseudo-channel에 각각 충분한 요청을 넣었다. 한쪽 data bus가 바쁜 동안 다른 쪽도 함께 전송하니 별개의 channel처럼 보인다. 그런데 첫 번째 쪽의 요청 pattern을 바꾸면 두 번째 쪽의 latency도 변한다. pseudo-channel의 독립성이 어느 자원에 적용되는지 확인하면 이 결과는 이상하지 않다.
AMD PG313의 HBM Topology 설명은 해당 HBM 구성에서128bit channel을 두64bit pseudo-channel로 나누고 command/address/control bus를 공유한다고 설명한다. 그래서 semi-independent라는 표현을 사용한다. data 경로가 둘이라는 사실은 명령 발행과 모든 내부 관리까지 둘로 완전히 복제됐다는 뜻이 아니다.
이 문서는 해당 IP와 HBM 구성의 설명이다. 다른 HBM 세대의 모든 command 구조와 timing을 같은 것으로 가정할 수 없다. 여기서 살펴볼 문제는 독립 data 경로와 공유 제어 자원을 가진 구성에서 생기는 병목이다.
payload 폭은 나뉘고 시작 명령은 공유될 수 있다
이 구성의 pseudo-channel mode burst length는4다. 64bit×4transfer는256bit, 즉32byte다. 가상 interface clock1GHz라면 DDR transfer rate는2GT/s이고 한 burst는2ns다. pseudo-channel 하나의 data peak는16GB/s, 둘의 합은32GB/s다. 이는 실제 chip 측정이 아닌 width와 rate로 계산한 상한이다.
이 상한은 두 bus가 필요한 burst를 계속 받을 때만 나온다. 한 요청을 처리하려고 command 경로에서 row 준비와 column 명령을 발행해야 한다. 요청 준비가 늦으면 그 pseudo-channel의 data bus가 비더라도 다른 쪽의 bus 폭으로 대신할 수는 없다. payload 경로와 시작 경로가 다른 위치에서 기다리는 것이다.
가상 controller model에서 공유된 어떤 command class가1ns짜리 slot 하나씩을 소모한다고 단순화하자. A의 준비 명령이0,1ns slot을 사용하면 같은 자원을 요구하는 B의 명령은 다음 가용 slot을 기다린다. A와 B의 data 전송은 그 이후 각 bus에서 겹칠 수 있다. 실제 HBM의 row·column command timing을 구현한 trace가 아니라 공유 resource contention을 보여 주는 toy다.
row hit가 많은 쪽과 miss가 많은 쪽
같은 열린 row의 column을 길게 처리하는 workload는 비교적 적은 준비 작업으로 data bus를 채운다. 매번 새로운 row를 요구하는 workload는 ACT·PRE 등 준비 명령을 더 자주 발생시킨다. 같은 byte 수를 읽어도 공유 경로에 주는 압력은 다를 수 있다.
따라서 pseudo-channel당 요청 수가 같다고 공평한 자원 사용이라고 말할 수 없다. 필요한 command 수와 발행 가능한 시점, queue 정책까지 알아야 한다. 한쪽의 latency 증가가 data bus 충돌인지 공유 command 경로인지, 앞단 NoC 또는 switch인지 구분해야 개선 위치가 보인다.
더 많은 outstanding 요청을 넣으면 대기를 숨길 수 있지만 무한정 좋은 것은 아니다. 공유 자원이 이미 포화면 queue가 길어져 latency가 늘 수 있다. 충분한 병렬성과 과도한 queueing의 경계를 throughput과 latency를 함께 측정해야 한다.
두 channel의 시험 결과를 합치기 전에
pseudo-channel 하나만 활성화한 bandwidth 두 개를 더하면 동시에 사용할 때의 결과보다 클 수 있다. 단독 측정은 공유 자원의 경쟁을 포함하지 않았기 때문이다. 반대로 동시에 동작해도 대부분 row hit여서 제어 경로가 여유롭다면 합산값에 가까울 수 있다. “항상 반으로 줄어든다”는 식의 고정 penalty도 맞지 않는다.
측정에서는 단독·동시 조건을 나누고 양쪽 pattern을 바꾸어 보자. 각 data bus utilization과 command 발행 지연, queue 깊이를 같이 기록하면 semi-independent의 실제 범위를 확인할 수 있다. 두 개의64bit 경로가 주는 병렬성은 크지만 그 숫자만으로 독립 자원의 수를 셀 수는 없다. HBM Pseudo Channel의 성능은 data 폭과 공유한 시작 작업을 함께 세었을 때 설명된다.