strange behavior in reg_driver in shipped UVM examples

[Martin Barnasconi]

Hi all,

 

I experiencing some strange things in the reg_driver which is shipped as part of the UVM 1.1d release.

 

Below the code snippet taken from the examples/simple/registers/common/reg_agent.sv:

class reg_driver #(type DO=int) extends uvm_component;
   ...
   task run_phase(uvm_phase phase);
      reg_monitor mon;
      $cast(mon, m_parent.get_child("mon"));

      forever begin
         reg_rw rw;
         seqr_port.peek(rw); // aka 'get_next_rw'
         DO::rw(rw);
         mon.ap.write(rw);
         seqr_port.get(rw); // aka 'item_done'
      end
   endtask
   
endclass 

In here, the driver communicates via the sequencer using the peek/get method (in this example there is no explicit response give, so no put method) The call in between the peek and get is DO::rw, where DO is a parameter which points to the dut in these examples. In this dut, the value of transaction/sequence_item rw will be changed.

 

And now the interesting thing: When we peek a value first and after this we get the value, I would expect we get the *same* result. I basically assume the sequence item is stored in a tlm_fifo and we first peek the value without clearing it, and with the get it and will be flushed from the fifo (aka item_done). However, in these examples, the 'get' results in a different value as the initial peek!

It gets even more funny as this (unwanted?) updated value is also returned back to the sequencer, which will call the bus2reg method to process the (unwanted?) updated value.

 

Instead I would expect the usage of a put or put_response method to report back any updated value. But when updating the reg_driver to provide a response (and adding the provides_responses = 1 to the adapter component) some examples, like the register aliasing example, seems to break.

 

I would appreciate any input to clarify if this changed transaction item between the peek and get is really intendend, and if not, whether the exampels can be updated accordingly.

 

Thanks,
Martin