uvm_reg_field W1C/W0S update problem

[saxmanlogic]

We ran across an issue when updating registers containing W1C fields.  Specifically, if any field of the CSR requires an update, then calling the parent register's update() results in all W1C fields being written with 1.

Example:  register CTL has field GO with access type W1C in bit 31.  It has field CMD with access type RW in bits 3:0.  Both fields have reset value of 0.

So, coming out of reset, we do:
CTL.CMD.set(2);

CTL.update();

The actual transfer goes out with data of 32'h8000_0002.  Nobody asked for bit 31, but there it is.

The issue appears to be with uvm_reg_field method XupdateX.  For the W1C and W0S cases, it returns a value of "~m_desired".  So, desired is 0, it wants to write a 1, even if m_mirrored is already 0.

I'm not sure what I would consider the 'correct' behavior here.  I can see two possibilities for W1C.

What I would prefer is that if I set(1), update writes a 1.  But, I could also see having it such that XupdateX evaluates ~m_desired & m_mirrored.

 

 

[DavidLarson]

I have found a related problem. 

 

When you need to send a 1 to a W1C register field, the normal flow doesn't work:

register_model.register.w1c_field.set(1); // <--- this is set to 0 internally
register_model.register.update(status);

This is clearly not what the user expects.

 

What is the correct flow for these registers?

[akshasi]

Use Write method instead of set/update. 

 

As update() writes only the 'changed' parts. Conditional write (compare and write). 

 

 

      // model.rfile0.ureg0.destination.set(16'h7698);

       // model.rfile0.ureg0.update(status);

       model.rfile0.ureg0.write(status, 16'h7698, .parent(this));