[UVM] 5.6.1 read/write(UVM_BACKDOOR) vs. peek/poke() — 차이와 올바른 사용법

방법 호출 예 백도어 동작 레지스터 동작 규칙(CLR-on-RD, RO, W1C 등) 미러 갱신 주용도

read / writepath = UVM_BACKDOOR	sv<br>R_CTRL.read(status, data, .path(UVM_BACKDOOR));<br>R_CTRL.write(status, data, .path(UVM_BACKDOOR));	내부 신호에 직접 접근하지만 프런트도어와 동일한 기능적 효과를 흉내 냄	● O (모사)· read CLR-on-RD 비트 → 0 poke· write RO/W1C 비트 → 값 유지 등	O (predict/샘플)	빠른 시뮬 + 기능 보존(가장 많이 사용)
peek / poke	sv<br>R_CTRL.peek(status, data);<br>R_CTRL.poke(status, 32'hDEAD_BEEF);	값 그대로 샘플·디폿	● X (무시)CLR-on-RD도 변경되지 않음RO·W1C도 덮어써짐	O (raw 값으로 업데이트)	디버그, 초기 메모리 로딩, 강제 패치

핵심 차이

1. 기능적 모사 여부
   • read/write + UVM_BACKDOOR → 프런트도어와 같은 부작용을 흉내
   • peek/poke → 단순 bit-bang, 모든 보호 규칙 무시
2. 결과 차이 예시상황 read/backdoor peek

   CLR-on-RD 비트	값 읽힌 뒤 0으로 자동 클리어	0으로 클리어되지 않음
   RO 비트에 write	기존 값 유지	원하는 값으로 강제 덮어씀

3. 미러(prediction) 연동
   두 방법 모두 내부적으로 미러 값을 갱신하지만, peek/poke 는 “raw” 값을 반영하므로 HW 실제 동작과 다를 수 있음.

---

실무 사용 가이드

목적 권장 API

기능 검증을 그대로 유지하면서 속도 향상	read/write(..., UVM_BACKDOOR)
초기 설정 수천 개 레지스터 0-time 구성	reg_blk.update(UVM_BACKDOOR) 또는 set()+update(BACKDOOR)
RAM/FIFO 대량 로딩·추출	mem.poke() / mem.peek() (스크립트 기반)
특정 버그 원인 파악·값 강제 수정	poke() 후 파형 관찰
CLR-on-RD 동작 자체를 테스트	반드시 프런트도어 read → backdoor peek 으로 결과 확인

---

 

 

 

본 내용은
accellera에서 공개한
Universal Verification Methodology
(UVM) 1.2 User's Guide
를 바탕으로 작성된 글입니다.