UVM-OVM: Compare method bugs

Hi all this post mainly focusing on exercising a caution while using UVM/OVM built-in compare methods using field utility macros. We have seen many folks discouraging about the usage of field utility macros due to their overhead and complexity. But there seems more to it…

Recently while doing some conversion from OVM to UVM, I came across a bug in OVM while using “compare” method for associative arrays. The array was registered with factory with “OVM_NOPRINT” attribute. So I used “UVM_NOPRINT” as a UVM counterpart. But the testcase failed in UVM while it passed in OVM.

Whenever an associative array is registered in OVM, with some attributes that we use, the comparison will not happen and it will always be a successful result. While in UVM-1.1b (and later revisions), the comparison is fixed.

`ovm_field_aa_int_int(myassociativearr, OVM_NORPINT) // Also suppresses the comparison

`uvm_field_aa_int_int(myassociativearr, UVM_NORPINT) // Does not suppress comparison

A pseudo code looks something like this:

class A extends ovm_object;

bit [7:0] syndrome[int] = '{ default: 0 };

`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

function new(string name = "A");

// 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");

// output OVM:

// 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

Here is an EDAPlayground Link for the code in UVM and OVM.

Currently, UVM-1.2 revision also have similar bug like this:

a.syndrome[2] = 0; // sET A value that matches the default
b.syndrome[1] = 5; // sET B any other value

When we set a default value at any index in one object, it matches to any other value in the RHS object. This bug is still present in all the UVM versions.

So, now what to do????

For the OVM bug, register the array explicitly with OVM_COMPARE or OVM_DEFAULT attribute. Still the default value bug will remain open issue.

As a permanent workaround to this, one can use “do_compare” callback hook to manually compare the associative arrays. This will ensure that correct comparison is taking place instead of some opaque built-in code.

Hope this post will keep you aware about the UVM/OVM BCL issue. I had posted a forum question related to this at VerificationAcademy. Mantis entry 3932 discusses about this issue.

One response

  1. […] we discovered one more bug in UVM and OVM build in compare methods. Previously, I discussed about UVM-OVM: Compare method bugs which was about associative array, this post is related to different object […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: