Jump to content

uvm_reg_field W1C/W0S update problem

Recommended Posts

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:


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.



Share this post

Link to post
Share on other sites

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

This is clearly not what the user expects.


What is the correct flow for these registers?

Share this post

Link to post
Share on other sites

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));

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now