모든 이야기

순차 곱셈기: 작은 회로로 계산할 때 지불하는 네 사이클

곱셈 명령이 가끔만 나오는 작은 제어용 CPU에 큰 병렬 곱셈기를 넣는 것이 항상 합리적일까. 순차 곱셈기는 한 번에 모든 부분곱을 계산하는 대신, 여러 사이클 동안 작은 연산 자원을 반복해서 사용한다. 필요한 숫자는 같지만 면적을 아끼는 대가가 시간과 인터페이스에 나타난다.

이 선택을 이해하려면 한 요청의 완료 시간인 latency와 새로운 요청을 받는 간격을 구분해야 한다. 여러 사이클을 쓰는 연산기도 pipeline이 있다면 매 사이클 새 요청을 받을 수 있지만, 같은 누산 자원을 하나의 요청이 계속 점유하는 구조는 보통 그렇지 않다.

4비트 곱을 네 번의 작은 일로

설명용 unsigned 곱셈에서 A=13, B=11(1011), accumulator=0으로 시작하자. B의 낮은 비트를 보고 1이면 현재 A를 더한다. 이후 A는 왼쪽으로, B는 오른쪽으로 한 비트 이동한다. 네 번의 처리 후 4비트 B를 모두 사용한다.

처리 단계사용한 B의 bit0더하는 값누산 결과
111313
212639
30039
41104143

A의 이동 상태와 누산 결과에는 전체 8비트 곱을 담을 폭을 사용한다고 가정한다. 4비트 A를 그대로 이동 레지스터에 넣으면 26부터 높은 비트가 잘려 틀린다. 이 표는 원리 설명용 shift-and-add 구조이며 특정 CPU의 실제 알고리즘과 사이클 수가 아니다.

상태에는 누산 값, 남은 multiplier 비트와 처리 횟수가 필요하다. 한 사이클의 조합 경로는 현재 항 선택과 덧셈, 다음 상태 계산을 담당한다. 나머지 항은 다음 사이클의 레지스터 상태를 통해 처리된다.

실제 CPU에서는 연산 자원도 공유할 수 있다

Ibex의 곱셈기 설명은 여러 구현 선택을 제공한다. slow multi-cycle 곱셈기는 ALU를 덧셈에 사용하고, 다른 선택은 내부 곱셈·누산 자원을 사용한다. slow 구현의 RTL에는 누산 상태와 이동 피연산자, 연산 상태 머신이 드러난다.

이는 한 종류의 곱셈기만 정답이 아니라는 사례다. 공개 문서의 특정 명령 사이클 수를 다른 CPU나 위의 4비트 예제에 그대로 적용해서는 안 된다. 부호, 높은 결과 비트 요청, 조기 종료와 제어 정책에 따라 필요한 처리도 다르다.

자원을 공유하면 추가 mux와 제어가 필요하다. 곱셈이 ALU를 쓰는 동안 일반 명령도 같은 자원을 요구하면 충돌한다. 곱셈기만 작아졌다고 코어 전체의 성능 비용이 곱셈 명령 수에만 비례하는 것은 아니다.

네 사이클 latency가 같은 두 구현 비교

가상의 두 유닛이 모두 요청 수락 후 4사이클에 결과를 낸다고 하자. 하나는 네 단계 pipeline이라 매 사이클 새 요청을 받고, 다른 하나는 같은 자원을 반복 사용하는 유닛으로 4사이클마다 새 요청을 받는다. 추가 stall과 입출력 병목은 없다고 가정한다.

독립적인 8개 요청을 처리할 때 pipeline의 마지막 완료는 첫 수락 후 4+(8−1)×1=11사이클이다. 반복 유닛에서는 4+(8−1)×4=32사이클이다. 완료와 다음 수락을 같은 에지에서 허용하는 이상적인 간격이며, 실제 제어가 한 사이클 공백을 요구하면 더 길어진다.

반대로 다음 곱셈이 이전 결과를 반드시 기다리는 의존 사슬이면 pipeline에 빈 슬롯이 생긴다. 한 요청의 latency가 같다면 매 사이클 새 요청을 받을 능력만으로 사슬이 같은 비율로 빨라지지 않는다. 입력들이 독립적인지까지 봐야 throughput 수치가 의미를 갖는다.

빨리 끝내는 기능이 새로운 조건을 만든다

multiplier의 남은 비트가 모두 0이면 일부 구조는 일찍 완료할 수 있다. 작은 입력이 흔한 작업 부하에서는 이득일 수 있지만, 입력에 따라 latency가 달라진다. 고정 사이클의 주변 제어는 그런 유닛을 바로 사용할 수 없다.

결과 valid와 수락 조건을 명시하고, busy 동안 새 피연산자가 들어오면 무시할지 stall할지 정해야 한다. 출력 소비가 늦으면 완료 결과를 유지해야 한다. 원천 입력이 변하는 동안 계산에 계속 직접 연결되면 한 요청 안에서 피연산자가 섞일 수 있으므로 수락 시점의 값 저장도 필요하다.

보안이나 실시간 요구가 있다면 데이터 의존 완료 시간이 허용되는지도 확인한다. Ibex slow RTL에는 data-independent timing에 관련된 제어가 있어 조기 종료와 분리된 정책을 볼 수 있다. 단순히 평균 사이클이 짧다는 값으로 이 요구를 대체할 수 없다.

면적을 아낀다는 말을 확인하기

비교에는 연산기 본체뿐 아니라 상태 레지스터와 mux, 제어를 포함해야 한다. 반복 계산이 여러 사이클 동안 같은 자원을 활성화하므로 에너지의 이득도 셀 수만으로 단정할 수 없다. 사용 빈도가 낮으면 유휴 비용을 줄일 여지가 있지만, 완료까지의 동적 활동과 클록 비용도 남는다.

순차 곱셈기는 드문 곱셈을 작은 자원으로 처리하려는 선택에 잘 맞을 수 있다. 다만 독립 요청이 몰리는 환경에서는 처리 간격이 직접적인 제한이 된다. 선택 기준은 곱셈 한 번의 사이클 수에 더해, 요청 독립성·자원 공유·수락 간격과 결과 유지 계약을 함께 보는 것이다. 작은 회로가 언제 좋은 시스템이 되는지는 그 사용 조건이 결정한다.