Issue with register read transaction

Hello,

I have initiated a register read transaction through register model.
Say,

//sequence
uvm_reg_data_t rd_data;
uvm_status_e status;

//body
p_sequencer.my_model.REGISTER_NAME.read(status,rd_data);
//endbody

//endsequence

My assumption here is, read task will call the reg2bus and generate the transaction item from the register item. Then it will start the sequencer with this request and finish it.
But when I checked the code in uvm_reg_map, I can see it is calling bus2reg post to finish item. I dont understand why read task calls bus2reg when my provides_responses is 0. I am not sending any response packet from the driver. Instead I am calling bus2reg from my predictor which get the transaction with rd_data from the monitor.

Issue facing is, bus2reg is called twice. One by the read task of uvm_reg_map which has rd_data as 0 cause I am not providing any rsp packet from driver. And second call is from my predictor which have the actual rd_data present. Read task output rd_data is 0 obviously.

Can someone help me solve this issue.

In reply to rexjohn4u:

If the responses are disabled in adapter reg_map just sends read_req to adapter for converting to uvm_reg_bus_op type, this shouldn’t cause any harm. You didn’t specify what error you are getting, if it’s data mismatch because of auto_check_on_read, then you need to disable auto_predict as you are using predictor explicitly. One way would be to keep auto_predict and auto_chk disabled always and use reg.mirror instead of reg.read to force checking.

Thanks,
Rohit

In reply to rohitk:

Hello Rohit,
Problem being I am not getting RTL read data through read task.
Auto predict is switched off. I am using monitor-predictor combo to fetch rtl read data.
But as the read task itself calling bus2reg and I am not providing any response from driver, bus2reg is getting read data as 0.

In reply to rexjohn4u:

In simple words, I wonder who will provide read data to bus_req so that bus2reg call from read task gets proper read data.

In reply to rexjohn4u:

For that to happen you need to set provide_response=1 and send back response data from your bus UVC. UVM RAL is just an mediator between registers and bus interface, if no response is sent back by bus UVC then reg_model will not get response read data back. What is the reason behind disabling responses, you may want to revisit the initial problem.

In reply to rohitk:

Thats the catch here. What if my driver is not supposed to send the response packet. How should the read task get the read data? It is not necessay that driver should sent rsp packet back to sequencer.
For collecting the response from rtl, i have provided monitor and sending transaction with proper read data to predictor. Predictor then calls bus2reg and updated register model.
But by that time read task calls bus2reg.

In reply to rexjohn4u:

I think in your case read response data can be collected by issuing reg.get() once reg.read has completed.

In reply to rohitk:

Yup that is one solution here. But still I dont understand what Am I missing here. I dont see it logical to call bus2reg if the response packet is not available.

In reply to rexjohn4u:

Looks like issue is solved. Actually driver was supposed to update the req.rd_data before calling item_done. That is cause sequencer updated bus_req of uvm_reg_map with this read data before calling bus2reg. Earlier I was not updating req.rd_data in proper time

Thanks,

In reply to rexjohn4u:

In reply to rexjohn4u:
Looks like issue is solved. Actually driver was supposed to update the req.rd_data before calling item_done. That is cause sequencer updated bus_req of uvm_reg_map with this read data before calling bus2reg. Earlier I was not updating req.rd_data in proper time
Thanks,

Hi rexjohn4u,

This means you were able to send the response collected by the monitor an obtain the proper read value? Or did you have to explicity collect the read data from the driver?

I’m facing a similar issue,

Thanks!