Scoreboard는 테스트의 정답을 정의(ref_model)하고, DUT의 실제 출력과 비교(Checker)함으로써 DUT의 출력이 "정답"인지 확인하는 검증 블록이다.(Ex. AXI에서 Write/Read 트랜잭션 수행 시 Monitor가 추출한 실제 데이터와 예측값이 일치하는지 확인한다. 불일치 시 로그를 출력하고 테스트 FAIL로 판정하여 설계 오류를 빠르게 식별할 수 있게 한다)Scoreboard 구현1. Scoreboard 클래스 정의 및 Factory 등록class my_scoreboard extends uvm_scoreboard; // Factory 등록 (재사용 가능하게 하기 위해 권장) `uvm_component_utils(my_scoreboard) // 생성자 function..

Monitor는 DUT의 응답이 올바른지, 프로토콜을 정확히 준수하는지를 관찰하여 의미 있는 트랜잭션 정보를 추출하는 역할을 한다.단순 신호 기록이 아닌, 인터페이스의 의미 있는 동작 단위를 정의하고 분석하는 것이 핵심이다. (Ex. AXI 버스 Monitor의 경우, 단순히 모든 신호를 기록하는 것이 아니라 완전한 트랜잭션(주소 페이즈 + 데이터 페이즈)을 식별하고 의미 있는 정보(읽기/쓰기 타입, 버스트 길이, 응답 코드 등)를 추출해야함.)Monitor 구현1. uvm_monitor 상속 및 클래스 정의class my_monitor extends uvm_monitor; `uvm_component_utils(my_monitor) function new(string name = "my_monitor..

Driver는 Sequencer에서 받은 트랜잭션을 실제 DUT 신호로 변환하는 역할을 한다. Driver는 사양에 따른 정확한 타이밍 및 신호 시퀀스, 즉 정확한 프로토콜을 구현해야 하며, 이는 테스트 신뢰성의 핵심 요소이다. Sequencer -> Driver -> Interface -> DUT 흐름에서 트랜잭션 데이터를 받아 실제 신호로 변환하여 DUT에 전달한다.(Ex. APB라면 addr/data/enable/write/read 등의 핀 타이밍 제어)Driver 구현1. uvm_driver 상속받아 사용자 정의 드라이버 Class를 생성한다class my_driver extends uvm_driver #(my_data); // 트랜잭션 타입 명시 `uvm_component_utils(my_d..

Sequencer는 테스트 시나리오가 흘러가는 출발점이다. Sequence -> Sequencer 흐름을 따라가며, Sequencer가 어떤 역할을 하고, 어떻게 동작하는지 알아보자.Sequence에서 트랜잭션을 생성 Sequencer가 트랜잭션을 받아 Driver로 전달1. Sequence란 무엇인가?시퀀스(Sequence)는 DUT(Device Under Test)에 가하는 자극(stimulus)의 패턴을 정의한 클래스 기반 객체를 뜻한다.즉, “어떤 데이터를 언제, 어떻게, 몇 번 보낼 것인가?”를 정의하고 생성하는 설계도이자 시나리오이다.initial begin clk = 0; rst = 1; #10; rst = 0; addr = 8'h05; data = 8'hAA; write_en = ..

지난 게시글에서 Agent에 대해 간단히 언급하였는데, 이에 대해 자세히 알아보자. Agent는 UVM 환경에서 가장 기본적인 검증 블록을 뜻한다. 하나의 DUT 인터페이스를 다루기 위해 필요한 컴포넌트들은 너무 많다(driver, monitor, sequencer). 이걸 묶어 하나의 단위로 다루면 재사용성, 확장성, 유지보수성이 올라가게 되는데, 이를 묶어서 하나로 묶은 통합 컨트롤 유닛을 UVM Agent라고 한다.구분🟢 Active Agent🔵 Passive Agent생성 컴포넌트Sequencer, Driver, Monitor 모두 생성Monitor만 생성DUT와의 인터페이스데이터를 전송할 수 있음DUT의 동작을 관찰만 함사용 목적DUT에 입력 신호를 생성/제어DUT의 출력 검증, 커버리지 측..