UVM: uvm_transaction vs uvm_sequence_item

09 Nov uvm_transaction vs uvm_sequence_item

Posted at 01:14h in UVM by IKS 0 Comments

DUT(Design-under-Test)를 검증하기 위해 DUT에 입력하는 stimulus 또는 DUT로부터 출력되는 response 등을 transaction이라고 부른다. 예를 들어 register write command에 사용되는 transaction은 적어도 write 하고자 하는 register의 address와 data 값을 포함한다. UVM에서 이러한 transaction을 생성하고자 할 때 extend 할 수 있는 class로 uvm_transaction과 uvm_sequence_item이 있다. 결론부터 이야기하자면, transaction은 항상 uvm_transaction이 아닌 uvm_sequence_item을 extend 하여 생성해야 한다. 두 class 간에 어떤 차이가 있으며 어떤 이유로 uvm_sequence_item을 extend 해야 하는지 알아보자.

class my_transaction extends uvm_sequence_item;
  
  `uvm_object_utils(my_transaction)
  
  rand logic [7:0] addr;
  rand logic [7:0] data;
  
  // ...
  
endclass: my_transaction

UVM inheritance diagram을 살펴 보면 아래와 같이 uvm_sequence_item은 uvm_transaction을 extend 하고 있음을 알 수 있다. 즉, uvm_sequence_item은 uvm_transaction의 property와 method를 그대로 가지면서, 자체적으로 추가적인 property와 method를 가진다는 뜻이며, uvm_sequence_item 자체적으로 갖고 있는 내용이 핵심이 되겠다.

UVM에서 transaction은 모여서 sequence를 구성하고, sequence는 sequencer를 통해 driver와 통신을 한다. 아주 간단한 경우에는 하나의 transaction으로 이루어진 하나의 sequence만을 사용할 수도 있겠지만, 대부분의 경우 여러 개의 transaction이 모여 하나의 sequence를 구성하거나 여러 sequence가 모여 또 다른 sequence를 구성하기도 한다. Sequencer와 driver 사이의 handshake에 대한 내용은 Driver Sequencer Handshake Mechanism 페이지를 참고하자.

이렇게 복잡한 형태의 sequence가 sequencer를 통해 driver에 전달되는 경우, driver는 여러 request를 동시에 처리하게 되며 각 request에 대한 response를 출력하는 시점은 request 순서와 관련이 없다. 결국 driver가 출력하는 response를 해당 sequence에 제대로 전달하기 위해서는 추가적인 context 정보가 필요한데, uvm_transaction은 이러한 context 정보를 갖지 않는다. 반면 uvm_sequence_item은 sequence ID, sequencer에 대한 handle, parent sequence 등의 추가적인 context 정보를 갖고 있기 때문에 적절한 routing을 위해 sequence, sequencer, driver가 해당 정보를 활용할 수 있다.

uvm_transaction을 extend 하는 transaction 생성 방식은 공식적으로 deprecated 되었으며, 반드시 uvm_sequence_item을 extend 하여 transaction을 생성해야 한다.