Behavior of UVM/OVM COMPARE for associative arrays

UVM
, , ,
1

I have been working on some code conversion from OVM to UVM. I came across a potential OVM issue where the associative array was registered with OVM_NOPRINT that got pass through the OVM_COMPARE also.

I have a class in OVM that is registered with flag OVM_NOPRINT as shown below. I am setting some of the fields in one object and not setting them in another object. I would expect the compare method to fail over here. But it passes in OVM, while it fails in UVM:

class A extends ovm_object;
  
   bit [7:0] syndrome[int] = '{ default: 0 };

  `ovm_object_utils_begin(A)
  `ovm_field_aa_int_int(syndrome, OVM_NOPRINT) // Only NOPRINT flag given
  //`ovm_field_aa_int_int(syndrome, OVM_DEFAULT) // This will shout for an error
  `ovm_object_utils_end
  
  function new(string name = "A");
      super.new(name);
  endfunction
endclass

// Somewhere in top module
A a,b;
initial begin
  a = A::type_id::create("a");
  b = A::type_id::create("b");
  a.syndrome[1] = 5; // Add single element in object a. Not element in object b.
  if(a.compare(b)) begin
    $display("COMPARE PASS");
  end else begin
    $display("COMPARE FAIL");
  end
end

// output OVM:
COMPARE PASS

// output UVM:
UVM_INFO /apps/vcsmx/etc/uvm-1.2/src/base/uvm_comparer.svh(351) @ 0: reporter [MISCMP] Miscompare for a: lhs size = 1 : rhs size = 0
UVM_INFO /apps/vcsmx/etc/uvm-1.2/src/base/uvm_comparer.svh(382) @ 0: reporter [MISCMP] 2 Miscompare(s) (1 shown) for object b@336 vs. a@335
COMPARE FAIL

The above code shows compare pass for OVM (unexpected). While it shows compare fail in UVM (expectedly). Here is the sample code at EDAPlayground here. Can anyone please explain me why the NOPRINT also supresses the COMPARE in OVM?

2

In reply to sharvil111:

I got to know it happens with some of the associative arrays. Does anybody have any info on this?

3

In reply to sharvil111:

This was a bug in the OVM that was not corrected until UVM 1.1b.

Note that there are other UVM bugs with comparing associative arrays. If you were to do

a.syndrome[2] = 0; // sET A VALUE IN ONE OBJECT ONLY that matches the default
b.syndrome[1] = 5; // sET B VALUE IN ONE OBJECT ONLY

you still will not get any error. It only iterates over the elements in A.

In any case, we strongly discourage the use of the ova/uvm field macros for their poor performance.

4

In reply to dave_59:

Got it! Thanks Dave. The link you have posted is not opening. It is showing “Access Denied”. Is it possible for you to give some details on the Mantis entry or post a link where Login is not required? Just to get some more detail.

5

In reply to sharvil111:

I have an associative array of integral data in an UVM object, with the key also an integral type. The factory operations of copy, print, and compare all get disabled if I set the field automation as either
uvm_field_aa_int_int(my_aa, UVM_DEC) or // -- Original intent to suppress only compare for this field. uvm_field_aa_int_int(my_aa, UVM_NOCOMPARE | UVM_DEC)
Only if I explicitly turn on all operations would they work for the array:
`uvm_field_aa_int_int(my_aa, UVM_ALL_ON | UVM_DEC)
I have not tried this for associative arrays of objects, or with string keys.
it seems ALL AA macros are affected. the root cause seems to be an additional check which basically disables ALL operations NOT listed in the 2nd arg of the field macro instance.

6

In reply to dave_59:

Thanks Dave for the details.

Note that there are other UVM bugs with comparing associative arrays. If you were to do

a.syndrome[2] = 0; // sET A VALUE IN ONE OBJECT ONLY that matches the default
b.syndrome[1] = 5; // sET B VALUE IN ONE OBJECT ONLY

Just a small query. I am using UVM-1.2. Are these bugs in UVM-1.2 also?

7

In reply to sharvil111:

Still a bug in UVM 1.2

8

In reply to dave_59:

Thanks. I will implement “do_compare” as a workaround.