class driver#(int PARAM_NAME) extends uvm_driver #(seq_item#(PARAM_NAME))
The driving loop is :
forever begin
seq_item_port.get_next_item(req);
do_transaction();
// please note that the transaction is visible on the bus
seq_item_port.item_done();
$cast(rsp,req);
rsp.set_id_info(req);
seq_item_port.put_response(rsp)
end
Without an actual testcase, it’s difficult to provide accurate feedback.
However, you shouldn’t cast the req to rsp. You should clone() req and cast that to rsp to ensure that the original req won’t be reused. I would also call item_done() after the response is created just to ensure that req hasn’t been changed at some point outside of this task.
forever begin
seq_item_port.get_next_item(req);
do_transaction();
// please note that the transaction is visible on the bus
$cast(rsp,req.clone());
rsp.set_id_info(req);
seq_item_port.put_response(rsp)
seq_item_port.item_done();
end
Thank you for your suggestion . Unfortunately it doesn’t work either in my case.
The example is based on production code, so I was hoping for more of a theoretical approach, since I haven’t seen any documentation/online resource for this particular case.
The code in uvm_sequence::put_response() is trying to $cast() between a uvm_sequence_item handle and the RSP type from your sequence declaration. Did you give a different RSP type than then REQ type?
Could you share code for the sequence class specialization in the test i.e handle declaration of the sequence in the test using which you call task start
If you don’t specialize the uvm_sequence on line 22, then req is just uvm_sequence_item and you will get an elaboration error on line 33 for the req.data reference. You must have:
class tx_sequence extends uvm_sequence #(tx_item(P));
You must seeing be a disturbance in the matrix. I just tried Questa 2022.4_2 and it correctly gave an elaboration error for req.data and rsp.data, when uvm_sequence uses the default specialization uvm_sequence_item.