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

From: Chuck Berking <berking_at_.....>
Date: Wed Aug 02 2006 - 12:06:50 PDT
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." 
---------------------------------------------------------- 
  
Received on Wed Aug 2 12:06:55 2006

This archive was generated by hypermail 2.1.8 : Wed Aug 02 2006 - 12:07:06 PDT