들어가며#
지난 몇 달간 사실 RTL 코딩 보다는 알고리즘 스터디와 RefC modeling을 위주로 작업을 진행하고 있어서, RTL을 많이 만지지는 못했습니다
최근에 테스트용(테스트용이지만, logic만 30~50만 게이트, 메모리 포함 100만 게이트 정도 되는 것들)으로 몇개 작업해보면서 느낀 점을 적어보려 합니다.
Coding Agent가 RTL을 잘 만드나?#
미묘한데.. skill 없는 상태에서 작업해보면 그럴듯한데 버그가 너무 많습니다. 심지어 작은 모듈에도 버그를 미묘하게 넣는 경우가 있습니다.
문제는 이게 일관성이 있는 건 아니라서, 어떨때는 잘되고, 어떨때는 잘 안된다는 겁니다.
구조로 봤을때는 어떤 부분에는 잘 고안하는데, 어떤 경우에는 어처구니 없는 실수들이 있었습니다.
(과거형으로 쓰는 건, 제가 최근에는 소위 이야기하는 skill 없이 coding agent를 사용한 적은 없어서요. skill 상에서 잡혀나가는 에러를 보면 그렇구나.. 이해하는 부분을 적었습니다. )
느낌상으로는 학습된 패턴은 잘 나오고, 학습되지 않은 형태는 잘 안나오는게 아닌가.. 하는 생각도 듭니다. 물론, 특정 부분은 의외로 기가막히게 잘짜는 부분도 있고요.
여기에 Skill을 사용하고, template을 같이 적용하면 어느 정도까지는 일관성 있는 설계를 만들 수 있습니다.
그럼에도 특정 형식은 일관성이 있지만, 블럭이 커지면 인터페이스등에서 지속적으로 오류가 자주 발생합니다.
이때, RAT에서 한 것처럼 interface 수준과 통합 단계에서 반복해서 리뷰를 하도록 만들면, 인터페이스 단계에서 미묘하게 달라지는 문제나, 중간에 뭘 빼 먹는 것이 iteration이 돌면서 수정됩니다.
즉, 코딩 에이전트는 실수를 반복할 것이라 가정하고, 어떤 형태가 되었든 실수를 확인하고 교정할 부분이 반드시 필요하다고 생각합니다.
Verilator가 되었든, LSP가 되었든, Coding agent의 판단이 아닌 명시적/정량적으로 기본적인 에러를 찾아줄 수 있는 것이 필요한 거죠.
svlens라는 툴을 하나 만든 것이 사실 인터페이스, connectivity, 그리고, latch infer 같은 사소한 문제를 의외로 coding agent에서 못잡아서 추가한 것입니다.
의외로 verilator에서 안잡히는 것도 있고요. (당연히 verilator는 simulator니까 합성에서 발생하는 문제를 알려주지는 않을 것이죠.)
Iteration을 짧게 가져 갈 수 있도록 만드는게, Coding agent의 효율을 높이는데 매우 중요했기 때문이기도 합니다.
(캐시가 살아있는 동안에, 틀린 부분을 잡아주면 금방 금방 고칠 수 있는데, 실제 시뮬레이션이나 시간이 오래 걸리는 부분에서 잡게되면 토큰 사용량이 급격히 증가하더군요. )
어떻게 하는게 효율적인가.#
여러분 작업에 맞는 적당한 skill을 하나 만드시는 건 필요합니다.
제가 만든 RAT와 같은 것을 사용하는 것도 좋겠습니다만, 요건 일반적인 경우와 제가 사용하는 경우를 위주로 적은 거라, domain expert(여러분이 작업하시는 분야의 지식을 전달하고, 점검하는)로 코덱과 AXI 같은 것이 들어있는데, 여러분의 작업에 맞는 expert를 맞춰 넣는게 중요한 것 같습니다.
만드는 건 간단합니다. 작업을 하시다가.. “지금까지 내가 작업한 내용을 기반으로 계속 작업 flow와 단계를 진행할 때 사용할 만한 gating을 추가할 수 있는 skill을 하나 만들어줘"라고 해도 됩니다. (물론, 이것보다 더 자세히 적어주시는게 좋습니다. )
며칠간 작업한 내용이 아마도 어떤 작업을 하고, 어떻게 고치고, 에러 메시지를 coding agent에 넣어서 계속 디버깅 하셨을테니까요. 이 과정이 잘 기록되어 있을수록 좋은 skill이 만들어집니다.
그 다음에는 /goal 명령으로 “어떤 것을 만들고 싶다” 고 적으면, 지금까지 작업한 정보를 기반으로 만든 skill이 동작하면서, 그 동안 여러분이 하셨던 작업을 반복하면서 원하는 것을 만들때까지 자율적으로 동작하게 만들 수 있습니다.
Coding Agent에서 더 튜닝해야 하는 것들#
요즘 몇달에 한번씩 프론티어 모델이 업데이트 되고 있어서, RAG나 LLM fine tuning하는 동안에 다음 모델이 나와버리고 있어서, RAG나 LLM fine tuning이 실질적으로 효과적인가 하는 생각이 있습니다.
오히려, 지금 현재 형태에 맞춰서 스킬로 데이터를 교정하고, 피드백을 줘서 결과를 다르게 유도 하는게 실질적으로 빠르고 효과적이라 생각합니다.
이게 훨씬 빠르게 버전 변경을 따라가는 방법이라 그렇습니다.
몇가지 예를 들자면..
요즘의 claude code는 RTL을 가지고 timing을 예측할 때 “너무 optimistic"하게 예측합니다.
물론 이게 정밀할 것이라 생각한 적은 없습니다만, 이전보다 더 주파수가 잘나올 것이라 예측하다보니, RTL의 logic depth가 생각보다 깊게 형성되는 경향성이 보입니다.
특히 opus 4.7, 4.8에서 조금 강해진 경향성이 보입니다.
그래서, 제가 가진 plugin을 가지고 RTL을 만들면 functionally는 동작하는데, frequency target에는 전혀 맞지 않는 경우가 많이 나옵니다.
몇개 측정해보면, critical path delay를 가지고 계산하면 50%~100% 정도 긴 path가 생성되는 경우가 많습니다. (즉, target path delay보다 크게는 2배까지 차이)
그런데, 우리가 실질적으로 합성할 때도 50% 마진을 주고(즉, 2배 주파수로 합성하고), loading도 잡고 하잖아요. 그걸 생각하면 오히려 정확해진것인지도 모르죠.
여하튼 우리는 결과를 기반으로 튜닝하는 것이니까, 위와 같이 잡는게 편합니다. (실제로는 조금 더 강력하게 조건을 주는게 좋습니다.)
이 부분은 합성을 agentic coding안에 synthesis가 들어가게 하면 되긴하는데, 합성 시간이 오래걸리는 경우가 많아서 실용적이지는 않은 것 같습니다.
(in-loop에 dc를 넣은 적이 있는데, 로직이 커지니까 정말 오래 걸리더군요. 특히 사람은 그렇지 않을텐데, agent는 loop을 많이 가지면서 RTL을 약간씩 교정하는 과정이 많거든요. )
그렇다고, open source tool들은 제가 보기에는 그리 좋은 결과는 아닌 것 같습니다. (합성 방법 자체가 그리 좋지는 않고, 속도 문제도 있고, 특히 주요 라이브러리를 사용하기 어렵다는 문제도 있죠.)
이런걸 생각하면, 그냥 “내가 이야기한 target 주파수의 2배 주파수를 목표 주파수로 잡아라"고 이야기하는 게 좋습니다. (microarchitecture 단계 전에서)
(요즘에 실험을 하면서 느낀 건데.. 최대한 스펙 단계에서 요걸 줘야지, 구현 단계에서 “예측된 path delay보다 2배 크게 예측되었다고 보라"고 skill을 잡으면 잘 안되더군요)
다른 부분은 역시 CDC입니다.
이것도 coding agent에게 “명령"을 내려도 잘 안되는 부분입니다.
svlens라는 도구로 clock domain crossing하는 부분들을 확인하고, CDC를 넣게 했는데, 의외로 빼먹는 경우가 많습니다. 템플릿과 들어가는 규칙을 주어도 자주 빼먹습니다.
그래서, 결과 부분에서 다시 리뷰를 진행하면 경우에 맞게 2-flop, async-fifo 를 넣게 됩니다.
이건 생각해보면, coding agent가 블럭 단위로 설계하면서, 점진적으로 상위로 올라갈때 context를 잃는게 아닌가 싶습니다. 그래서 상위로 가면서 svlens가 되었든, spyglass가 되었던 CDC를 빠르게 확인하도록 하는게 중요합니다. (어려운 룰은 배제하고, 일단 구조적 규칙들 위주로)
요건 요즘에 계속 보고, 추가하고 있습니다.
마지막으로..#
시간이 지나면서 coding agent가 RTL도 당연하게 더 잘할 거라고 봅니다. 더 정밀해지고요.
지금도 top-down 형식으로 스펙을 단위별로 나눠주고, 작은 단위 별로 설계/검증하면서 상위 단계로 통합하면서 확인하고 검증하는 과정을 거치는 것만으로도, 많이 좋아진다는 이야기는 드렸었죠.
이제는 규모를 늘려가면서 확인해야 할 부분을 정량화하고, 추정할 부분을 coding agent로 넘기는 부분에 대해서 점진적으로 조금씩 더 “어떤 것이 효과적인지” 알게 되고 있는 과정이라 생각합니다.
Coding agent들 간에 속성도 그때 그때 바뀌고 있는데, 어느 정도는 일관성도 있습니다. 적어도 cross review나, 해당 부분을 잘하는 agent(예를 들어, 구현 정밀성은 GPT-5.5 xhigh가 더 좋은 경우가 있습니다. 스펙만 명확하다면요)에게 작업을 할당하는 것도 매우 유효해 보입니다.
다만, 제가 요즘에 설계 단계로 봤을때 RTL에 집중하는 단계는 아닌지라, 많은 시간을 사용하지는 못하고 있다는 점이 약간 아쉽기는 합니다.
게다가 회사의 다른일에 집중하다보니, 토큰이 문제도 있어서 이 작업에 쓸 토큰이 별로 없다는 것도 문제고요.
그럼에도 최근에 새로운 버전이 나올때마다 이것 저것 해보면서(로컬 LLM을 포함해서) 확인하는 과정이 아직은 즐겁네요.
뭔가 좋은 뭔가가 나올 수도 있을 것 같습니다. (아.. 제가 아니더라도요..)
