Uvm_path_e vs uvm_door_e

UVM
, ,
1

I have the following scenario:

class user_cb extends uvm_reg_cbs;


 virtual function void post_predict(
input uvm_reg_field fld,
input uvm_reg_data_t previous,
inout uvm_reg_data_t value,
input uvm_predict_e kind,
input uvm_path_e path,
input uvm_reg_map map

);
endfunction: post_predict

endclass

I get the following error:
L148 : xmvlog: E, SVNOTY (): Syntactically this identifier appears to begin a datatype but it does not refer to a visible datatype in the current scope.

This is for the line that has uvm_path_e in the argument.

I see that uvm_door_e is a new replacement but that just makes the above function redundant if that is the case.

is there a way around this?

2

Which UVM implementation are you using? Have you looked at the Accellera’s UVM 2020-3.0 Reference Implementation released earlier this year? They’ve made the UVM more backward compatible friendly.

3

Realized the issue. it was because we are using the IEEE library. Will look into that.Thanks

Another question on the same note. I am trying to get a register callback when a backdoor write takes place. not successful. Even tried using uvm_reg_bd_cb to register a cb but did not work. Any ideas?