RTL · 참조 모델 · 검증
허용된 latency 차이와 기능 오류는 어디서 갈리는가. 입력이 받아들여진 순간부터 출력이 대응되는 순간까지, 비교기가 보존해야 할 의미를 따라가 본다.
참조 RTL과 매 사이클 출력을 대조하면, 스펙이 허용한 다른 latency도 실패로 처리할 수 있다. BEHAVE는 이 문제를 기능 참조 모델로 푼다.
트랜잭션으로 기대값을 계산하는 방식 자체는 익숙하다. UVM의 scoreboard도 입력 트랜잭션을 참조 모델에 넣고, 예측한 출력과 실제 출력을 비교한다. 모니터는 인터페이스 신호를 트랜잭션으로 복원한다.
BEHAVE-Sim은 실제 수락된 입력과 순서, 리셋 같은 이벤트를 과제별 규칙으로 해석해 골든 Behavior 모델에 전달한다. 설정 적용 시점도 과제가 정한다. 모델이 만든 기대 출력과 RTL 출력을 대응시키되, 프로토콜·시간 제약은 별도 모니터로 검사한다. Behavior IR은 이 기능을 실행 가능한 형태로 표현한다. 원문 3.1절·부록 B.5
에이전트가 만든 RTL과 Behavior 모델은 숨겨진 골든 모델로 각각 평가한다. 이 점수를 학습 보상에도 쓰므로, 참조 RTL 없이 스펙과 골든 Behavior 쌍으로 학습할 수 있다. 3.4절
10이 늦게 나오는 것과
15가 나오는 것은 다르다
다음은 이 글을 위해 만든 덧셈 블록이다. 입력 x와 설정값 k는 부호 없는 8비트 값이고, 출력은 y=x+k다. 예제의 스펙은 입력 handshake 때의 k를 사용하도록 정했다. 입력 하나에 결과 하나를 순서대로 내고, 결과는 입력 수락 후 다섯 사이클 이내에 전달해야 한다.
드라이버가 x=7을 제시해도 ready=0이면 아직 입력을 받은 것이 아니다. 이 예제에서는 상승 에지에서 valid=1과 ready=1이 함께 관측될 때 입력이 수락된다. 그때의 k=3이 이번 연산에 속한다. 이후 외부 설정이 8로 바뀌어도, 이 연산의 기대값은 10이다.
같은 입력을 받은 세 가지 실행
단일 클록 · 입력은 한 번만 수락 · 연산 중 리셋 없음
입력 handshake 때 설정 적용 · 출력 ready는 항상 1
입력 제시x=7, k=3valid=1, ready=0
아직 연산을 시작하지 않음
입력 수락x=7과 k=3을 연결valid=1, ready=1
이번 연산의 설정을 저장
설정 변경외부 k가 8로 바뀜이미 수락한 연산에는
k=3이 계속 적용됨
B도 시간 조건에서 실패한다. 기대값이 10이라는 사실과 정해진 시간 안에 도착했다는 사실은 별도로 확인해야 한다.
A의 C3 출력만을 정답으로 고정하면 B는 틀린 설계처럼 보인다. 하지만 예제의 스펙은 B에게도 완료할 시간을 줬다. 반면 C의 15는 늦어서 틀린 것이 아니다. 다른 설정값을 가져와 다른 계산을 했기 때문에 틀렸다. 계산이 같다는 것과 계산 스케줄이 같다는 것을 이 지점에서 구분할 수 있다.
기대 출력 10은 C3이나 C6이라는 한 시점에 묶어 둘 필요가 없다. 실제 결과가 나왔을 때 그 값과 대응시키면 된다. 다만 결과가 빠졌거나 두 번 나왔다면 ‘10이 한 번 보였다’는 이유로 통과시켜서는 안 된다. 이 예제는 입력 하나에 출력 하나라는 조건까지 갖고 있기 때문이다.
값 비교와 시간 검사를 나누는 것도 검증 실무의 기본 구조다. UVM 가이드 4.8절은 데이터 검사와 시간 동작을 확인하는 assertion을 구분한다. 위 예제의 응답 한계 역시 값 비교를 느슨하게 했다고 사라지지 않는다.
설정을 읽는 순간도 기능이다
논문의 CVDP 위상 회전 사례에서는 기본 입력 8,200개를 통과한 RTL도 추가 탐색에서 실패했다. 연산 시작 때 저장해야 할 i_wait를 계산 뒤 읽었고, 재실행에서 o_subsampling이 기대값 0 대신 1이었다. 부록 D.3
덧셈 예제에서도 k를 3으로 계속 유지하면 A·B·C가 모두 10을 낼 수 있다. 입력 데이터만 바꾸는 테스트로는 설정을 언제 읽었는지 구별하기 어렵다. C1에서 일을 받은 뒤 C2에서 설정을 바꿨기 때문에, 저장한 설정을 쓰는 구현과 나중의 설정을 읽는 구현이 10과 15로 갈라진다.
더 까다로운 경우는 참조 모델도 현재 보이는 k=8을 가져올 때다. RTL과 모델이 함께 15를 내면 서로는 일치한다. 그 비교에는 ‘둘 다 이번 연산에 속하지 않는 설정을 썼다’는 사실을 알려 줄 기준이 없다. 독립적으로 정한 기대값 10과 비교해야 두 구현의 공통 오류가 드러난다.
이 구분은 디버깅에도 남겨야 한다. 스펙이 시작 시 샘플링을 요구한다는 것을 잘못 이해했다면 스펙 해석 오류이고, 그 요구를 이해하고도 RTL을 다르게 구현했다면 RTL 구현 오류다. 출력 불일치 하나만으로 둘 중 원인을 단정할 수는 없다.
BEHAVE에서 주목할 변화는 정답의 스케줄을 하나로 정하는 대신, 허용된 구현들이 지켜야 할 동작의 의미를 판정 기준으로 삼았다는 점이다.
덧셈 블록의 파이프라인이 두 사이클에서 다섯 사이클로 바뀌어도 7과 3이 이번 연산의 피연산자라는 사실은 바뀌지 않는다. 구현에 줄 수 있는 자유와 참조 모델이 지켜야 할 의미가 정확히 그 경계에서 갈린다.
논문의 테스트 판정은 검사한 입력에 대한 결과다. 별도의 bounded 분석도 고정된 범위의 목표를 다루며, Behavior–RTL 형식적 동등성이나 전체 SoC 검증을 입증하지 않는다. 부록 C.11
자료 범위: 한국시간 2026년 10월 2일 오후 10:02까지 공개된 자료(13:02 UTC). 원문은 의미 확인을 위해 이후 다시 검토했다.
덧셈 블록은 논문의 회로나 반례를 재현한 것이 아니다. 기능 참조 모델의 판정 기준을 설명하기 위한 독립 예제이며, 특정 설계 환경과의 호환성이나 성능을 측정하지 않았다.
답글 남기기