RE: [sv-cc] A possible interpretation for vpi_compare_objects

Chuck,

Number 1 is an interesting idea.  I think the idea is that
if the behavior at run-time is the same, then the objects
are the same.  Is that right?

This would make a difference, of course, for applications
such as decompilers that are doing static access.  For example,
consider the two assignments,

  i[3] = ...;
  i[p+1] = ...;

where "p" is a parameter with the resolved value of "2".

Now if I take each LHS and do a vpiIndex iteration on
each, in the first case I get a vpiConstant and in
the second a vpiOperation.  Is this still consistent
with your idea that the two LHS's are the "same object"?

Regards,
Jim

--------------------------------------------------------- 
James H. Vellenga                            978-262-6381 
Engineering Director                   (FAX) 978-262-6636 
Cadence Design Systems, Inc.         vellenga@cadence.com 
270 Billerica Rd
Chelmsford, MA 01824-4179
"We all work with partial information." 
----------------------------------------------------------  

]-----Original Message-----
]From: Chuck Berking 
]Sent: Wednesday, August 02, 2006 3:07 PM
]To: Jim Vellenga; SV-CC
]Subject: RE: [sv-cc] A possible interpretation for vpi_compare_objects
]
]Overall this looks great, Jim.  I would suggest two possible 
]clarifications/additions to this as follows:
]
]1) Re. comparing two bit/var selects-
]   We may want to return TRUE if two bit/var-select objects of same
]   array have index expressions that, though differently specified, are
]   "run-time invariant" (constant exprs) that evaluate to the 
]same values,
]   i.e. rather than strictly vpiDecompile output-based.  This 
]would still be
]   consistent with the third principle as well.
]
]2) You may want to give an example of what is meant by your 
]last paragraph,
]   i.e. 
]      "However, the converse is not required.  In some cases, all 
]       these conditions may be true without requiring that 
]       vpi_compare_objects() return 1, and a return value of 0 
]does not 
]       require that at least one condition be false."
]Regards,
]Chuck
]
]-----Original Message-----
]From: owner-sv-cc@eda-stds.org 
][mailto:owner-sv-cc@eda-stds.org] On Behalf Of Jim Vellenga
]Sent: Wednesday, August 02, 2006 2:21 PM
]To: SV-CC
]Subject: [sv-cc] A possible interpretation for vpi_compare_objects
]
]Here are some thoughts on vpi_compare_objects() coming out of 
]today's meeting.
]
](27.2) IEEE Std 1364-2005 states for vpi_compare_objects() that:
]
]  "The VPI routine vpi_compare_objects() shall return 1 (true) if
]  the two handles refer to the same object. Otherwise, 0 (false)
]  shall be returned. Handle equivalence cannot be determined with
]  a C '==' comparison."
]
]After today's meeting, I'd like to offer the text below as one 
]possible clarification.  Note that according to this proposed 
]clarification,
]
]-- the vpiType of the two handles must match.
]
]-- two vpiVarSelects or vpiBitSelects that differ only in how 
]their indices are expressed will not match because the strings 
]returned by vpiDecompile will differ.
]
]-- if the two handles can differ at any time during the 
]simulation process, vpi_compare_objects() must return FALSE at 
]all times.
]
]Regards,
]Jim
]
]Proposed clarification:
]-------------------------------------------------------------------
]In particular, if vpi_compare_objects(obj1, obj2) returns 1, 
]then at all points in the simulation process at which obj1 and 
]obj2 exist (have not been freed),
]
]-- For any integer property P except vpiLineNo, the value 
]returned by vpi_get(P, obj1) shall be equal to the value 
]returned by vpi_get(P, obj2).
]
]-- For any string-valued property S, except for vpiFile, the 
]value returned by vpi_get_str(S, obj1) shall match the value 
]returned by vpi_get_str(S, obj2) under comparison using the C 
]strcmp() function, or both functions shall return a null handle.
]
]-- For any VPI function that takes a reference handle and 
]returns another VPI handle, if that function is applied 
]separately to obj1 and to obj2, either the returned values 
]shall both be the null handle, or the returned values shall 
]themselves match under vpi_compare_objects().
]
]-- Applying vpi_get_value() or vpi_get_delays() to obj1 shall 
]return the same values as applying the identical function to obj2.
]
]-- If vpi_put_value() or vpi_put_delays() is applied to either 
]handle, the simulation shall subsequently behave as if it had 
]been applied to both.  For example, if vpi_put_value() applies 
]a new value to obj1, immediately applying vpi_get_value() to 
]obj2 shall return the value stored in obj1.
]
]If any of these conditions is not true, vpi_compare_objects() 
]must return 0.  However, the converse is not required.  In 
]some cases, all these conditions may be true without requiring that
]vpi_compare_objects() return 1, and a return value of 0 does 
]not require that at least one condition be false. 
]-----------------------------------------------------------------------
]
]
]--------------------------------------------------------- 
]James H. Vellenga                            978-262-6381 
]Engineering Director                   (FAX) 978-262-6636 
]Cadence Design Systems, Inc.         vellenga@cadence.com 
]270 Billerica Rd
]Chelmsford, MA 01824-4179
]"We all work with partial information." 
]---------------------------------------------------------- 
]  
]
]