In reply to mperyer:
Hello,
I’m stuck on the same problem as the one which was described by ash7 (a long time ago) while reusing a code developped by another team.
I am trying to run a built-in base sequence for register models, but it fails with “response queue overflow”.
I tried to apply the solution proposed by mperyer, namely setting provides_responses to 1 (instead of the previous value 0). Now I have a fatal error in my adapter: the cast in the bus2reg fails whereas it worked when provides_responses was 0.
Typically, the code looks like:
virtual function void bus2reg(uvm_sequence_item bus_item, ref uvm_reg_bus_op rw);
ahb_monitor_transfer ahb_trans;
if (!$cast(ahb_trans, bus_item)) begin
`uvm_fatal("NOT_AHB_TYPE","Wrong type for bus_item")
return;
end
// Code to transform bus access into reg access
// ...
endfunction
The cast fails; it seems I am mixing bus_items of two types:
uvm_sequence_item → ahb_transfer → ahb_monitor_transfer
ahb_monitor_transfer is a transaction generated by the monitor (to the scoreboard), wheras ahb_transfer is a transaction sent to the driver.
The additional fields of the ahb_monitor_transfer class are data collected by the monitor.
The sequencer handles only ahb_transfer (i.e. responses are of the same type).
// Response is defaulted to ahb_transfer !
class ahb_master_sequencer extends uvm_sequencer #(ahb_transfer)
//...
endclass
I have no documentation why the authors of this UVC coded it this way…
In particular, I don’t get why the bus2reg method of the adapter expects ah ahb_monitor_transfer type because the response sent by the sequencer should be ahb_transfer !
Do you recognize a “common practice” in the way this uvc is coded ?
Do you have an idea why provides_response influences this behaviour ?
Thanks,
Jean-Luc