A race condtion issue when we used uvm_reg_predictor to predict the mirrored value explicitly

UVM
, ,
1

Hi, Dear All,

Recently I ran into a problem when I used uvm_reg_predictor, the issue is that first we connect our JTAG monitor with a JTAG register predictor as following :


reg2jtag_predictor.map = regmodel.default_map;
reg2jtag_predictor.adapter = reg2jtag;
reg_env.jtag.monitor.item_collected.connect(reg2jtag_predictor.bus_in);

To catch the register change in time, we connect the jtag.monitor.item_collected.connect() to another component as well, which was intentionly used to monitor the register updates simultaneously.



reg_env.jtag.monitor.item_collected.connect(reg_state.jtag_reg_imp);

......

function void write_jtag_reg(register_op op);
  uvm_reg reg;
  bit [1:0] config;
  `get_reg_by_addr(reg, op.addr);
  config = reg.get_mirrored_value();
endfunction

We monitored the config variable to determine if our checker should be enabled in time, however we found that there is probably race condition happening. uvm_reg_predictor didn’t update the mirrored value before we want to use it, it always return old value from previous register operation.

Can some one tell me why this happened ? What determined the execution order when we connect one port to multiple implementations (exports) ? Any suggestions to solve this issue ?

Thanks,

WangYang

2

In reply to caowangyang:

You shouldn’t rely on the execution order of connected imp ports as this is a UVM BCL implementation aspect (not documented, allowed to change, etc.). Why don’t you rather cascade your second component by connecting it to the register predictor?

Something like:


reg2jtag_predictor.reg_ap.connect(reg_state.jtag_reg_imp);

Naturally, you’ll have to change your reg_state component to work with register items instead of JTAG item. This way you’ll ensure that register updates are done before any other code gets executed.

3

In reply to Tudor Timi:

Hi, Timi,

Thanks for your reply, it makes me much clear, a question is that I am wondering if your codes could work even I didn’t override the write function in uvm_reg_predictor ? Looks to me that I have to create a new class which inherited from uvm_reg_predictor and override the write function, then we could pass the information to cascade component, is that right ?

Thanks,

WangYang

4

In reply to caowangyang:

uvm_reg_predictor already provides all of the functionality to achieve this. Have a look in the UVM source code.

5

In reply to Tudor Timi:

Hi, Timi,

Thanks, I got this, your response is very helpful :)

WangYang