Access Rights in Ral

UVM
1

Hi,

Lets Take a register of 32 bit which has four fields of 8bit each. In that 4 fields, two are of RO type and Two are of RW type. I created a reg fields class extending from uvm_reg. Later I tried to make reg block and map this register.Unfortunately while mapping , I found a field called rights in add_reg as shown below

reg_map.add_reg( .rg(regA), .offset( 32'h01 ), .rights( "WO" ));

.My question is that what should be the rights given for a kind of register given above and also help me out with affects of this rights. ANd what is the difference between those two types of rights which is in uvm_reg and uvm_reg_block??

Thank you

2

In reply to Anudeep J:

A register might consist of several reg fields. If this is the case you have to define your reg fields by extendending the base class uvm_reg_field. The base class ha s lot of methods available to deal with this reg field, including methosd to set the access policy. All what you have available for the reg field is also available for the reg itself. If you have single reg fields you have to construct your regs form the reg fields. For more details see the UVM reference guide.

3

In reply to chr_sue:

Hi chr_sue,

I got your point but my question is that does reg field and register have different access policies? If no, then why there is a field in the add_reg for rights?

4

In reply to Anudeep J:

UVM provides yyou a broad variety of options for doing things, considering specific requirements.
It’s up to you to make your choice which fits your needs. UVM allows you even to do things which do not fit. But this results mostly in an catastrophe.
With respect to your question. For register handling UVM provides you aalso a lot of different options. If you have simple registers without different reg fields you will construct your model in another ways as when you have registers with different reg fields. If you have reg fields with different access rights in a register you cannot set the access rights from the reg level. Instead you have to do this from the reg field level. In your example do not connect the rights varaible in the add_reg command. Let it simple open. But you have to set the access rights on the reg field level.

5

In reply to chr_sue:

Thanks chr_sue.

I have one more question. Lets take the same example as mentioned above. This time I dont give any rights in add_reg field. But in source code, It is always tied to RW. As described above there 2 RO fields also. Does this RW show affect on RO? or else is it a kind of priortisation happens?

6

In reply to Anudeep J:

You are right, there is a priority. If you set the access policy for the field then the access right from the reg does not overwrite the field feature. See the following example code:

class cmd_reg extends uvm_reg;
`uvm_object_utils(cmd_reg)

    uvm_reg_field TX_READY;             // RO - so not rand

rand uvm_reg_field TX_DMA_RUN; // RW

function new(string name = “cmd_reg”);
super.new(name, 16, UVM_NO_COVERAGE );
endfunction : new

virtual function void build();

  this.TX_READY   = uvm_reg_field::type_id::create("TX_READY");
  this.TX_DMA_RUN = uvm_reg_field::type_id::create("TX_DMA_RUN");
  
  this.TX_READY.configure(this, 1, 15, "RO", 0, 1'h0, 1, 0, 0);
  this.TX_DMA_RUN.configure(this, 1, 14, "RW", 0, 1'h0, 1, 1, 1);

endfunction : build

endclass : cmd_reg

Field TX_READY is configured for “RO”
Field TX_DMA_RUN is configured for “RW”.

class regmodel extends uvm_reg_block;
`uvm_object_utils(regmodel)

cmd_reg cmd;
…
this.default_map.add_reg(cmd, .offset(0), .rights(“RW”));
…
endclass

Does not change the access policy of the reg fields.

7

In reply to chr_sue:

Thank You very much for the solution