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

Thanks Jim/Chuck,

This does look good -- I was reading this primarily with class var/obj
in mind.  

About (2) below, easiest is to say this is necessary but not sufficient.

Thx.
-Bassam.

-----Original Message-----
From: owner-sv-cc@eda-stds.org [mailto:owner-sv-cc@eda-stds.org] On
Behalf Of Chuck Berking
Sent: Wednesday, August 02, 2006 12: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." 
----------------------------------------------------------