`uvm_field_int(variable-name, UVM_COMPARE) does comparison with ‘==’, instead of ‘===

[mano]

`uvm_field_int(variable-name, UVM_COMPARE) does comparison with ‘==’, instead of ‘===’

Won't this pose problems when comparing data types which can contain ‘x’ or ‘z’ (e.g logic) ?

<QUOTE UVM 1.1, uvm_object_defines.svh>

// MACRO: `uvm_field_int

//

// Implements the data operations for any packed integral property.

//

//| `uvm_field_int(ARG,FLAG)

//

// ~ARG~ is an integral property of the class, and ~FLAG~ is a bitwise OR of

// one or more flag settings as described in <Field Macros> above.

`define uvm_field_int(ARG,FLAG) \

begin \

case (what__) \

UVM_CHECK_FIELDS: \

begin \

__m_uvm_status_container.do_field_check(`"ARG`", this); \

end \

UVM_COPY: \

begin \

if(local_data__ == null) return; \

if(!((FLAG)&UVM_NOCOPY)) ARG = local_data__.ARG; \

end \

UVM_COMPARE: \

begin \

if(local_data__ == null) return; \

if(!((FLAG)&UVM_NOCOMPARE)) begin \

if(ARG !== local_data__.ARG) begin \

void'(__m_uvm_status_container.comparer.compare_field(`"ARG`", ARG, local_data__.ARG, $bits(ARG))); \

if(__m_uvm_status_container.comparer.result && (__m_uvm_status_container.comparer.show_max <= __m_uvm_status_container.comparer.result)) return; \

end \

end \

end \

</QUOTE UVM 1.1, uvm_object_defines.svh>

[mea1201]

I would recommend that you do not use the field macros at all, because they expand into too much bloat, and can be inflexible as you've discovered. Instead, implement the comparison and other basic operations with the do_* methods. So, you can define your own do_compare, and ensure the comparison uses === to consider X and Z states if that is what you want.

[mano]

thanks mea1201. Using do_compare would let me implement the method to my liking. This is a viable alternative.

I was also a bit concerned for unsuspecting users who might use the compare method assuming it will do what they expect (return fail if a comparison mismatch is found, inclusive of X's and Z's).

I was a bit suprised when i couldn't find any discussion in this area. I was hoping for some reasoning behind the current implementation of the compare method.

[bhunter1972]

Personally, I disagree with mea1201. But that's the equivalent of starting a holy war and I've no desire to do that.

At any rate if you do use the built-in compare functionality, you are comparing transaction classes. Typically, the monitor is pulling the signals off of the interface and creating or unpacking these transactions as it sees them. Either the monitor or the interface should be checking for X's and flagging these X's as errors as appropriate. The transaction classes will abstract the 4-state logic away and store the values as bits, not logic.

The point is that once you leave the monitor the signaling details of X's and Z's are gone anyway so you should only be left with 2-state classes and comparing those.

At least, that's what I do. Your mileage may vary.

[uwes]

hi,

i agree with that (xz checking in the interface/monitor/collector) everything else only two state.

i think the overall principle to save your time when coding verification environments is abstraction (go from cycles/time to events, from xy01 to 01, bit-wiggle to transactions) and since abstraction typically involves information loss you need to perform the appropriate checks at the right level (physical checks like xy at the physical level, logical/data checks at the higher levels)

/uwe