Design Conductor가 219단어 요구사항 문서만으로 12시간 안에 1.48 GHz 타이밍을 만족하는 Linux 구동 가능 RISC-V CPU를 사양부터 GDSII까지 자율적으로 설계한 과정과 결과를 설명합니다.
(2026년 2월 6일)
Design Conductor (DC)는 최첨단 모델의 역량을 적용해 반도체를 엔드투엔드로 구축하는 자율 에이전트다. 즉, 개념에서 시작해 검증을 마치고 테이프아웃 준비가 된 GDSII(레이아웃 CAD 파일)까지 만든다. 12시간 동안 완전히 자율적으로, DC는 219단어 분량의 요구사항 문서에서 출발해 1.48 GHz에서 타이밍을 만족하는 완전한 RISC-V CPU의 여러 마이크로아키텍처 변형(이를 우리는 “VerCore”라고 부른다)을 구축할 수 있었다. 1 1 1 rv32i_zmmul; using the ASAP 7nm PDK. VerCore는 3261의 CoreMark 점수를 달성한다. 역사적 맥락에서 보면 이는 2011년 중반의 Intel Celeron SU2300(1.2 GHz로 동작)과 대략 비슷한 수준이다. 우리가 아는 한, 자율 에이전트가 사양부터 GDSII까지 완전하고 동작하는 CPU를 구축한 것은 이번이 처음이다. 이 보고서는 다음과 같이 구성된다. 먼저 DC의 설계와 핵심 구성요소를 검토한다. 그다음 DC가 VerCore를 구축하기 위해 따른 방법론을 설명한다. 여기에는 RTL 구현, 테스트벤치 구현, 프런트엔드 디버깅, 타이밍 클로저 달성을 위한 최적화, 백엔드 도구와의 상호작용이 포함된다. 이어서 결과물인 VerCore의 핵심 특성을 검토한다. 2 2 2 The VerCore RTL source and scripts necessary to rebuild the GDSII will be publicly available. 마지막으로, 이 응용을 더 잘 가능하게 하기 위해 최첨단 모델이 어떻게 개선될 수 있는지, 그리고 DC와 같은 시스템의 역량으로 가능해질 미래의 칩 구축 방식에 대해 우리가 얻은 교훈을 강조한다.
\correspondence
(a)VerCore 설계 A (더 높은 성능)
(b)VerCore 설계 B
Figure 1: VerCore 설계의 GDSII 플롯 (70 µm 70\text{,}\mathrm{\SIUnitSymbolMicro m}×\times 70 µm 70\text{,}\mathrm{\SIUnitSymbolMicro m})
기존의 오래된 설계에서 시작하든 완전히 처음부터 시작하든, 칩을 만드는 일은 매우 많은 시간과 비용이 드는 작업이다. 새로운 최첨단 설계를 시장에 출시하는 데는 $400M를 훨씬 넘는 비용이 들고, 수백 명 규모의 엔지니어링 팀이 있어도 18~36개월이 걸린다는 점은 널리 알려져 있다. 최첨단 칩 설계 프로세스는 서로 구분되는 많은 단계로 이루어지며, 각 단계는 대형 소프트웨어 프로젝트에 맞먹는 노동력을 요구할 수 있다. 여기에는 아키텍처 정의, RTL 구현, 테스트벤치 구현 및 기능 검증, 프런트엔드 합성, 배치 및 배선, 전력 추정, 패키징이 포함된다. 또한 상업적으로 실용적인 칩은 실제로 설계 반복을 거쳐야 만족할 수 있는 여러 상호 얽힌 제약을 마주한다. 이로 인해 추가로 수개월이 더 소요된다.
그중에서도 가장 중요한 것은 매우 높은 기능 테스트 커버리지 요구사항이다. 즉, 장치의 동작에 “버그”가 없다는 것을 매우 높은 신뢰도로 보장하기 위한 테스트다. 한 번의 테이프아웃 비용이 수천만 달러에 이를 수 있기 때문에, 양산 후 버그를 “수정”하는 것은 선택지가 될 수 없다. 이것이 “검증” 비용을 높이는 주요 원인이며, 흔히 전체 비용의 50%를 넘는다고 추정된다. 더 나아가 칩은 여러 엄격한 성능 요구사항을 만족해야 하며, 일반적으로 최소한 클록 속도, 전력 소비, 실리콘 면적(생산 비용에 영향)을 포함한다. 검증에 필요한 다양한 시뮬레이션 유형은 실제 경과 시간 기준으로도 느리고 서버 시간 측면에서도 비용이 많이 든다. 전자설계자동화(EDA) 도구 또한 설정 가능 항목이 매우 많고, 설계에 대해 좋은 최종 결과를 얻기 위해서는 상당한 전문성이 필요하다.
이러한 비용과 도전 과제 때문에 많은 실리콘 시장은 소수의 공급업체만이 담당하며, 스타트업의 진입은 소프트웨어 산업보다 더 드물다. 게다가 더 많은 잠재적 설계가 전용 칩을 만들 만큼 물량이 충분하지 않다고 여겨진다. 그리고 최신 기술이 최종 소비자에게 도달하기까지는 일반적으로 수년과 막대한 엔지니어링 비용이 든다.
장기간 실행되는 자율 AI 에이전트는 이러한 패러다임을 바꿀 유망한 기회를 제시한다. 설계 프로세스를 완전히 가속하고 Amdahl의 법칙의 함정에 빠지지 않으려면, 이러한 에이전트는 문제 전체를 다루어야 한다. 즉, 테이프아웃 준비가 된 GDSII [gds1978gds]까지 전 과정을 처리해야 한다. 이 보고서의 나머지 부분에서는 이를 수행하기 위해 Design Conductor (DC)가 어떻게 작동하는지 설명한다.
이 절에서는 DC의 핵심 역량과 이를 뒷받침하는 아키텍처 및 인프라를 검토한다.
우리는 DC가 실현하도록 구축된 핵심 역량 몇 가지를 나열한다.
섹션 1에서 설명했듯이, 칩 설계는 많은 하위 구성요소를 포함하는 복잡한 작업이다. DC는 소비된 수백억 토큰에 걸쳐 목표, 즉 기능적으로 올바르고 고성능인 설계를 향해 진전을 이룰 수 있어야 한다. 이 목표는 단일한 것이 아니라 여러 설계 목표의 조합이다. 전력, 성능, 면적(PPA), 기능 제약, 아키텍처 입력을 모두 포함한다. DC는 이 모든 것을 기억하고 충족해야 한다.
DC는 자신이 사용하는 기반 LLM이 좋은 결정을 내리는 데 필요한 정보를 제공해야 한다. 또한 제한된 컨텍스트 윈도 사용을 신중히 관리해야 하며, 단지 오버플로를 피하는 데 그치지 않고 품질을 최대화해야 한다.
LLM은 여러 분야에 걸친 깊은 지식에서 놀라울 정도의 역량을 보이며, 이는 이미 인간의 능력을 능가한다고 주장할 수 있는 한 측면이다. 그러나 칩 설계는 특정 영역에서 극도로 깊은 지식을 요구한다. 예를 들어, 뛰어난 CPU 설계자는 좋은 성능을 달성하기 위한 특정한 “트릭”과 “레시피”를 이해한다. 유용하려면 DC는 현장 전문가와 원활하게 협업할 수 있을 만큼 충분히 높은 수준의 지식을 달성해야 한다. 또한 다양한 유형의 설계 전반에서 높은 성능을 달성하는 데 무엇이 필요한지 이해해야 한다.
수백만 개의 유닛을 출하하는 상황에서 “감으로 하는 칩 설계”는 선택지가 될 수 없다. DC는 검증 가능하게 올바른 설계를 제공해야 한다.
칩의 설계 공간은 방대하다. DC는 최적의 성능을 달성하기 위해 사용자의 지시를 준수하면서도 그 공간을 탐색할 수 있어야 한다. 동시에 “토끼굴”로 빠져 전체 목표를 제때 달성하지 못하는 상황을 피해야 한다. 이는 탐색과 검색을 규율 있게 관리할 것을 요구한다.
인간 칩 설계 프로세스에서 가장 비용이 많이 들고 고통스러운 부분은, 테이프아웃 직전에 타이밍(클록 속도) 목표를 맞추거나 “코너 케이스” 기능 버그를 수정하기 위해 마지막 순간에 RTL 변경이 필요한 경우다. 이유는 분명하다. 적어도 이전 설계 노력의 일부를 뜯어고쳐야 하고, 더 많은 버그를 추가할 위험도 생기기 때문이다. DC는 설계를 구축하는 과정에서 같은 종류의 작업을 수행해야 하며, 이때 이전 작업에 대한 필요한 컨텍스트와 기억을 유지해야 한다.
대규모 칩 설계는 하드웨어 자원을 매우 많이 요구한다. 디버깅에 사용되는 VCD 트레이스 파일은 쉽게 수백 기가바이트에 이를 수 있고, EDA 도구는 합성, 배치, 배선 중 설계를 최적화하기 위해 대량의 DRAM을 사용한다. 또한 DC는 작업을 적시에 완료하기 위해 여러 서브에이전트 인스턴스가 함께 동작해야 할 수 있다. 이는 DC를 지원하는 인프라가 확장성과, 특히 신뢰성 측면에서 세계적 수준이어야 함을 의미한다.
Figure 2: Design Conductor 아키텍처의 상위 수준 개요
우리는 그림 2에 상위 수준 아키텍처 개요를 제시한다.
DC는 분산 파일 시스템 위에서 실행되는 확장 가능한 클라우드 기반 애플리케이션이다. LLM 세션은 워커 서버가 관리하며, 이들 모두는 중앙 DB와 동기화된다. 이 세션들은 하나 이상의 실행 환경에 존재하는 도구 서버에 연결되며, 실행 환경은 VM 또는 컨테이너일 수 있다. 컨텍스트 관리 모듈은 특정 시점에 진행 중인 여러 세션의 전체 컨텍스트 윈도 사용량을 모니터링하고 제어한다. 일반적으로 Bash, Edit, Subagent 도구만 있으면 충분하지만, 품질 향상을 위해 이들의 맞춤형 버전과 추가 도구를 사용할 수 있다. 서브에이전트와 더 상위 수준의 알고리즘(예: 진화적 알고리즘)은 최상위 DC Core 모듈에 의해 관리되며, 이 모듈은 하위 수준 LLM 세션과 상호작용한다.
구체적인 지식은 전용 지식 베이스를 통해 DC에 제공된다. 이 지식 베이스는 메인 메모리 시스템 안에 포함된다. 메모리는 무기한 존재하며 완전히 자율적으로 관리된다. DC는 새로운 코드베이스에 스스로 온보딩할 때나, 사용자가 제공한 요구사항을 흡수할 때 이 메모리를 활용한다. 이 메모리는 또한 사용자가 요청한 설계의 모든 요구사항을 DC가 충족하게 하고, DC가 구축 중인 설계가 모든 정확성 요구사항을 만족하게 하는 데 핵심적이다. 하나의 DC “인스턴스”는 한 고객의 설계 전용으로 할당되며, 코드, 메모리, 또는 어떤 정보도 고객 간에 교차하지 않는다.
이들 모듈의 실제 설계는 독점 정보이며 이 보고서에서는 더 이상 다루지 않는다.
DC에 대한 실제 사용자 입력은 다음 문서뿐이었다.
DC에는 또한 Spike [spike], RISC-V ISA 시뮬레이터, RISC-V ISA [waterman2011risc] 및 ASM 매뉴얼, 그리고 RISC-V GNU 툴체인에 대한 접근 권한이 제공되었다.
Figure 3: Design Conductor의 전형적인 설계 프로세스. VerCore의 경우 “기존 설계”는 없다는 점에 유의하라.
그림 3은 VerCore를 구축하기 위해 DC가 거친 단계를 보여준다. 이 프로세스는 궁극적으로 DC의 통제하에 있으며, DC는 각 설계 프로젝트에 맞게 이를 맞춤화하거나 수정하고 실행할 수 있다. 우리는 단지 도표에 나타난 역량들을 DC의 일부로 제공했을 뿐이며, 그 조합은 섹션 2에서 설명한 DC Core 모듈이 결정한다.
DC는 사용자가 제공한 입력으로 시작한다. 이 입력, 자신의 메모리, 그리고 지식에 따라 초기 설계 제안을 생성한다. 이 제안의 일부 발췌가 아래에 제시된다. 설계 제안은 “살아 있는” 문서로서, 아키텍처의 기능 또는 타이밍 문제를 수정함에 따라 DC가 이를 갱신한다. 실제로 우리는 배치 및 배선 후 최종 타이밍의 피드백을 바탕으로 DC가 설계를 갱신하는 것을 관찰했다.
그다음 제안의 모든 측면을 검토한다. DC 자신의 표현에 따르면, 구현을 시작하기 전에 설계가 적절함을 보장하기 위해 이 검토는 “수작업적”이고 “고된” 방식으로 이루어진다. 곱셈기 유닛 설계에 대한 그러한 검토의 한 발췌를 아래에 보인다.
이 설계 단계가 끝나면, DC는 실제 모듈 구현으로 넘어간다. DC는 항상 모듈별 테스트벤치를 구축하고, 다음 단계로 진행하기 전에 이 테스트벤치가 통과하도록 모듈 기능을 수정한다.
이 시점에서 DC는 통합 테스트에 집중한다. DC는 Spike를 사용해 전체 vercore_tb.v 테스트벤치를 구성하는데, 이는 주어진 RISC-V ELF에 대해 DUT에서 테스트 프로그램을 실행하고 설계의 아키텍처 상태와 메모리 트랜잭션이 Spike가 보고한 내용과 일치하는지 확인한다. DC는 MD5를 포함한 많은 테스트 프로그램에 대해 이를 수행했고, 궁극적으로는 CoreMark 자체에도 적용했다.
이 과정에서 Spike와의 불일치가 발견되면, DC는 해당 조건을 관찰하고 VCD 파일을 조사해 문제를 디버깅한다. 일반적으로 VCD를 CSV 파일로 변환하고, 자체적인 Python 능력을 활용해 처리를 쉽게 만든다.
VCD 분석을 사용해, DC는 문제의 근본 원인을 추적하고, 수정안을 제안하고, 이를 구현한 뒤 다시 테스트한다.
이처럼 검증 주도 접근법이 DC로 하여금 동작하는 설계에 도달하게 한다.
모든 테스트 프로그램이 Spike 기반 테스트벤치를 통과하면, DC는 PPA 클로저로 이동한다. DC는 타이밍 보고서를 검토하고 이 정보를 사용해 설계에 RTL 변경을 가한다. 이 과정에서 ID 단계에서 조기 포워딩을 구현하는 방법을 찾아냈고, 4단계로 균형 잡히며 숙련된 설계자에게 알려진 가장 일반적인 병렬성 형태를 구현하는 고속 Booth-Wallace 곱셈기를 구현했다.
DC는 무기한 실행될 수 있지만, 이 경우에는 소비된 토큰 수가 일정 수준에 이르자 실행을 종료했다. 그 시점의 결과를 섹션 4에서 보고한다.
Table 1: VerCore 핵심 지표
표 1은 VerCore의 핵심 정량 지표를 보여준다.
Figure 4: VerCore 파이프라인 다이어그램.
그림 4는 최종 VerCore의 파이프라인을 보여준다. 이 작업에서 DC는 파이프라인의 여러 버전을 생성했으며, 그림에 보인 버전이 그중 가장 높은 성능을 달성한다. 가능한 경우 조기 분기 해석, 조기 포워딩, 그리고 고효율 Booth-Wallace 곱셈기(이 자체만으로 2.57 GHz로 동작함)를 특징으로 한다. 이러한 속성은 DC가 발견한 것이며 어떤 입력 지시에도 포함되어 있지 않았다(3 참조).
DC는 “추측”에 의존하지 않았다. 대신, 각 변형에 대해 전체 Verilog 구현을 수행했다(일부는 2사이클 분기 페널티, 일부는 1사이클). DC는 각 변형을 GDSII까지 완전히 구현했다. DC는 추가 비교기 로직이 포함된 더 긴 타이밍 임계 경로를 가지더라도, 1사이클 분기 페널티 설계로 클록 속도 목표를 달성할 수 있다고 결론지었다. DC는 본질적으로 원래의 MIPS 5단계 RISC CPU 설계의 임계 경로를 다시 발견했으며, 그 설계 역시 1사이클 분기 페널티를 특징으로 했다.
이 작업에서 우리가 마주한 몇 가지 “LLM의 걸림돌”을 아래에 열거한다. 이러한 이유로, 우리는 DC와 같은 시스템을 안내하는 데 경험 많은 인간 아키텍트가 여전히 중요하다고 믿는다.
기반 모델이 추가적인 도움을 필요로 하는 영역 중 하나는 아키텍트처럼 추론하는 능력이다. 우리는 모델이 비최적 설계 선택을 하는 사례를 관찰했으며, 이를 최적화하는 데 결국 많은 토큰이 필요했다. 예를 들어, 포워딩 구현은 처음에 지나치게 긴 임계 경로를 초래하는 방식으로 이루어지는 경우가 많았다. 모델은 타이밍 결과를 관찰한 뒤에야 문제를 파악하고 이를 수정했다. 이러한 종류의 지식은 인간 설계자에게는 종종 경험을 통해 체득된다.
또한 DC는 어떤 경우 특정 문제를 해결하는 데 필요한 작업의 복잡성을 과소평가한다. 예를 들어 한 사례에서는 타이밍을 만족하지 못했을 때, 더 단순한 설명을 찾는 대신 파이프라인을 더 깊게 만드는 대규모 수정부터 시도했다. 이는 불필요하게 토큰을 소비한 낭비성 탐색이었고, 더 나은 아키텍처 및 엔지니어링 이해가 있었다면 피할 수 있었다.
우리는 모델이 이벤트 구동 언어인 Verilog를 순차 코드인 것처럼 추론하는 사례를 관찰했다. 이것이 DC의 기능적 정확성 달성 능력에 영향을 미치지는 않았다고 보지만, 타이밍 문제를 디버깅하는 일은 더 어렵게 만들었다. 기억에 남는 한 사례에서 DC는 의존적인 코드 줄 수를 줄이면 칩의 임계 경로가 짧아질 것이라고 잘못 추론했다. 이러한 오류는 궁극적으로는 수정된다. DC가 도구로부터 실제 타이밍 보고서에 접근할 수 있기 때문이다. 하지만 이런 오류는 DC의 진전을 늦추고 추가 토큰을 소비하게 만든다.
우리는 이것이 LLM의 사전학습과 후속학습 모두에서 소프트웨어 코드가 매우 큰 비중을 차지하기 때문이라고 본다. 또한 최첨단 연구소들이 칩 설계를 더 중요한 응용 분야로 인식하게 되면, 이 문제는 해결될 것으로 기대한다.
우리는 DC에 제공되는 입력 사양이 극도로 의도적이고, 간결하며, 검증 가능하고 측정 가능한 방식으로 작성되어야 한다는 사실을 발견했다. 예를 들어 그 문서에 CPI 요구사항이 없으면, DC는 때때로 분기와 포워딩에서 성능이 현저히 떨어지는 프로세서를 생성하곤 했다. 사양에 그 한 줄이 있으면, DC는 Spike 트레이스에 보고된 PC당 사이클을 계산하기 위해 테스트벤치에서 사이클 카운터를 사용하여 CPI를 추정했다. 이런 방식으로 목표를 충족하는지 보장할 수 있었다.
이 절에서는 DC와 같은 시스템을 어떻게 확장해 상업적 복잡도의 설계를 다룰 수 있을지, 그리고 이러한 새로운 역량을 최대한 활용하기 위해 인간 설계 팀을 어떻게 구성할 수 있을지에 대한 저자들의 견해를 설명한다.
우리는 매우 큰 코드베이스, 예를 들어 수백만 줄의 Verilog를 가진 경우로 확장하는 것이 DC에 특별한 문제를 일으키지 않는다는 사실을 발견했다. 13단계 OoO 프로세서의 코드베이스에서 수행한 테스트에서, DC는 VerCore를 다룰 때와 마찬가지로 기능 및 타이밍 문제를 해결할 수 있었다. 이는 코드베이스 정보를 메모리에 구조화하는 방식 덕분이다.
이 정도 복잡성의 설계를 다루는 데 있어 핵심 과제는 코드베이스를 다루는 기계적 문제에 있는 것이 아니라, 좋은 결과를 얻기 위해서는 DC를 특정 설계 영역에 경험이 있는 아키텍트가 운용해야 한다는 점에 있다.
Figure 5: 팀이 DC를 가장 효과적으로 활용하기 위해 어떻게 재구성될 수 있는지를 보여주는 그림. 더 많은 설계와 제품 아이디어가 여러 하위 팀에 의해 탐색될 것이며, 각 팀은 하나의 설계를 처음부터 끝까지 생산할 수 있다.
DC와 같은 시스템으로 힘을 얻게 되면, 현재 하나의 설계를 위해 100명 이상이 일하는 팀은 여러 가지 서로 다른 설계, 아키텍처, 제품 아이디어를 동시에 탐색할 수 있게 될 것이며, 각각을 개념에서 GDSII까지 추진할 수 있게 될 것이다. 이 팀들은 현재의 18~36개월 대신 3~6개월 안에 존재하는 가장 복잡한 설계를 테이프아웃할 수 있게 될 것이다. 이러한 전문가들의 역할은, 시장에서 성공할 것이라 믿는 설계 결과를 얻기 위해 아키텍처와 목표 수준에서 DC를 안내하는 것으로 바뀔 것이다. 이들은 추측 없이 실험할 수 있고, 더 공격적인 비용 및 성능 목표를 밀어붙일 수 있다. 기업들 또한 이전에는 수익성 있게 대응하기엔 물량이 너무 적었던 응용 분야에서 훨씬 더 많은 공략 가능한 소켓을 찾게 될 것이다.
하나의 유력한 프로세스 변화는 검증 작업을 앞단에 배치하는 것이다. 그러면 DC에 RTL 구현을 안내할 일종의 통합 테스트를 제공할 수 있다.
이러한 미래 팀의 시니어 엔지니어와 마스터 설계자는 훨씬 적은 “도구 조작” 책임을 지게 될 것이며, 대신 판단력과 경험에 의존하는 역할을 맡게 될 것이다. DC가 거의 모든 다른 엔지니어링 작업을 처리할 수 있기 때문이다. 도구 상호작용을 관리하는 DC의 능력은 도구 전환 비용과 종속도 또한 줄일 것이다. 도구 공급업체는 인터페이스 설계와 사용자를 위한 단순한 환경 보장에 노력을 들이기보다, 알고리즘의 품질에 집중할 수 있게 될 것이다.
