RAL built-in sequences (e.g uvm_reg_bit_bash_seq) : how to exclude RO/undefined fields from test?

UVM
,
1

Hello all,

I have a Register Model (32bits registers size) with some registers
containing fields, that can be either RW, RO, WO, and also, some empty bits being undefined :

class my_REG_CONTROL extends uvm_reg;
`uvm_object_utils(my_REG_CONTROL)

rand uvm_reg_field CK_EN;
rand uvm_reg_field DATA_EN;
rand uvm_reg_field FREQ_EN;
rand uvm_reg_field FREQ_VAL;
rand uvm_reg_field DUMMY;

// Function : new
function new(string name = "my_REG_CONTROL");
    super.new(name, 32, build_coverage(UVM_NO_COVERAGE));
    add_coverage(build_coverage(UVM_NO_COVERAGE));
endfunction

// Function : build
virtual function void build();
    this.CK_EN    = uvm_reg_field::type_id::create("CK_EN"      );
    this.DATA_EN  = uvm_reg_field::type_id::create("DATA_EN"    );
    this.FREQ_EN  = uvm_reg_field::type_id::create("FREQ_EN"    );
    this.FREQ_VAL = uvm_reg_field::type_id::create("FREQ_CAL_EN");
    this.DUMMY    = uvm_reg_field::type_id::create("DUMMY"      );
    this.CK_EN   .configure(this,   1,   0, "RW", 0,   1'd0, 1, 1, 0);
    this.DATA_EN .configure(this,   1,   1, "RW", 0,   1'd0, 1, 1, 0);
    this.FREQ_EN .configure(this,   5,   2, "RW", 0,   5'd0, 1, 1, 0);
    this.FREQ_VAL.configure(this,   1,   8, "RO", 0,   1'd0, 1, 1, 0);
    this.DUMMY   .configure(this,  23,   9, "RW", 0,  23'd0, 1, 1, 0);
endfunction

endclass

I am then using the ral_seq_bit_bash sequence to test this register,
but when I do so, I can see that both :

  • the FREQ_VAL field (bit 8), which is RO, is tested.
  • the undefined bit(s), matching no fields (bit 7, “between” FREQ_EN and FREQ_VAL) is also tested.

UVM_INFO @ 3203000: reporter@@ral_seq_bit_bash.reg_single_bit_bash_seq [uvm_reg_bit_bash_seq] Verifying bits in register cs_ral_model.REG_CONTROL in map “cs_ral_model.default_map”…
UVM_ERROR @ 3503000: reporter@@ral_seq_bit_bash.reg_single_bit_bash_seq [uvm_reg_bit_bash_seq] Writing a 1 in bit #7 of register “cs_ral_model.REG_CONTROL” with initial value 'h0000000000000000 yielded 'h0000000000000080 instead of 'h0000000000000000
UVM_ERROR @ 3523000: reporter@@ral_seq_bit_bash.reg_single_bit_bash_seq [uvm_reg_bit_bash_seq] Writing a 1 in bit #7 of register “cs_ral_model.REG_CONTROL” with initial value 'h0000000000000000 yielded 'h0000000000000080 instead of 'h0000000000000000
UVM_ERROR @ 3543000: reporter@@ral_seq_bit_bash.reg_single_bit_bash_seq [uvm_reg_bit_bash_seq] Writing a 1 in bit #8 of register “cs_ral_model.REG_CONTROL” with initial value 'h0000000000000000 yielded 'h0000000000000100 instead of 'h0000000000000000
UVM_ERROR @ 3563000: reporter@@ral_seq_bit_bash.reg_single_bit_bash_seq [uvm_reg_bit_bash_seq] Writing a 0 in bit #8 of register “cs_ral_model.REG_CONTROL” with initial value 'h0000000000000100 yielded 'h0000000000000000 instead of 'h0000000000000100

=> What is the best solution to exclude these bits from being tested ?

Thanks in advance for your answer,
Etienne

2

Hello,

Nobody ?

I found a first potential solution for defined fields that I don’t want to check (WO, RO), using the set_compare(UVM_NO_CHECK) on the specific field.

However, I am still lacking a solution for undefined bits (matching no fields in Register definition).

Thanks in advance for any help / advise on this topic,

3

In reply to elaurend:

You can declared the undefined fields as “Reserved” with “RO” access policy. Then you can use set_compare(UVM_NO_CHECK) same as other “RO” fields.

4

Thanks for your answer, that is indeed one solution !
But I would have preferred a more practical one, since it implies defining all RO fields,
which can be a lot of work (even with a RAL generation tool)

Any other ideas based on the UVM functions / methods which would meet my requirements without modifying the Registers definition itself ?

Thanks a lot !

5

In reply to elaurend:
I don’t think UVM provides any other way to deal with the undeclared register fields. As per my perspective, it’s the best approach to declare them as reserved.

It’s manual but one time effort to update all the undeclared fields to RO. You can use some automation to do so.

In addition, from UVM user guide 1.2:

5.5.1.5 Reserved Fields
There is no pre-defined field access policy for reserved fields. That is because “reserved” is a documentation concept, not a behavioral specification. Reserved fields should be left unmodelled (where they will be assumed to be RO fields filled with 0’s), modeled using an access policy that corresponds to their actual hardware behavior or not be compared using uvm_reg_field::set_compare(0).