Get_next_item in driver blocks

What causes can be under the block of the function seq_item_port.get_next_item(rsp) after calling it?

Particularly, my code is:

  // Continually detects transfers
  task channel_rx_driver::get_and_drive();
    `uvm_info("CHANNEL_RX_DRIVER",$sformatf("Channel RX Driver start get and drive:\n%s",this.sprint()) , UVM_LOW)
    @(negedge vif.reset);
    `uvm_info(get_type_name(), "Reset Dropped", UVM_MEDIUM)
    forever begin
      // wait for data valid to get the next response
      `uvm_info(get_type_name(), "Channel RX Driver waiting to get the next response", UVM_MEDIUM)
      @(posedge vif.clock iff vif.data_vld===1'b1);
      // Get new item from the sequencer
      `uvm_info(get_type_name(), "Channel RX Driver waiting completed. Getting next item...", UVM_MEDIUM)
      seq_item_port.get_next_item(rsp);
      // Drive the response
      `uvm_info(get_type_name(), "Channel RX Driver: next item got", UVM_MEDIUM)
      send_response(rsp);
      // Communicate item done to the sequencer
      seq_item_port.item_done();
    end
  endtask : get_and_drive

Using `uvm_info calls I can trace that get_next_item is the one that blocks my test.

In reply to rubensm:

There is no such method for the

seq_item_port

as

send_response()

. Sending response will be taken care by

item_done()

method of

seq_item_port

. Remove

send_response(rsp)

from your code.

In reply to sunils:

Plus use req type instead of rsp type in get_next_item().

In reply to rubensm:

If get_next_item is blocking, then there is no seq_item available.
But are you sure the get_next_item isblocking or is it
@(posedge vif.clock iff vif.data_vld===1’b1); ?

Addiotionally my recommendation is to execute first the get_next_item and afterwards synchronize on the clock:

    forever begin
      seq_item_port.get_next_item(rsp);

      // wait for data valid to get the next response
      `uvm_info(get_type_name(), "Channel RX Driver waiting to get the next response", UVM_MEDIUM)
      @(posedge vif.clock iff vif.data_vld===1'b1);
      // Get new item from the sequencer
      `uvm_info(get_type_name(), "Channel RX Driver waiting completed. Getting next item...", UVM_MEDIUM)

BTW the wording is you get a request (req) and sending bacvk to the sequencer a response (rsp)

In reply to chr_sue:

Thank for your reply. I’ve been debugging the code with `uvm_info calls and I am sure that is get_next_item who is blocking the execution. Is there any way to debug the state of the seq_items?

In reply to sunils:

Thank you for your reply. Is there really any difference if the word is rsp or req? I see in many books to use these two words, but I have not been able to find any source where states that they must be one or the other depending the case.

About the send_response function, it is a custom driver function in charge to actually drive the packet through the DUT. Therefore it should be there.

The root of the problem is that I cannot monitor whether there are available items to get or not, and I wonder if there is any way to debug it.

In reply to rubensm:
Then you should look if your sequence is starting with the creation of seq_items first.
And please do the get_next_item before the clockedge.

In reply to rubensm:

Hello Rubensm,

There is no difference between rsp and req, they are identifiers only.
Use task try_next_item(output req). It is non blocking task and will fetch the items from the sequence if available or not. Is it your answer. please reply.

In reply to sunils:

Hi,

To debug this issue, go in this sequence:

  1. Check Driver to Sequencer connection, probably in your agent.
drv.seq_item_port.connect(seqr.seq_item_export);
  1. Check Sequence body() method for start_item(req) amd finish_item(req).

  2. Go to the test, and see if run_phase() calls start method on appropriate Sequencer for the Driver.

seq.start(env.agent.seqr);
  1. I am not sure about send_response(rsp) as I’ve never used it. If you want to communicate response back to Sequencer, use:
rsp.set_id_info(req);
   seq_item_port.item_done(rsp);
  1. Your driver is not exactly blocking the testcase, it’s the sequence you are starting is blocking execution of test run_phase(). Use displays there to debug this.