Handling initial reset in UVM driver

UVM
,
1

I am working on module level verification of a counter(up/down counter).

I am looking at handling asynchronous initial reset on environment side. In my case, i just need to make sure that the sequences are sent only after the reset becomes false.

My reset generation in top file and the driver looks as below:


module tb_counter_top;
:
:
  //reset Generation
  initial begin
    reset = 1;
    #5 reset =0;
    #5 reset = 1;
    #100;  
  end
:
:
endmodule

//---------DRIVER---------
 virtual task run_phase(uvm_phase phase);
    super.run_phase (phase); 
    initialize(); //initialise the driver signals
    forever begin
      seq_item_port.get_next_item(req);
      drive();
      seq_item_port.item_done();
    end //forever
  endtask : run_phase

virtual task drive();  
  @( counter_vif.counter_cb);
  if (counter_vif.reset ==1) begin
    counter_vif.counter_cb.load_counter <= req.load_counter;
    counter_vif.counter_cb.count_value  <= req.count_value;
    counter_vif.counter_cb.up_counter   <= req.up_counter;
    counter_vif.counter_cb.run_counter  <= counter_vif.clk_en;
  end //if
endtask

Though the driver is not sending the sequences if reset is true, but sequences are generated. If i am setting load_counter or other control signals in the first sequence, this info is not passed onto to DUT/scoreboard because of reset.
One simple way is, I will send the default values in the first sequence and send the required values in the subsequent sequences. Even if the first sequence is ignored because of reset, there wont be any loss of any important control signals.

Can we use reset phase to wait for reset to become false?
Or wait for reset to be false before calling seq_item_port.get_next_item(req);? (@(posedge counter_vif.reset) before calling get_next_item)
What is the better solution?

2

In reply to uvmsd:

Simply pass your reset signal to the virtual interface. Then you can react in the driver if the reset has been activated.
BTW, the driver is never sending a seq_item. It receives/retrieves a seq_item through the get or get_next_item.

3

In reply to chr_sue:

Thank you chr_sue!
Ok, i mean, driver shouldn’t retrieve seq_item and drive the signals. I should have phrased my sentence well.

reset(its active low) has been passed to virtual interface.
wait(counter_vif.reset ==1) before get_next_item doesn’t work since reset =1 in the beginning.
Can i do as below(it did work though):


//---------DRIVER---------
 virtual task run_phase(uvm_phase phase);
    super.run_phase (phase); 
    initialize(); //initialise the driver signals
    (@(posedge counter_vif.reset) 
    forever begin
      seq_item_port.get_next_item(req);
      drive();
      seq_item_port.item_done();
    end //forever
  endtask : run_phase
4

In reply to uvmsd:
I do not see a limitation …