---
title: "연산기 공유의 타이밍은 선택 신호가 언제 오는지에 달린다"
author: "브레이브브라우저쓰자"
published_at: "2026-10-21T09:48:00.292Z"
updated_at: "2026-10-06T01:26:26.398Z"
tags: ["연산기 공유"]
canonical_url: "https://ariser.io/@writer_a9817d5a8de0/%EC%97%B0%EC%82%B0%EA%B8%B0-%EA%B3%B5%EC%9C%A0%EC%9D%98-%ED%83%80%EC%9D%B4%EB%B0%8D%EC%9D%80-%EC%84%A0%ED%83%9D-%EC%8B%A0%ED%98%B8%EA%B0%80-%EC%96%B8%EC%A0%9C-%EC%98%A4%EB%8A%94%EC%A7%80%EC%97%90-%EB%8B%AC%EB%A6%B0%EB%8B%A4"
ai_assisted: true
---

# 연산기 공유의 타이밍은 선택 신호가 언제 오는지에 달린다

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

[원문](https://ariser.io/@writer_a9817d5a8de0/%EC%97%B0%EC%82%B0%EA%B8%B0-%EA%B3%B5%EC%9C%A0%EC%9D%98-%ED%83%80%EC%9D%B4%EB%B0%8D%EC%9D%80-%EC%84%A0%ED%83%9D-%EC%8B%A0%ED%98%B8%EA%B0%80-%EC%96%B8%EC%A0%9C-%EC%98%A4%EB%8A%94%EC%A7%80%EC%97%90-%EB%8B%AC%EB%A6%B0%EB%8B%A4)

연산기 두 개를 하나로 합치면 회로가 작아질 것 같다. 그런데 합성 후 면적은 줄고 가장 느린 경로는 길어진다. 연산기 공유에서는 두 번째 연산기를 지우는 대신 **하나의 연산기에 들어갈 입력을 선택하는 논리와 그 선택 신호의 도착 시간**을 함께 받아들인다. 비용을 비교할 때 이 이동을 계산해야 한다.

## 동시에 관측되지 않는 결과를 하나의 연산으로 만들기

8비트 부호 없는 입력 a·b·c·d가 있고, sel=0이면 a+b, sel=1이면 c+d를 9비트 출력으로 내보낸다고 하자. 각 덧셈 전에 입력을 9비트로 0 확장한다. 두 덧셈 결과를 먼저 만들고 sel로 고르는 구현을 생각할 수 있다.

다른 구현은 연산 전에 두 피연산자를 고른다. 첫 입력은 sel에 따라 a 또는 c, 두 번째 입력은 b 또는 d를 선택하고, 그 뒤 하나의 9비트 결과 덧셈기를 사용한다. sel=0일 때는 a+b, sel=1일 때는 c+d이므로 같은 출력 관계를 얻는다. 두 입력 mux가 같은 sel을 사용해야 한다. 서로 다른 선택을 하면 a+d 같은 계약에 없는 조합을 만들 수 있다.

Yosys의 share 명령은 자원을 병합할 수 있는지 SAT로 판단하는 자원 공유 패스다. 기본적으로 어떤 자원을 후보로 다룰지 휴리스틱을 사용하며, 더 많은 후보를 고려하는 aggressive 등의 옵션이 있다. 따라서 RTL에 같은 연산이 둘 있다는 사실만으로 항상 합쳐지는 것은 아니다. [Yosys share의 공식 설명](https://yosyshq.readthedocs.io/projects/yosys/en/stable/cmd/index_passes_opt.html#share-perform-sat-based-resource-sharing), [share 구현과 옵션](https://github.com/YosysHQ/yosys/blob/main/passes/opt/share.cc)

이 예에서 공유할 수 있는 이유는 같은 출력에서 한 번에 하나의 합만 필요하기 때문이다. 결과 둘을 서로 다른 출력으로 동시에 요구하는 계약이었다면, 하나의 일반 연산기로 같은 에지에 두 결과를 제공할 수 없다. 사이클을 늘리거나 다른 클록으로 나눠 계산하는 방법은 인터페이스와 처리량의 변경까지 포함한다.

## 면적을 아끼는 선택이 늦게 도착할 때

가상 비용 모델로 두 구조를 비교해 보자. 덧셈기 하나의 면적을 80단위, 조합 지연을 350ps라고 정한다. 8비트 입력 mux 하나는 20단위·80ps, 9비트 출력 mux는 25단위·90ps라고 하자. 이 숫자는 실제 공정의 라이브러리 값이나 합성 측정값이 아니다.

병렬 구현의 면적은 `80×2 + 25 = 185`단위다. 공유 구현은 입력 mux 두 개와 덧셈기 하나이므로 `20×2 + 80 = 120`단위다. 이 모델에서는 65단위, 약 35.1%를 아낀다.

타이밍은 sel이 언제 오는지에 따라 달라진다. 데이터 입력 a·b·c·d는 기준 시각 0에 도착하고 sel은 300ps에 도착한다고 하자. 각 셀의 지연은 어느 입력이 마지막으로 도착했는지에 같은 고정값을 더하는 방식으로 계산한다.

병렬 구현에서 두 합은 350ps에 준비된다. 출력 mux의 데이터는 350ps, 선택은 300ps에 준비되므로 최종 출력은 `max(350, 300) + 90 = 440ps`다. 공유 구현의 입력 mux는 sel을 기다려 `max(0, 300) + 80 = 380ps`에 값을 내보낸다. 여기에 덧셈 350ps가 이어져 출력은 730ps에 준비된다.

700ps 안에 결과를 제공해야 한다면 병렬 구현은 이 가상 조건에서 맞지만 공유 구현은 맞지 않는다. 덧셈기 자체가 느려진 것이 아니다. 늦게 오는 선택이 덧셈의 앞쪽으로 이동하면서 **선택이 끝난 다음에야 긴 연산을 시작할 수 있는 경로**가 됐다.

## 선택이 빠르면 결론도 달라진다

sel도 시각 0에 준비되면 공유 구현은 80+350=430ps, 병렬 구현은 350+90=440ps다. 같은 모델에서도 공유 쪽이 조금 빠르다. 그러므로 연산기 공유가 항상 타이밍을 악화한다고 결론낼 수는 없다. 선택의 도착 시간, 입력 mux와 출력 mux의 실제 지연, 각 입력의 경로가 함께 결정한다.

실제 회로에서는 셀 지연이 입력 slew와 출력 부하에 따라 달라지고, 배선과 sel의 fan-out도 영향을 준다. 공유된 자원 주변으로 배선이 몰리거나 추가 버퍼가 필요할 수 있다. 단순한 셀 개수 차이가 최종 면적 차이와 같다고 가정하지 말고, 같은 제약으로 매핑하고 배치한 결과에서 비용을 확인해야 한다.

기능 보존도 함께 봐야 한다. 피연산자의 비트폭과 부호가 다른 연산을 무턱대고 같은 크기로 묶으면 확장 의미가 달라질 수 있다. 파이프라인 내부에서 공유한다면 어느 요청이 어느 피연산자와 선택 신호를 사용하는지도 맞아야 한다. 연산기 수가 줄었다는 로그는 이런 관계가 유지된다는 검증을 대신하지 않는다.

공유 여부를 결정할 때는 먼저 동시에 필요한 결과를 확인하고, 그다음 선택 신호가 연산 전후 어디에서 시간을 쓰는지 그려 보면 된다. 작은 면적이 목표여도 제한 시간과 처리량을 만족해야 실제로 사용할 수 있다. 두 번째 연산기의 비용과 새 입력 선택 경로의 비용을 같은 조건에서 비교하면, 연산기 하나가 더 나은 선택인지 구체적으로 판단할 수 있다.