Jump to content

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

Recommended Posts

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


Link to comment
Share on other sites

  • 3 weeks later...
  • 8 months later...

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.



Link to comment
Share on other sites

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!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...