UVM Tests (테스트 시나리오)

uvm_tests는 가장 최상단에 위치한 class로, 여기서부터 

다른것들을 호출한다고 보면된다. 

 

아래와 같이 basic_test 라는 것을 한번 보도록 하자, 

 

class basic_test extends uvm_test;
  `uvm_component_utils(basic_test)
  
  virtual interface apb_if apb_vif;
  
  function new (string name, uvm_component parent);
    super.new(name, parent);
    if (!uvm_config_db #(virtual interface apb_if)::get(null, "*", "apb_vif", apv_vif))
      $fatal("Failed to get apb if");
  endfunction 


endclass

 

basic_test는 uvm_test에서 상속을 받아왔으며, virtual interface가 정의되어있고, 

연결되지 않는 경우, 에러를 발생하도록 되어있다. 

이것이 가장 기본적인 형태이며, 여기에다가 run_phase를 추가하고,

 

run_phase에서 실제 사용하는 시나리오들을 기술하도록 되어있다. 

이중에서 raise_objection, drop_objection이라는 함수들을 기술을 해줘야 하는데 , 

 

task run_phase(uvm_phase phase);
  ... 
  phase.raise_objection(this);
  ....
  ...
  phase.drop_objection(this);

endtask

UVM이 정말 맥락이 없는게 이런 구문들이 갑자기 훅들어오면, 당황하기 마련이다. 

 

raise_objection은 현재 phase가 시작하는 것을 알리는 신호이고,  

drop_objection은 현재 phase가 끝났다는 것을 알리는 신호이다. 

 

이게 중요한 포인트 중 하나인데, 

이 구문을 사용하지 않으면, raise, drop사이에 뭐가 들어있더라도, 

이것들이 실행되지 않고, 시작하자마자 simulation이 종료가 된다.

 

이 구문은 스케쥴러에게 나는 지금 특정 phase를 수행하고 있으니,

다른것들이 다 끝나더라도 내 작업이 끝날때(drop_objection)까지 기다리라는 의미이다. 

 

그래서 이게 선언이 되어 있지 않으면, 다음 단계가 수행이 되어버리기때문에, 

하다보면 이런데서 디버깅하는데 시간을 좀 소비를 많이 할 수가 있다. 

 

이 phase에 대해서는 나중에 따로 기술을 하도록 하겠다. 

 

하나 더 run_phase는 task로 작성되어야 한다.  build_phase는 function으로 되어야하고, 

아마도 system verilog 언어적 특성때문인것 같은데,

이런것들 때문에 UVM자체는 좀 weird하다는게 맞을듯하다.