곱셈 세 번을 어느 곱셈기에 맡길지 정하는 과정
코드에 곱셈이 세 번 있다고 해서 곱셈기 세 개가 생기는 것은 아니다. 서로 다른 시각에 실행할 수 있다면 같은 곱셈기를 공유할 수 있다. 반대로 한 개로 제한하면 값이 준비되어 있어도 차례를 기다리는 연산이 생긴다. operator binding은 이런 연산들을 실제 구현 자원에 대응시키는 과정이다.
개수와 종류와 시각을 함께 결정한다
자원을 몇 개 허용할지 정하는 allocation, 각 연산을 어떤 구현 자원에 맡길지 정하는 binding, 언제 실행할지 정하는 scheduling은 서로 영향을 준다. 빠른 시간표에 필요한 연산기 개수를 나중에 줄이면 충돌이 생길 수 있고, 지연이 다른 구현을 선택하면 의존 연산의 시작 시각도 바뀐다.
AMD의 ALLOCATION 설명은 지정 범위에서 연산이나 함수의 자원 수를 제한하는 기능을 설명한다. BIND_OP 설명은 특정 결과 변수의 연산에 구현 종류와 허용되는 지연을 지정하는 기능을 다룬다. BIND_OP를 썼다는 사실만으로 여러 곱셈을 반드시 한 물리 인스턴스로 공유했다는 뜻은 아니다. 두 지시의 의미와 적용 범위를 구분해야 한다.
이 관계를 작은 자체 회로로 계산해 보자. p=a×b, q=c×d, r=e×f를 구하고, u=p+q, y=u+r로 결합한다. 이 덧셈 구조를 고정하며, 입력 여섯 개는 모두 시각 0에 준비되어 있다. 메모리 지연은 없고 충분한 수치 폭을 가정한다.
곱셈기는 지연 3사이클, 새 입력 수락 간격 1사이클인 파이프라인이다. 덧셈기는 한 개이며 지연과 수락 간격이 각각 1사이클이다. 경계 0에 시작한 연산의 3사이클 결과는 경계 3에서 다음 연산에 쓸 수 있다.
같은 수식을 다른 수의 곱셈기에 맡긴다
| 곱셈기 수 | p·q·r 시작 | p·q·r 완료 | u 시작→완료 | y 시작→완료 |
|---|---|---|---|---|
| 1 | 0·1·2 | 3·4·5 | 4→5 | 5→6 |
| 2 | 0·0·1 | 3·3·4 | 3→4 | 4→5 |
| 3 | 0·0·0 | 3·3·3 | 3→4 | 4→5 |
곱셈기 한 개 구성에서는 p, q, r를 같은 자원에 다른 시작 시각으로 배정한다. 둘째 구성은 p와 q를 두 자원에 동시에 보내고, r는 한 자원의 다음 입력 칸을 사용한다. 셋째에서는 세 곱을 모두 동시에 시작한다.
자원 수가 1에서 2로 늘면 결과 시각이 6에서 5로 줄어든다. 하지만 2에서 3으로 늘려도 이 고정된 결합 구조의 결과는 5에 나온다. 곱셈이 더 빨리 끝나도 u와 y의 두 단계가 남기 때문이다. 자원 증가가 현재 가장 늦게 끝나는 경로를 줄이는지 확인해야 한다.
입력을 a=2, b=3, c=4, d=5, e=6, f=7로 놓으면 p=6, q=20, r=42, 최종값은 68이다. 세 시간표는 같은 값과 서로 다른 자원 사용을 갖는다. 이는 도구가 자동으로 위 시간표를 선택한다는 예측이 아니라, 설정한 자원·지연 조건에서 가능한 배정의 예다.
자원 충돌과 값 의존을 별도로 검사할 수도 있다. 한 곱셈기 구성에서 세 곱의 시작을 모두 0으로 두면 입력 수락 용량을 세 배 요구한다. 한편 자원 두 개로 p와 q를 0에 시작해도 u를 2에 시작하면 아직 나오지 않은 곱을 읽는다. binding으로 개수 제한을 지키는 것과, 그 배정에서 scheduling이 올바른 값을 사용하는 것은 서로 필요한 검증이다.
공유에 필요한 회로도 공유 비용에 포함한다
하나의 곱셈기를 공유한다면 사이클마다 어느 입력 쌍을 보낼지 선택해야 한다. 결과가 나올 때도 그것이 p인지 q인지 r인지 구분해 올바른 보관 위치로 보내야 한다. 위 시간표처럼 지연이 고정되어 있다면 제어 시간표로 이 대응을 정할 수 있다. 가변 지연이나 정지가 섞이면 요청과 결과를 추적하는 계약이 더 필요하다.
연산기 본체가 줄어드는 대신 입력 선택기, 결과 보관 레지스터와 제어가 추가될 수 있다. 그러므로 공유를 늘렸다는 사실만으로 전체 면적이나 소비 전력이 반드시 줄었다고 결론 낼 수 없다. 선택 경로의 지연이 새로운 제한을 만들 수도 있다. 실제 구현에서는 생성된 자원과 경로를 확인해야 한다.
자원 제한의 시간 의미에도 주의가 필요하다. CIRCT의 shared operator 모델은 완전히 파이프라인된 자원을 전제로 설명한다. 그런 모델에서는 같은 시작 시각의 입력 수를 제한한다. 결과가 나올 때까지 자원을 독점하는 연산기를 같은 방식으로 세면 다른 시간의 충돌을 놓칠 수 있다. 지연 3이라는 값과 수락 간격 3이라는 조건을 별도로 기록해야 한다.
더 긴 내부 파이프라인이 목표 클록을 만족시키는 선택이 될 수도 있다. 다만 지연이 길어지면 의존 결과가 늦어지고 보관해야 할 중간 값도 달라진다. 어떤 구현 종류가 항상 최선인지보다, 필요한 완료 시간과 지속 입력량을 만족하는지부터 판단할 수 있다.
operator binding을 이해하면 ‘곱셈 세 번’이라는 코드의 표현을 ‘어떤 곱셈기에 어떤 시각의 입력을 보내는가’라는 구현의 질문으로 바꿀 수 있다. 같은 결과를 유지하면서 개수·지연·공유 비용을 조절하되, 더 늘린 자원이 실제 제한 경로를 개선하는지 확인하는 것이 선택의 기준이다.