I am currently working with UVM RAL and I encountered this error:
“Response queue overflow, response is dropped”
Got the above error since my driver was calling seq_item_port.item_done(rsp). The error however goes when I change it to seq_item_port.item_done() in the driver.
My UVM RAL sequence doesn’t explicitly make a call to get_response(rsp) but the register reads and writes work perfectly. My question is,how does RAL sequence get the response back if we don’t call the get_response() explicitly?
The RAL is supposed to abstract away the accesses to registers with its API. When you call a register access method, it uses the register adapter class to convert to/from a generic register item to a bus specific sequence_item.
When your driver does a get_next_item(req) call, it then uses the req sequence_item to do a frontdoor register access. When it calls the item_done() method, the sequencer-driver hand-shake completes and the handle to the req sequence_item is used to retrieve the response data. If you call item_done(rsp) you start to push rsp items into a response queue which is not being unloaded by the adapter.
The adapter has a variable called provides_responses - if this was set to 1, then your item_done(rsp) would not result in an error.
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:
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 ?