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