AI-Generated RTL Code: A Functional Evaluation of Natural-Language and HLS Prompting
본 연구는 상용 LLM이 고수준 명세로부터 기능적인 Verilog RTL을 생성하는 능력을 평가하며, HLS-C 프롬프트를 사용하는 것이 자연어 사용 시보다 정확도를 유의미하게 향상시킨다는 점을 발견하는 동시에, 시뮬레이션 오류와 가변 비트 폭에 대한 제한된 일반화라는 지속적인 과제를 드러낸다.
원본 논문은 CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기
당신이 마이크로칩 안에 아주 작고 초고속인 공장을 지으려 한다고 상상해 보세요. 이것은 장난감이나 자동차를 만드는 공장이 아니라, 빛의 속도로 정보를 처리하는 디지털 공장입니다. 이 공장을 짓기 위해 엔지니어들은 RTL 코드(Register-Transfer Level)라고 불리는 특별한 종류의 설계도(instruction manual)를 작성합니다. 이 코드는 공장의 컨베이어 벨트, 조립 팔, 그리고 신호등을 위한 청사진이라고 생각하면 됩니다. 만약 이 설계도에 단 하나의 작은 실수라도 있다면, 공장 전체가 멈추거나, 불이 나거나, 아예 작동하지 않을 수도 있습니다.
오랫동안 이러한 설계도를 작성하는 것은 소수의 전문가들만이 이해할 수 있는 비밀스럽고 엄격한 언어를 사용하는 것과 같았습니다. 하지만 이제, 당신의 휴대폰 앱이나 웹사이트와 같은 소프트웨어 코드를 쓰는 데 매우 능숙한 **인공지능(AI)**이 등장했습니다. 사람들은 궁금해하기 시작했습니다. "AI가 소프트웨어 코드를 그렇게 잘 쓴다면, 이 까다로운 하드웨어 설계도도 쓸 수 있지 않을까?" 이것이 연구자들이 다룬 핵심 질문입니다. 그들은 똑똑한 AI가 간단한 하드웨어 작업 설명을 보고 이를 작동하는 공장 설계도로 바꿀 수 있는지, 아니면 엄격한 규칙 때문에 혼란에 빠질지를 확인하고 싶었습니다.
실험: 대화하기 vs 코딩하기
연구진은 다양한 AI 모델들이 이 작업을 얼마나 잘 수행하는지 확인하기 위해 거대한 테스트를 설정했습니다. 그들은 AI에게 두 가지 매우 다른 방식으로 설계도를 요청했습니다.
- "수다스러운" 접근 방식 (자연어): 그들은 단순히 영어로 하드웨어가 무엇을 해야 하는지 설명했습니다. 예를 들어, "두 숫자를 곱하는 기계를 만들어줘"라고 말하는 식입니다. 이것은 마치 친구에게 레시피를 주지 않고 그냥 "야, 샌드위치 하나 만들어줘"라고 부탁하는 것과 같습니다.
- "프로그래머" 접근 방식 (HLS-C 프롬프팅): 일반적인 영어 대신, 그들은 로직을 설명하는 C 코드(흔히 쓰이는 프로그래밍 언어)를 제공했습니다. 이것은 AI가 이미 잘 알고 있는 언어로 된 상세한 레시피를 건네주며, 그 레시피를 특정 "공장 언어"(Verilog)로 번역해 달라고 요청하는 것과 같습니다.
그들은 이 테스트를 7개의 서로 다른 AI 모델(GPT-4나 Gemini 같은 유명한 모델 포함)에 적용하여, 단순한 신호등 컨트롤러부터 복잡한 수학 계산기까지 8가지 유형의 디지털 회로를 구축하도록 했습니다. AI가 우연히 맞춘 것인지 아니면 정말로 과업을 이해한 것인지 확인하기 위해 각 테스트를 30번씩 반복했습니다.
결과: 레시피의 승리
결과는 꽤 명확했으며, 어쩌면 놀라울 수도 있습니다. AI와 일반 영어로 "수다"를 떨었을 때, AI는 고전했습니다. 생성된 설계도가 실제로 작동하는 비율은 평균적으로 약 **26.9%**에 불고했습니다. 대부분의 경우, AI는 잘못된 벽돌로 집을 지으려는 것처럼 실수를 저질렀습니다. 즉, 코드가 컴파일(실행 시작)조차 되지 않거나, 실행은 되더라도 잘못된 결과를 내놓았습니다.
하지만 연구진이 **C 코드 레시피(HLS-C 프롬프팅)**로 전환하자, AI의 성능이 급격히 올라갔습니다. 성공률이 **39.5%**로 치솟았습니다! 이는 큰 개선입니다! 이는 AI가 비록 똑똑하긴 하지만, 하드웨어 엔지니어보다는 프로그래머처럼 생각한다는 것을 시사합니다. 구조화된 코드 레시피를 주면, AI는 그 단계들을 하드웨어 언어로 어떻게 번역해야 할지 정확히 알게 됩니다. 마치 AI가 이렇게 말하는 것과 같습니다. "아, 프랑스어로 된 레시피를 주셨군요? 그럼 스페인어로 완벽하게 번역할 수 있어요. 하지만 그냥 영어로 '샌드위치 만들어줘'라고만 하면, 어떤 재료를 써야 할지 짐작만 해야 해요."
"이상한 숫자" 테스트: 암기인가 이해인가?
AI가 이전에 봤던 답을 단순히 복사하는 것인지(암기), 아니면 실제로 이 기계들을 만드는 법을 이해하고 있는 것인지 확인하기 위해 연구진은 속임수를 썼습니다. 그들은 AI에게 곱셈기(수학 기계)를 만들되, 현실에서는 거의 쓰이지 않는 7비트나 31비트 같은 아주 생소하고 특이한 비트 수를 사용하도록 요청했습니다. 이런 숫자들은 학습 데이터에서 흔히 볼 수 없는 것들이라 AI가 답을 외워서 낼 수 없습니다.
여기서 나온 결과는 매우 흥식했습니다. 일부 더 똑똑한 AI 모델들(예: o4-mini 및 Gemini 2.5 Pro)은 이 이상한 숫자들을 거의 완벽하게 처리하며 90% 이상의 성공률을 보였습니다. 이는 이 모델들이 단순히 복사해서 붙여넣는 것이 아니라, 기계를 만드는 로직을 실제로 이해하고 있음을 시사합니다. 즉, 이들은 한 번도 본 적 없는 새로운 상황에서도 규칙을 적용할 수 있는 '일반화' 능력을 갖추고 있습니다.
한계: 아직 완벽하지 않다
그럼에도 불구하고, 논문은 우리가 아직 완성 단계에 도달하지 못했음을 분명히 하고 있습니다. "레시피" 접근 방식을 사용하더라도 AI는 여전히 성공보다 실패를 더 많이 합니다. 가장 큰 문제는 AI가 문법(철자 오류 등)을 틀리는 것이 아니라, **타이밍(timing)**을 틀린다는 점입니다.
AI가 컨베이어 벨트가 1초 너무 빠르게 움직이는 공장을 만든다고 상상해 보세요. 설계도는 완벽해 보이고 기계도 켜지지만, 제품이 포장되기도 전에 라인 밖으로 떨어져 버립니다. 연구에서 이러한 "시뮬레이션 오류"가 가장 흔한 실패 원인이었습니다. AI는 코드가 겉보기에는 멀쩡해 보이지만, 실제 클록(clock)이 돌아갈 때 미세하게 다르게 동작하는 코드를 만드는 경우가 많았습니다. 이러한 오류를 수정하는 것은 어렵습니다. 왜냐하면 하드웨어가 시간에 따라 어떻게 작동하는지에 대한 깊은 이해가 필요한데, AI는 아직 이 부분에서 어려움을 겪고 있기 때문입니다.
또한 연구진은 AI가 성공했을 때, 그 결과물인 하드웨어가 인간 전문가가 작성한 설계도만큼이나 빠르거나 심지어 더 빠르다는 것을 발견했습니다. 이는 엄청난 성과입니다. 만약 우리가 AI가 이러한 미세한 타이밍 실수를 하지 않도록 만들 수 있다면, AI는 엔지니어를 위한 강력한 조수가 될 수 있음을 시사합니다.
결론
그렇다면 핵심 요점은 무엇일까요? AI는 컴퓨터 칩 설계를 돕는 데 점점 능숙해지고 있지만, 아직 완전히 직업을 대체할 수준은 아닙니다. 그것은 마치 명확하고 구조화된 계획(C 코드 레시피 같은)을 준다면 훌륭한 초안을 작성할 수 있는 유능한 인턴과 같습니다. 하지만 최종 세부 사항을 검토하고 공장이 멈추지 않도록 감독할 인간 관리자가 여전히 필요합니다.
이 연구는 이러한 AI 모델들과 대화할 때는 그냥 평범한 영어로 채팅하는 것보다 코드 기반의 프롬프트를 사용하는 것이 훨씬 더 나은 방법임을 시사합니다. AI가 여전히 인간의 디버깅을 필요로 하는 실수를 저지르기는 하지만, 이미 설계 프로세스의 속도를 높이고 하드웨어 엔지니어링 입문자들을 돕는 강력한 도구로서의 가치를 증명하고 있습니다. 우리는 AI가 도움 없이 처음부터 칩을 스스로 만들 수 있는 단계는 아니지만, 확실히 올바른 방향으로 나아가고 있습니다.
연구 분야의 논문에 파묻히고 계신가요?
연구 키워드에 맞는 최신 논문의 일일 다이제스트를 받아보세요 — 기술 요약 포함, 당신의 언어로.