I have a base class, where all fields are registered as UVM_ALL_ON. In class extended from this base class,i want to remove some field from comparing (UVM_NOCOMPARE).
class a ;
rand [2:0] bit tag;
rand [7:0] bit addr;
/////////////////////////////
class b extend a;
`uvm_field_init (tag, UVM_ALL_ON | UVM_NOCOMPARE)
//other functions and fields
endclass
But, still TAG is getting compare even though its been registered as NO_COMPARE in extended class.
Any clue is appreciated, about how to remove “tag” from comparing.
You should remove all of the `uvm_field_* macros and implement the Transaction Methods individually to give you better control. This will allow you to override the required methods in your extended class as required.
I don’t think you’ve answered the question. Sometimes there are legacy reasons to not follow this advice. I also have the same question as Debashis. Can it be done?
One solution that I found can work is to remove the field macro registration from the base class, and relocate the field macro registration into the extended class for the base class elements.
Thze recommendation is to avoid the field macros because it puts a big overhead on the simulation and might cause additional problems.
BTW, why do you want to have UVM_NOCOMPARE? UVM_ALL_ON creates automatically the do_compare function. It is there but you do not have to use the compare function where do_compare is called.
If you are using a UVM Framework Generator like UVMF from Mentor or the EasierUVM Code Generator from Doulos(Doulos) it creates all the seq_item methods automatically for you.
In reply to enolan: (Not denying others’ recommendation. Yes, we should follow the recommendation for performance reasons. But just to answer the question:)
I was trying to achieve the same thing as per my scoreboard requirements. Was able to achieve it using the same approach using UVM_1.2 and UVM_IEEE_1800.2-2017.
UVM has separate bits for UVM_COMPARE and UVM_NOCOMPARE.
The above method essentially sets both the bits (COMPARE & NOCOMPARE).
Not sure how it was handled in the previous implementation if both bits are set.
Can you try this? (- to explicitly deassert the COMPARE bit and set the NOCOMPARE BIT, while keeping others ON)