Hi
i am using uvm_reg predictor and connection it to the monitor , the provides_response=0 at the uvm_reg_adapter and there is something i dont understand with the bu2reg function at the uvm_reg_adapter is called twice
once from the uvm_reg_map after finish_item:
rw.parent.finish_item(bus_req);
bus_req.end_event.wait_on();
if (adapter.provides_responses) begin
uvm_sequence_item bus_rsp;
uvm_access_e op;
// TODO: need to test for right trans type, if not put back in q
rw.parent.get_base_response(bus_rsp);
adapter.bus2reg(bus_rsp,rw_access);
end
else begin
adapter.bus2reg(bus_req,rw_access);
once from the uvm_reg_predictor:
virtual function void write(BUSTYPE tr);
uvm_reg rg;
uvm_reg_bus_op rw;
if (adapter == null)
`uvm_fatal("REG/WRITE/NULL","write: adapter handle is null")
// In case they forget to set byte_en
rw.byte_en = -1;
adapter.bus2reg(tr,rw);
rg = map.get_reg_by_offset(rw.addr, (rw.kind == UVM_READ));
the problem is that bus_item at the argument is the driver_item when the uvm_reg_map calling it and is monitor_item when the predictor is calling it, so i can do $cast.
I had a UVM testbench causing a similar problem and I used a workaround.
Actually I needed to poll a status bit. Although the monitor was seeing the bit set, uvm_reg_map was calling bus2reg before the predictor, so the reg_read call was never returning the status bit correctly.
{code}
while(out_data[STATUS_BIT]==1'b0) begin regmodel.stat_reg.read(.status(status), .value(out_data)); out_data = regmodel.stat_reg.get(); end //Here should be seen the correct value uvm_info(get_type_name(), $sformatf(“Read data=%x”, out_data), UVM_LOW)
{code}
I had a problem w/the same symptoms (bus2reg being called twice) and the read data not being set. After removing the predictor all together, I still wasn’t getting the read data. I actually thought you needed the predictor, but you don’t.
Then I tracked it down to the fact that with RAL your DRIVER needs to latch the return read data, whereas a monitor was doing that for me before. I was learning how to use UVM, so I started w/a monitor first, then moved to try RAL. So instead of checking via the monitor, I’d be checking via the RAL. BUT I didn’t update my driver to return the read value. Even though I had the predictor connected to the monitor analysis port, and the monitor was recording the read value, this didn’t propagate to the driver/reg read.
For my case, I had a driver that requested that the DUT return the read data on the bus but not care about the read data as I had the monitor doing that comparison. W/O the monitor, and using RAL, the driver now has the responsibility to latch the data on a read and return it to the sequencer.
xx.get_next_item(myseq);
…
// before I didn’t care to latch the return since the monitor was doing it
if (myseq.rw == READ) myseq.data = busif.data); // new code
xx.item_done();
Now the two bus2reg calls return the correct read data to the reg_read side of the RAL.
two bus2reg calls, and the regmodel..read(status, read_value); call from the test returning the data from the first one, which doesn’t have the correct read data, coming from the driver not the monitor (which does have the correct data). This is despite the provides_responses is set to zero
…and solved it in the same manner: duplicating the monitor’s “read response” from the interface in the driver and setting that in the req transaction’s data value
This was tedious to debug and the solution feels like a hack, and seems to be not the way all of this was intended to be. …but it works.
I’m somewhat comforted that its not only me who has observed this behavior. Is there a UVM expert out there who can provide some insight. If someone wants to engage, then I’ll try to put something together on eda playground.
the problem is that bus_item at the argument is the driver_item when the uvm_reg_map calling it and is monitor_item when the predictor is calling it, so i can do $cast.
any one can explain?
The question is why you are using 2 different seq_items in an agent. There should be only one. This makes your life easy.
two bus2reg calls, and the regmodel..read(status, read_value); call from the test returning the data from the first one, which doesn’t have the correct read data, coming from the driver not the monitor (which does have the correct data). This is despite the provides_responses is set to zero
What do you expect setting provides_responses==0 to do? It doesn’t mean the driver doesn’t return the read data. provides_responses==0 means the read data is returned in the same transaction RAL sent to the driver, instead of in a separate response transaction coming from the driver.
As far as the duplicated calls to bus2reg, I don’t think that can be avoided with how uvm_reg is currently designed. The first bus2reg call comes from your call to rg.read(), it needs to translate the transaction returned from the driver before read() returns, so it calls bus2reg. The second call comes separately from the predictor connected to your monitor. RAL has no idea these two events are really the same event, and currently has no way do effectively deduplicate the work.
I think the fix would require something like changing read() ( and write() ), such that if monitor based predictors are setup, read() should ignore the data returned from the driver and wait for the response from the predictor. However, I think there are probably troublesome corner cases such as you could have multiple maps, but not all maps have predictors setup. So while the current implementation is inefficient, really shouldn’t miss anything.