Limiting compare to 2 elements with tolerance margin for a Scoreboard?

Need some guidance on how to compare two transactions of the same class with the comparison having some acceptable tolerance.

I believed it was a simple matter of writing a do_compare method in the transaction class which would have been called by the stock uvm_object compare function.

the behavior I am seeing is that I get a UVM_INFO reporter [MISCMP] for one of the values prior to the do_compare method being called? I can see the do_compare passing, but by this time the uvm_scoreboard has already determined we have miscompare and is failing.

So if you are using the uvm_scoreboard and the objects you are comparing are based on uvm_sequence_item, the members are real data types, what would you have to do in order to compare expected.real to observed.real with 10% tolerance? Let’s say there are other members in the transaction data class as well, so I am also limiting the compare to the ones I care about.

Am I missing some registration? Do I need to skip the UVM macros for these data members? A simple example would be welcome, as it is impossible to get code out of where I am - in fact I am writing this on my iPad.

In reply to tessier5894:

What macros are you referring to? The field macros? If so, it is highly recommended that you not use the field macros and instead implement your own sequence item methods.

This cookbook article describes the methods you should define. By writing your own do_compare() method, you can ensure that the required tolerances are used.

In reply to cgales:

Yes, the field macros are what I was referring to. If I wanted to do this style of compare are you recommending that I skip the field macros for the class members that need to compare for tolerance and add a do_compare method? I already have added the do_compare method and expected that was all I needed to do, but somehow it is failing even before it calls the do_compare method.

Thanks for the insight, I was hoping for a code snippet that I could study.
TomT…

In reply to tessier5894:

Don’t use any field macros. Only use `uvm_object_utils(sequence_item) to register the sequence_item with the factory.

The article I referred to has examples of these functions that you can study.

In reply to cgales:

So you are saying that if I use the macros then my own do_compare within my transaction class is called after the built in compare, as that seems to be the behavior.

Is there another way, I know this isn’t tough but seems this type of behavior would have been consider in the macro development.

TomT…

In reply to tessier5894:

In fact after reading that article, that exactly what I did, was write my own do_compare routine to allow my tolerances. So I still confused as to why the reporter indicated that I had a failure PRIOR to calling my do_compare function?

I don’t believe we have a solution yet.
TomT…

In reply to tessier5894:

If you still have field macros, you will get the behavior you are seeing. As I stated before, the solution is to not use any field macros and write your own sequence_item methods.

There are many different options associated with the field macros than can control the behavior of each variable. These include printing a variable, using it in comparison, copying, etc. Unless you know all of these, it can be difficult to achieve the desired results. This is why we strongly advise against using the field macros.

In reply to cgales:

To clarify Chuck’s response, do_compare() is a hook method called after comparing all the registered fields. The result of do_compare() gets ANDed with the field macro compares; you cannot change a false to true compare.
`uvm_field_real
does a simple equality(==) compare which you should never do with real numbers.

In reply to dave_59:

Dave,

That was the clarity I needed. The standard field macros do include a field by field compare function which is why I saw the failed compare before my do_compare hook was called.

So the approach would be to eliminate the field macros, add the functions I need back, then my do_compare should work?

TomT…