Search the Community
Showing results for tags 'w1c'.
Found 1 result
-
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.