FPGA Verilog 디버깅 - Claude 답변을 Waveform으로 검증한 과정

Claude의 RTL 디버깅 활용

1학기 디지털시스템설계 수업 중 진행한 term project에서 SRCNN 8×4 Streamline 가속기 과제를 담당하였습니다.

그 과정에서 Claude에게 RTL 질문을 꽤 많이 하게 되었습니다.

 

Line Buffer를 BRAM으로 바꿔야 하는지, valid는 왜 어긋나는지, PU2를 둘로 나누는 편이 나은지 같은 문제들이었습니다.

답변은 빠르게 나왔습니다. 그런데 실제 Vivado 설정을 보지 못한 상태에서 latency를 단정하거나, target FPGA와 맞지 않는 자원 추정을 내놓는 경우도 있었죠.

 

그래서 답변을 바로 코드에 반영하지는 않았습니다. 확인할 후보를 먼저 뽑고, waveform과 Vivado report에서 하나씩 지워가는 식으로 사용했습니다.

 

SRCNN 8×4 Streamline 구조

8×4 구조는 PU1(1→8), PU2(8→4), PU3(4→1)를 파이프라인으로 연결합니다.

 

앞 PU의 output valid가 다음 PU의 입력 조건이 되기 때문에, 앞단에서 timing이 조금만 틀어져도 뒤 레이어까지 그대로 이어집니다. Controller부터 전체 코드를 다시 보는 것보다, data와 valid가 어디까지 맞는지 먼저 확인하는 편이 훨씬 빨랐습니다.

 

Claude 활용 사례

1. Line Buffer의 BRAM 전환 검토

처음 받은 제안 중 하나는 Line Buffer를 BRAM으로 옮기는 것이었습니다.

8×4 구조에는 Line Buffer가 여러 개 들어가니 LUTRAM 사용량이 커질 수 있다는 얘기였습니다. 충분히 그럴듯했습니다.

 

그런데 Synthesis 결과를 확인해 보니 현재 구조도 목표 보드의 자원 안에 들어왔습니다. BRAM으로 바꾸면 포트 수와 동시 접근 방식까지 다시 손봐야 했고요.

 

정말 구조를 바꿀 만큼 이득이 있는 상황은 아니었습니다. 그래서 Line Buffer는 그대로 두고, Claude의 자원 계산은 초기 추정치로만 참고했습니다.

 

2. PU1 output valid의 3클럭 오차

가장 오래 붙잡고 있었던 건 valid timing 문제였습니다.

 

PU1만 따로 시뮬레이션했을 때 o_output_valid가 실제 o_dout보다 3클럭 앞서 있었습니다. 처음에는 Controller가 잘못됐는지, Line Buffer 문제인지, post-process에서 delay가 빠진 건지 구분하기 어려웠습니다. Multiplier IP의 latency도 후보에 들어갔고요.

 

Claude가 가능한 원인을 정리해 주기는 했지만, 목록만 봐서는 어느 쪽이 진짜 원인인지 알 수 없습니다. 그래서 신호를 다음 순서로 내려가며 확인했습니다.

1. PU1 output data와 valid
2. Line Buffer window와 window valid
3. PE multiplier 입력·출력과 valid pipeline
4. Vivado Multiplier IP의 pipeline 설정

여기까지 확인하고 나서야 Multiplier IP의 실제 데이터 지연과 RTL이 가정한 valid 지연이 다르다는 것을 찾았습니다.

 

IP 설정과 valid pipeline을 맞춘 뒤 PU1 단독 테스트를 다시 돌렸고, 마지막으로 전체 SRCNN에서도 결과가 맞는지 확인했습니다.

 

3. 분할 PU2와 단일 PU2 비교

PU2는 버그를 찾는 문제라기보다 구조를 고르는 문제였습니다.

 

개발 중간에는 placement와 routing을 분산해 보려고 PU2를 두 개의 8→2 모듈로 나눴습니다. 반대로 하나의 8→4 PU2로 합치면 Line Buffer를 공유할 수 있었습니다.

 

코드만 보면 둘 다 나름의 이유가 있습니다. 어느 쪽이 낫다고 말로 정하기 어려워서 두 버전을 직접 구현하고 같은 종류의 Vivado report를 비교했습니다.

 

아래 이미지는 그때 작업 기록에 남긴 checkpoint입니다. 최종 보고서와 측정 시점이 다르기 때문에, 최종 성능 수치라기보다는 당시 구조를 고른 근거로 보는 편이 맞습니다.

 

Resource utilization

기존 분할 PU2	단일 PU2

 

Timing

기존 분할 PU2	단일 PU2

 

항목	분할 PU2	단일 PU2
LUT	20%	18%
LUTRAM	9%	7%
FF	9%	8%
WNS	2.471 ns	2.770 ns

 

이 checkpoint에서는 단일 PU2 쪽의 LUT·LUTRAM·FF 사용량이 줄었고 WNS도 2.471 ns에서 2.770 ns로 늘었습니다. 구조도 더 단순해 최종안은 단일 PU2로 정했습니다.

 

RTL 디버깅 및 검증 순서

이런 과정을 몇 번 반복하니 Claude에게 무엇부터 물어봐야 하는지도 조금씩 정리됐습니다.

1. 증상을 숫자로 작성: 어느 모듈인지, 몇 cycle 차이인지, 기대값과 실제값이 무엇인지 먼저 적었습니다.
2. 답변을 수정안이 아닌 가설로 설정: waveform, IP 설정, report 중 어디에서 확인할 수 있는지도 함께 정했습니다.
3. 정상인 구간부터 따라가기: Input → Line Buffer → PE → post-process → PU output 순서로 보면 오류가 처음 생기는 지점을 찾기 쉽습니다.
4. 한 번에 한 군데만 변경: 단독 시뮬레이션이 통과한 뒤 통합 테스트, reference 비교, Implementation으로 범위를 넓혔습니다.

Controller와 Line Buffer, PE를 한꺼번에 건드리면 무엇 때문에 결과가 바뀌었는지 알기 어렵습니다. 질문할 때도 이 세 종류의 문제를 섞지 않는 편이 나았습니다.

 

Claude 활용 범위

Claude가 도운 일	직접 확인한 일
원인 후보 정리	waveform 관찰과 오류 경계 확정
볼 신호의 순서 제안	Vivado IP 설정 확인
BRAM 전환·PU2 분할 같은 대안 제시	RTL 수정, 단독·통합 시뮬레이션
검증 항목과 글의 구조 정리	Synthesis·Implementation 및 최종 구조 선택

 

표로 놓고 보면 Claude에게 맡긴 범위는 생각보다 좁습니다.

 

그래도 처음부터 모든 RTL을 뒤지는 대신, 다음에 볼 신호를 정하는 데는 도움이 됐습니다. 반대로 target FPGA의 자원이나 IP latency처럼 설정에 따라 달라지는 값은 Claude의 설명만으로 결정하지 않았습니다.

 

정리

이후에는 Claude에게 “어디를 고치면 될까?”라고 바로 묻기보다, “3클럭 차이가 생길 수 있는 지점은 어디이고 어떤 신호를 보면 구분할 수 있을까?”라고 묻게 됐습니다.

 

대화에서 얻고 싶었던 것은 완성된 수정 코드가 아니라 다음 측정 지점이었습니다. 실제 수정과 구조 선택은 waveform, Synthesis, Implementation 결과를 확인한 뒤에 진행했습니다.