Jump to content

Overlapping field of non conflicting access policy


Recommended Posts

Hello

Following user guide http://www.accellera.org/images//downloads/standards/uvm/uvm_users_guide_1.2.pdf that explain through chapter 5.5.1.4 the mapping between Ieee1685-2009 and UVM (at the time UVM 1.2)

We can understand some compatibility between the 2 standard.

I face UVM_ERROR when I build my register model.

I describe in ipxact 2009 2 overlapping field of non-conflicting access policy, which comply with ipxact rules; in particular SCR 7.2 : 

Quote

No bit field shall have a bitOffset value that falls within the bit range of another bit field, unless one of the registers has an access element with the value read-only and the other has an access element with the value write-only or writeOnce.

I use my uvm generator tool which produce the expected systemVerilog/UVM code and expect it to be functional. Apparently the uvm library forbid this case. While a similar case is allowed and describe in chapter 5.7.5 RO and WO Register Sharing the Same Address of the uvm user guide. To be note this case of overlapping register with non conflicting access policy is also supported by ipxact 2009 and in particular is covered by SCR 7.1

Here is code sample of the issue I face:

`include "uvm_macros.svh"
program top;

  import uvm_pkg::*;

  class my_reg_test extends uvm_reg;

    uvm_reg_field FD_WO;
    uvm_reg_field FD_RO;

    function new(string name = "my_reg_test");
      super.new(name,8,UVM_NO_COVERAGE);
    endfunction

    function void build();
      this.FD_RO = uvm_reg_field::type_id::create("FD_RO");
      this.FD_WO = uvm_reg_field::type_id::create("FD_WO");

      this.FD_RO.configure(this, 8,  0, "RO", 0,   8'h00, 1, 0, 1);
      this.FD_WO.configure(this, 8,  0, "WO", 0,   8'h00, 0, 0, 1);

    endfunction
  endclass


  initial begin

    my_reg_test rgm;
    rgm = new;

    rgm.build();
   
    $write("!! rg build end !!\n");
  end

endprogram

Printed output get from my simulator:

UVM_INFO ../1800.2-2020-2.0/src/base/uvm_root.svh(458) @ 0: reporter [UVM/RELNOTES] 
  ***********       IMPORTANT RELEASE NOTES         ************

  This implementation of the UVM Library deviates from the 1800.2-2020
  standard.  See the DEVIATIONS.md file contained in the release
  for more details.

----------------------------------------------------------------
Accellera:1800.2-2020:UVM:2.0

All copyright owners for this kit are listed in NOTICE.txt
All Rights Reserved Worldwide
----------------------------------------------------------------

      (Specify +UVM_NO_RELNOTES to turn off this notice)

UVM_ERROR ../1800.2-2020-2.0/src/reg/uvm_reg.svh(766) @ 0: reporter [RegModel] Field FD_RO overlaps field FD_WO in register "my_reg_test"
!! rgm build end !!
Simulation complete via implicit call to $finish(1) at time 0 FS + 1
./test.sv:2 program top;

Looking at  UVM library source code and in particular at uvm_reg::add_field implementation, the library does not consider field access policy to rise an error.

Is this UVM_ERROR in this case an explicit requirement or could it be considered as a bug ?

Is there a way to work-around this limitation ? Can I override  uvm_reg::add_field in a specialization of uvm_reg class ?

What is the effective status of compatibility between UVM and ipxact ? It is not very clear to me what is the subset of both standard expected to be compatible. Is there initiative to enhance the current uvm user guide with such data ?

Thanks

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.

Guest
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...