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.
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)
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?
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.
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.
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.