---
title: "곱셈 세 번을 어느 곱셈기에 맡길지 정하는 과정"
author: "브레이브브라우저쓰자"
published_at: "2026-10-26T01:54:00.314Z"
updated_at: "2026-10-06T02:26:27.212Z"
tags: ["operator binding"]
canonical_url: "https://ariser.io/@writer_a9817d5a8de0/%EA%B3%B1%EC%85%88-%EC%84%B8-%EB%B2%88%EC%9D%84-%EC%96%B4%EB%8A%90-%EA%B3%B1%EC%85%88%EA%B8%B0%EC%97%90-%EB%A7%A1%EA%B8%B8%EC%A7%80-%EC%A0%95%ED%95%98%EB%8A%94-%EA%B3%BC%EC%A0%95"
ai_assisted: true
---

# 곱셈 세 번을 어느 곱셈기에 맡길지 정하는 과정

이 글은 AI가 활용됐습니다.

[원문](https://ariser.io/@writer_a9817d5a8de0/%EA%B3%B1%EC%85%88-%EC%84%B8-%EB%B2%88%EC%9D%84-%EC%96%B4%EB%8A%90-%EA%B3%B1%EC%85%88%EA%B8%B0%EC%97%90-%EB%A7%A1%EA%B8%B8%EC%A7%80-%EC%A0%95%ED%95%98%EB%8A%94-%EA%B3%BC%EC%A0%95)

코드에 곱셈이 세 번 있다고 해서 곱셈기 세 개가 생기는 것은 아니다. 서로 다른 시각에 실행할 수 있다면 같은 곱셈기를 공유할 수 있다. 반대로 한 개로 제한하면 값이 준비되어 있어도 차례를 기다리는 연산이 생긴다. operator binding은 이런 연산들을 실제 구현 자원에 대응시키는 과정이다.

## 개수와 종류와 시각을 함께 결정한다

자원을 몇 개 허용할지 정하는 allocation, 각 연산을 어떤 구현 자원에 맡길지 정하는 binding, 언제 실행할지 정하는 scheduling은 서로 영향을 준다. 빠른 시간표에 필요한 연산기 개수를 나중에 줄이면 충돌이 생길 수 있고, 지연이 다른 구현을 선택하면 의존 연산의 시작 시각도 바뀐다.

[AMD의 ALLOCATION 설명](https://docs.amd.com/r/en-US/ug1399-vitis-hls/Allocation)은 지정 범위에서 연산이나 함수의 자원 수를 제한하는 기능을 설명한다. [BIND_OP 설명](https://docs.amd.com/r/en-US/ug1399-vitis-hls/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 모델](https://circt.llvm.org/docs/Scheduling/)은 완전히 파이프라인된 자원을 전제로 설명한다. 그런 모델에서는 같은 시작 시각의 입력 수를 제한한다. 결과가 나올 때까지 자원을 독점하는 연산기를 같은 방식으로 세면 다른 시간의 충돌을 놓칠 수 있다. 지연 3이라는 값과 수락 간격 3이라는 조건을 별도로 기록해야 한다.

더 긴 내부 파이프라인이 목표 클록을 만족시키는 선택이 될 수도 있다. 다만 지연이 길어지면 의존 결과가 늦어지고 보관해야 할 중간 값도 달라진다. 어떤 구현 종류가 항상 최선인지보다, 필요한 완료 시간과 지속 입력량을 만족하는지부터 판단할 수 있다.

operator binding을 이해하면 ‘곱셈 세 번’이라는 코드의 표현을 ‘어떤 곱셈기에 어떤 시각의 입력을 보내는가’라는 구현의 질문으로 바꿀 수 있다. 같은 결과를 유지하면서 개수·지연·공유 비용을 조절하되, 더 늘린 자원이 실제 제한 경로를 개선하는지 확인하는 것이 선택의 기준이다.