Jump to content


  • Content count

  • Joined

  • Last visited

  1. 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.
  2. Given a class that defines a field: bit [31:0] foo [4];and with said field added to field automation: `uvm_field_sarray_int(foo, UVM_ALL_ON)I proceed to add a call to my component's build_phase to obtain the results of any configuration changes: void'(uvm_config_db#(bit[31:0])::get(this, $psprintf("foo[%0d]",i), foo[i]));Doesn't compile.I try: void'(uvm_config_db#(bit[31:0][4])::get(this, "foo"), foo));Doesn't compile. It try various other possible permutations. Eventually, I arrive using typedef to avoid syntax limitations in the parameterization clause: typedef bit[31:0] DW; typedef DW[0:3] DW_ARRAY;(NOTE: Had to use the [0:3] dimensioning ala Verilog rather than the [4] dimensioning allowed in SV.)I am now able to deal with uvm_config_db, so long as I deal in terms of the entire array: void'(uvm_config_db#(DW_ARRAY)::get(this, "", "foo", foo)); This is tolerable, if not ideal, for dealing with static arrays. It does require that configuration overrides deal with the array on an all or nothing basis, but does not permit of modifying a single entry within the array by means of uvm_config_db, so far as I can gather. So, to the questions: 1) Am I missing something in the syntax? Is it REALLY necessary to do this typedef stuff to con UVM into accepting my data type? If so, couldn't this have been documented up front? 2) Is there any means by which uvm_config_db can be used to modify only a subset of array elements, rather than overriding the entire array? 3) What if some lower-level entity is intended to modify other entries in this array? 4) What about dynamic arrays? In particular, if I have an associative array and wish to override some few specific locations, am I still going to be required to create a separate dynamic array, set my values there, and then pass it in? Thank you.