Uvm_reg::do_predict() in UVM (1800.2-2020-1.0) does not skip prediction if the status field is set to UVM_NOT_OK

[salmantanvir]

The uvm_reg::do_predict() method contains an if clause which is true when the status field of the register is set to UVM_IS_OK. However it seems the begin end statements are unintentionally missed which causes the prediction to be done also when the status is UVM_NOT_OK. I would expect prediction to be skipped and it seems from the indentation that this was also intended by the implementer. 

Another issue related to the incorrect processing of the status field (UVM_NO_OK) in uvm_reg_predictor::write() has been open for quite some time at:

0005449: uvm_reg_predictor ignores status of bus_op - Accellera Mantis (mantishub.io)

Would it be possible for someone from the UVM working group to provide an estimate as to when these issues can be resolved. Thanks

[zaidiash]

Mantis added for the topic:

0007259: uvm_reg::do_predict() "begin end statements are unintentionally missed" - Accellera Mantis (mantishub.io)

[Michael Privett]

Based on my testing, an additional change will be required in the class uvm_reg_bit_bash_seq.svh.

My assumption here is that the fix for this issue is adding the "begin" at line 1404 (above) and "end" at (1419).

 

Problem 1: uvm-1800.2-2020.1  uvm_reg_bit_bash_seq.svh contains the following line to calculate the expect value:

exp = rg.get() & ~dc_mask; // from line 173

With the planned fix, the mirror and desired values remain the same.  The problem is that when the desired value is non-zero, a non zero value is expected in the later comparison, which will result in a miscompare.

if (val !== exp) begin // Line 181

Potential Fix: change to 

exp = rg.get_mirrored_value() & ~dc_mask; // from line 173

 

Problem 2: The bit bash status comparison should be configurable

Here's the code in question:

175         if (status != UVM_IS_OK) begin
176            `uvm_error("uvm_reg_bit_bash_seq", $sformatf("Status was %s when reading register \"%s\" through map \"%s\".",
177                                        status.name(), rg.get_full_name(), map.get_full_name()))
178         end

An error status may be correct and required by the architecture.  For example, an APB slave may be required to assert slave error for an illegal write.

For this case, we should be able to disable this error in the sequence (perhaps config_db set).  In our TBs, we don't need the register tests to "check" the bus error status (status), we let our scoreboard handle that.

 

Thoughts?

[Justin Refice]

This is a known issue, covered by the currently open mantis: https://accellera.mantishub.io/view.php?id=6913

In a nutshell:  RAL doesn't currently provide any API for indicating that a register is "temporarily volatile"...  basically something has happened which causes the model to lose track of the expected state of the register, but it's a potentially recoverable event. 

We're currently working on how such an API could/should work.

Thanks for the information!