모든 이야기

passive monitor: 세 번 valid였는데 전송은 두 번인 이유

전송 로그에 A, A, B가 남았다. 입력 valid는 세 사이클 동안 켜져 있었지만 첫 사이클에는 ready가 꺼져 있었다. 실제로 받아들인 항목은 A와 B 두 개다. 테스트벤치가 자극을 내보낸 기록을 곧바로 전송 기록으로 사용하면, 이렇게 기다리는 시간을 데이터의 개수로 오인할 수 있다.

passive monitor는 회로를 움직이지 않고 인터페이스에서 실제로 일어난 일을 기록한다. 자극을 만들 때의 의도와 회로가 받아들인 결과를 분리하는 관측 지점이다.

driver는 제안하고 monitor는 관찰한다

UVM User’s Guide는 driver가 transaction을 신호로 변환해 DUT에 전달하는 능동 구성요소이고, monitor는 인터페이스를 관찰하는 수동 구성요소라고 설명한다. monitor가 모은 transaction은 검사와 coverage에 쓰일 수 있다. 특히 관측은 driver 내부 정보에 의존하지 않도록 권한다. Accellera UVM User’s Guide 1.1, §1.2.4 Monitors

driver에는 ‘A를 보내겠다’는 정보가 있다. 그러나 요청을 언제 수락했는지, 기다리는 동안 payload가 잘 유지되었는지, 신호가 실제로 어떤 값이었는지는 별개다. driver가 완료를 잘 판단하더라도 그 판단 로직 자체가 검증 대상에서 완전히 독립적이지 않을 수 있다.

가상의 동기식 인터페이스에서 reset이 해제된 클록 상승 edge마다 valid와 ready가 모두 1이면 한 항목이 전송된다고 하자. payload는 그 edge 전에 안정되어 있어야 한다. 다음 표는 각 edge에서 받아들임을 판정할 입력 값이다.

edgevalidreadypayload실제 전송
110A없음
211AA
311BB
401무관없음

valid가 켜진 횟수는 3이고, 전송 횟수는 2다. A는 두 번 제시되었지만 한 번만 수락되었다. monitor는 전송 조건이 성립한 edge에서만 payload의 복사본을 내보낸다. ready를 기다리는 시간을 별도 항목으로 세지 않는다.

잘못된 DUT와 잘못된 기준이 서로 맞을 수 있다

만약 DUT에 ‘valid만 켜져 있으면 저장한다’는 오류가 있다면 A, A, B를 저장할 수 있다. 참조 모델도 driver가 valid를 켠 사이클마다 A, A, B를 넣는 방식이라면 두 결과가 맞아 버린다. 비교는 수행했지만 기준 모델이 실제 전송 계약을 따르지 않은 것이다.

독립적인 입력 monitor가 A, B만 기록하면 차이가 드러난다. 결과를 돌려주는 인터페이스까지 관찰했을 때 출력이 A, A, B라면, 예상 두 항목과 실제 세 항목이 맞지 않는다. ‘비교 성공’이라는 표시보다 그 비교의 입력이 어디에서 왔는지가 먼저다.

PULP의 공개 AXI 테스트 코드에서도 관찰은 신호의 valid와 ready를 함께 확인한 뒤 이루어진다. axi_scoreboard의 mon_ar와 mon_r는 실제 채널 값을 복사하고, 주소와 응답 정보를 큐에 넣는다. 여기서는 관측 조건과 payload 복사라는 구조를 읽는 것이 목적이며, 코드의 샘플링 지연 설정을 모든 인터페이스에 그대로 적용한다는 뜻은 아니다. PULP AXI, axi_test.sv

관측한 transaction 객체를 이후에 수정하는 문제도 주의해야 한다. driver가 재사용하는 같은 객체의 참조만 보관하면, A의 기록이 다음 B의 내용으로 덮여 보일 수 있다. 기록에는 그 순간의 값이 남아야 하므로 신호에서 새 객체를 구성하거나 필요한 데이터를 복사해 소유권을 분명히 한다.

수동이라는 말은 검사를 하지 않는다는 뜻이 아니다

passive monitor는 신호를 구동하지 않는다. 그렇다고 단순한 로그 출력기일 필요는 없다. 전송을 재구성하고, stall 동안 payload가 유지되는지 같은 인터페이스 규칙을 확인할 수 있다. 재구성한 항목을 여러 소비자에게 전달하면 기능 검사와 통계도 같은 관측 사실을 기반으로 한다.

이 분리가 있으면 환경을 재사용하기도 쉽다. 모듈 단위 검증에서는 agent 안의 driver가 자극을 보내지만, 시스템에서는 다른 실제 블록이 그 역할을 한다. monitor가 driver의 개인 로그를 읽지 않는다면, 능동 구동을 제거한 passive agent에서도 인터페이스를 관찰할 수 있다. UVM 가이드가 설명하는 passive agent는 이런 사용을 지원한다. Accellera UVM User’s Guide 1.1, §1.2.5 Agents

관측 시점은 여전히 정확해야 한다. edge 이후 DUT가 valid를 내리거나 ready를 바꾸는데 최종 값만 보고 방금 전송을 판정하면 누락이 생길 수 있다. clocking block이나 시뮬레이터의 적절한 샘플링 단계로 계약이 요구하는 edge의 입력 값을 잡아야 한다. monitor를 분리했다는 구조만으로 시간 해석까지 자동으로 맞아지지는 않는다.

또한 monitor가 수집한 사실과 명세의 정답은 서로 다른 층이다. monitor가 DUT의 잘못된 출력도 충실하게 기록하는 것은 정상이다. 그 결과가 옳은지 판단하려면 기능 모델이나 별도의 규칙 검사가 필요하다. 관찰기와 참조 모델이 똑같은 잘못된 프로토콜 가정을 공유하면 독립성이 다시 약해진다.

세 번 제시한 데이터와 두 번 수락한 데이터 사이의 차이를 지키는 것이 passive monitor의 역할이다. 테스트벤치는 ‘보냈다고 생각한 것’만으로 회로를 평가하지 않는다. 실제 인터페이스에서 성립한 전송을 기록하고 그 기록을 기준으로 결과를 비교해야, 기다림과 중복 저장을 서로 구별할 수 있다.