RTL 생성은 겉으로 보면 소프트웨어 코드 생성과 비슷합니다. 요구사항을 문장으로 입력하고 코드를 받기 때문입니다. 그러나 검증 단계에서는 차이가 큽니다. RTL의 잘못된 분기 하나는 프로토콜 교착, 초기화되지 않은 상태, 반복되는 연산 오류 또는 닫히지 않는 타이밍 경로로 구현됩니다. 문법에 맞는 코드를 얻는 일은 전체 문제에서 가장 쉬운 부분입니다.
최근 네 편의 논문은 모델 주변에 어떤 체계가 필요한지를 서로 다른 방향에서 보여 줍니다. Spec2RTL-Agent는 긴 규격 문서를 나누고 여러 에이전트가 구현 계획, 합성 가능한 C++ 생성, 검토를 담당합니다[2]. ScaleRTL은 긴 추론 이력으로 학습하고 추론 단계에서 자기 검토에 계산량을 더 씁니다[3]. StepPRM-RTL은 완성된 모듈만 채점하지 않고 중간 판단 단계에 보상을 줍니다[1]. ASPEN은 기능 생성에서 더 나아가 동등성이 보장되는 데이터 경로를 탐색하고 실제 PPA 결과를 다음 선택에 반영합니다[4]. 네 연구를 함께 보면 RTL 자동화의 단위는 자동 완성이 아니라 제어 가능한 검증 과정입니다.
코드보다 중요한 검증 이력
RTL의 정확성에는 여러 층이 있습니다. 먼저 파싱과 엘라보레이션을 통과해야 합니다. 시뮬레이션에서는 정상 입력뿐 아니라 경계 조건과 잘못된 순서에서도 의도한 값을 내야 합니다. 형식 검증 속성은 지정된 범위의 모든 도달 가능한 상태에서 성립해야 합니다. 합성 후에도 기능을 유지하면서 목표 공정의 면적과 지연 조건을 만족해야 합니다. 클록, 리셋, 인터페이스, 지연 시간 계약은 단위 시험만으로 드러나지 않을 수 있습니다.
한 번에 코드를 생성하는 모델은 대부분의 검증 결과를 구현을 끝낸 뒤에 받습니다. 반면 실제로 쓸 수 있는 자동화는 규격을 어떻게 나눴는지, 어떤 상태 변수를 만들었는지, 핸드셰이크가 왜 진행되는지, 어떤 속성이 실패했는지, 어느 재작성으로 면적이나 지연이 바뀌었는지를 남깁니다. 문제가 생겼을 때 원인을 찾을 수 있고, 전부 다시 쓰지 않고 실패 지점에서 수정을 시작할 수 있습니다.
배포 과정에서도 이 구분이 중요합니다. 엔지니어는 완성된 모듈이 맞을 확률보다 상태 전이와 검증 속성을 더 정확히 검토할 수 있습니다. 어떤 시뮬레이터, 테스트벤치, 합성 라이브러리, 모델 버전이 각 수정을 만들었는지도 기록할 수 있습니다. 이 이력이 없다면 벤치마크 점수가 높아져도 재현 가능한 설계 절차는 만들어지지 않습니다.
코드 생성보다 앞선 규격 분해
복잡한 규격 문서는 실행 가능한 모듈 순서로 작성되지 않습니다. 요구사항, 예외 조건, 타이밍 규칙, 레지스터 설명, 도표와 서로 다른 독자를 위한 문장이 섞여 있습니다. Spec2RTL-Agent는 문서를 해석하고 구현 계획을 만든 뒤 합성 가능한 C++을 생성하며, 검토를 거쳐 HLS 도구로 RTL을 만듭니다[2]. 세 종류의 규격 문서를 사용한 평가에서 사람이 개입해야 하는 횟수를 최대 75% 줄였습니다.
C++과 HLS를 거친다는 조건을 함께 읽어야 합니다. 이 방법은 모든 RTL을 자유롭게 생성하는 대신 기존 컴파일러가 스케줄링과 자원 공유, 파이프라이닝, 인터페이스 구현을 담당할 수 있는 표현을 사용합니다. 알고리즘 중심 블록에는 생산성이 높을 수 있지만, HLS가 결정한 마이크로아키텍처가 요구 조건에 맞는지는 별도로 검토해야 합니다.
사람이 개입한 지점도 실패로만 볼 필요는 없습니다. 요구사항이 모호하거나 통합 조건이 빠졌거나 생성된 구조가 의도한 설계와 다를 때 질문이 생깁니다. 이 질문과 답을 보존하면 코드보다 더 가치 있는 실행 가능한 규격이 됩니다. 다음 블록이나 다음 버전에서 같은 모호성을 다시 해결할 필요가 없기 때문입니다.
추론과 수정에 계산량을 쓰는 ScaleRTL
ScaleRTL은 평균 약 5만 6천 토큰 길이의 추론 이력을 포함한 35억 토큰 학습 데이터와 추론 시 자기 검토를 결합합니다[3]. 18개 기준 모델과 비교한 결과 VerilogEval에서 최대 18.4%, RTLLM에서 최대 12.7% 개선했습니다. 요구 조건을 해석하고 후보를 만들고 시험한 뒤 수정하는 과정에 계산량을 쓰는 것이 RTL 생성에도 효과가 있음을 보여 줍니다.
다만 18.4%를 칩 설계팀 생산성이 같은 비율로 늘었다고 읽으면 안 됩니다. 두 벤치마크는 테스트벤치로 성공 여부를 판단할 수 있는 제한된 문제입니다. 실제 블록에는 클록 도메인 교차, 리셋 순서, 저전력 동작, 검증 커버리지, 코딩 규칙과 문서에 없는 상호작용이 추가됩니다. 추론 계산량의 가치는 이런 조건을 반영한 평가기에 연결될 때 생깁니다.
실제 시스템에서는 모델이 자기 설명만 오래 검토하게 두어서는 안 됩니다. 각 반복에서 시뮬레이터, 린터, 엘라보레이터, 형식 검증기 또는 합성 도구를 호출하고 구조화된 결과를 다음 수정 작업으로 바꾸어야 합니다. 추론 토큰 자체는 근거가 아닙니다. 원인을 구분할 수 있는 도구의 관측값이 근거입니다.
중간 판단을 학습하는 StepPRM-RTL
일반적인 코드 생성 학습은 마지막에만 보상을 줍니다. 모듈이 통과했는지 실패했는지만 표시하면 올바른 규격 해석과 상태 분해가 포함된 실패 사례도 모두 같은 값이 됩니다. StepPRM-RTL은 단계별 추론 이력으로 과정 보상 모델을 학습하고, 보상 기반 미세 조정과 트리 탐색으로 더 나은 판단 경로를 선택합니다[1]. IBM은 비교 대상 중 가장 좋은 기존 방식보다 기능 정확성과 추론 충실도를 10% 넘게 개선했다고 보고했습니다.
하드웨어에서는 초반의 구조 결정이 이후 수정 범위를 정하기 때문에 과정 보상이 중요합니다. 큐가 필요한 프로토콜을 단순 카운터로 해석했다면 국소 수정으로 해결하기 어렵습니다. 반대로 인터페이스 해석과 상태 분해가 옳았다면 그 부분을 보존하고 잘못된 전이만 탐색하는 편이 효율적입니다.
과정 보상의 품질은 누가 중간 단계를 평가하는지에 달려 있습니다. 얕은 테스트로 라벨을 만들면 테스트벤치의 빈틈을 학습합니다. 다른 언어 모델만 평가하면 회로 정확성보다 설명의 그럴듯함이 보상이 될 수 있습니다. 파싱, 속성 커버리지, 반례 위치, 합성 가능성, 명시된 규격과의 일치 여부를 함께 사용해야 합니다.
동등성 안에서 PPA를 찾는 ASPEN
기능이 맞는 RTL을 얻어도 최적화는 남습니다. 같은 연산을 표현하는 두 코드가 합성 후에는 전혀 다른 회로가 될 수 있습니다. ASPEN은 데이터 경로를 동등성 그래프로 나타내고, LLM이 재작성 후보를 제안하며, 정리 증명기로 동작이 같은지 확인한 뒤 상용 EDA 흐름의 PPA 결과로 후보를 정렬합니다[4]. 기존 동등성 그래프 방식과 비교해 평균 면적 16.51%, 지연 6.65% 개선을 보고했습니다.
정리 증명기는 모델의 권한을 제한합니다. 모델은 예상 밖의 대수 변환을 제안할 수 있지만 기능을 바꿀 권한은 없습니다. 동등성이 허용 영역을 정하고 합성 결과가 그 안의 후보를 평가합니다. 한 모델이 최적화와 자기 검증을 모두 담당하는 방식보다 신뢰하기 쉬운 구조입니다.
독립적으로 운영할 세 가지 루프
첫 번째는 기능 검증 루프입니다. 요구사항을 속성과 시험으로 바꾸고 후보를 실행해 실패 위치를 찾습니다. 정상 예제 통과만으로 멈추지 않고 프로토콜 불변 조건, 금지 상태, 순서, 리셋 동작의 커버리지를 종료 조건으로 사용해야 합니다.
두 번째는 구조 검증 루프입니다. 합성 가능성, 클록과 리셋 규칙, CDC 경계, 린트, 통합 규칙을 확인합니다. 기능이 맞아도 의도하지 않은 래치, 조합 루프, 인터페이스 규칙 위반이 있으면 사용할 수 없습니다. 이 규칙은 블록과 함께 버전으로 관리해야 합니다.
세 번째는 물리 비용 루프입니다. 합성과 초기 타이밍으로 선택한 구조의 면적과 지연을 평가합니다. 국소 변환은 동등성 검증으로 기능을 보호하면서 PPA를 탐색할 수 있습니다. 지연 시간이나 자원 공유가 바뀌는 큰 구조 변경은 외부 동작에 영향을 줄 수 있으므로 다시 기능 루프로 돌아가야 합니다.
세 루프를 나누면 실행 비용도 관리할 수 있습니다. 값싼 린트와 시뮬레이션은 모든 후보에 적용하고, 상태 구조나 속성이 바뀔 때 형식 검증을 수행하며, 앞 단계를 통과한 후보에만 전체 합성을 실행할 수 있습니다. 에이전트형 RTL 생성은 모델 문제이면서 동시에 도구를 어떤 순서로 호출할지 정하는 오케스트레이션 문제입니다.
통과율보다 필요한 실패 분류
하나의 통과율은 산술 비트 폭, 시간 동작, 인터페이스, 모호한 요구사항 중 어디에서 실패했는지 가립니다. 비트 확장 오류는 국소 수정으로 끝날 수 있지만 트랜잭션 모델이 틀리면 블록을 다시 설계해야 합니다. 실패 유형별 분포를 보고해야 점수 개선이 비싼 오류를 줄였는지 판단할 수 있습니다.
익숙한 템플릿과 새로운 조합도 분리해야 합니다. 카운터, FIFO, 중재기는 공개 예제가 많습니다. 새로운 프로토콜 규칙, 매개변수 폭, 백프레셔, 여러 클록, 복구 순서를 함께 요구하는 문제가 실제 차이를 드러냅니다. 데이터 누출을 막은 분할과 규격 변형 시험이 필요한 이유입니다.
PPA 비교에는 같은 합성 조건이 필요합니다. 라이브러리, 클록 제약, 합성 노력 수준, 물리 가정이 결과를 바꿀 수 있습니다. 면적과 지연 옆에 동등성 결과와 도구 구성을 함께 기록해야 다른 프로젝트에서 재현할 수 있습니다.
도입 범위와 권한 경계
가까운 시기에 효과가 큰 대상은 대형 서브시스템 전체가 아닙니다. 레지스터 블록, 프로토콜 어댑터, 산술 데이터 경로, 테스트벤치 확장, 속성 생성, 기능을 보존하는 재작성처럼 평가 기준이 분명한 작업입니다. 인터페이스를 명시할 수 있고 도구 결과를 빠르게 돌려받을 수 있기 때문입니다.
배포 단위에는 규격 범위, 생성된 속성, 도구 버전, 후보 이력, 반례, 합성 보고서를 함께 넣어야 합니다. 엔지니어는 계약과 최종 절충을 승인하고 자동화는 그 경계 안에서 탐색과 수정을 맡습니다. 그러면 모델의 변동성이 설명되지 않은 코드 변경이 아니라 기록된 후보군으로 남습니다.
네 논문이 가리키는 방향은 같습니다. 더 좋은 RTL 자동화는 모델에 구조화된 일을 더 주고 검증되지 않은 권한은 줄일 때 만들어집니다. 계획은 요구사항을 명시하고, 추론 계산은 후보를 탐색하며, 과정 보상은 올바른 중간 결정을 보존하고, 형식 동등성은 최적화 범위를 제한합니다. 코드가 산출물이지만 설계팀이 신뢰할 대상은 이 과정을 운영하는 시스템입니다.
출처와 저작권 안내
이 글은 인용한 네 논문과 공식 공개 기록을 바탕으로 Silicon & Systems가 독립적으로 작성한 편집 분석입니다. 기술 내용과 수치는 우리 표현으로 다시 설명했으며 원문의 문장, 표, 벤치마크 구성 또는 도판을 복제하지 않았습니다. 두 도판은 이 글을 위해 새로 만들었습니다. 인용 논문의 저작권은 각 출판사와 저자에게 있습니다.