RE: [sv-cc] Assertion VPI discussion

Bassam:

Re: I'm not sure what you mean by "reject attempt to have
same names for object types," but there is a key feature
of VPI that would be hard to undo. Specifically, if
one has a handle to an object, no matter how one
obtains that handle, one must be able to apply both

  vpi_get(vpiType, <object_handle>)

and

  vpi_get_handle(vpiType, <object_handle>)

and have each function return something unambiguous
(IEEE Std 1364-2001, Section 26.3.2). So you can't
have these functions return "vpiAssertProperty"
if you got the object one way and "vpiAssertion"
if you got it another way. They would have to be
two distinct objects.

On the other hand, if an "assert property" is something
different from an "assertion", they should have different
names (different values for vpiType).

Does this fit in with your thinking?

Regards,
Jim Vellenga

---------------------------------------------------------
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: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On
] Behalf Of Bassam Tabbara
] Sent: Wednesday, October 27, 2004 2:25 PM
] To: sv-cc@eda.org
] Subject: [sv-cc] Assertion VPI discussion
]
] Hi All,
]
] I had to remind myself of some things I had forgotten to
] clear up the issues raised in the call this morning (thx
] Francoise!), here's a summary as I see it. Please feel free
] to discuss by email, we can also have a small meeting for
] people interested in working to address this if need be
] before the full meeting unless you all agree with the plan below.
]
] ** Motivation/Explanation:
]
] A) Assertion API of section 28 works based on the **VPI
] diagram in that chapter**. It is a direct mechanism to:
] a) access assertions (immediate/concurrent)/sequence/....
] to get handles
] b) register callbacks to get data
]
] B) The VPI of section 31 is a (design statement) navigation
] mechanism. So it also can "see" assertions
] (immediate/concurrent/...) as it walks the statements.
]
] ** Note that the Assertion API is in production use and has
] found a lot of success in apps that want to get at the
] assertions directly, the navigation VPI has also been
] discussed/brushed up, so really the mandate here is to try to
] smooth things out (in a simple way) not destroy one or the
] other and potentially add more errors. I believe my
] suggestions below should accomplish this.
]
] ** 3 Ideas to smooth things out:
]
] 1) Consolidation (NEW TICKET): FIX and consider how to
] incorporate the VPI diagram of Assertion API into chapter 31.
] **NOTE that this also means fix both of:
] - figure 28.1 should have "instances" instead of "module".
] - remove Note below the figure
] ** This ticket means fix 31.2 to have "assertion" in there
] (in addition to concurrent assertion, NOT a replacement) and
] delete figure 28.1 and Note that follows it from section 28.
]
] 2) Clear-up (NEW TICKET): ADD a few sentences in Assertion
] API section to say that handles can be obtained through this
] "direct access mechanism" in that chapter or thru the design
] navigation (i.e. the handles are the same of course ....), to
] dispell any confusion, i.e. add some wording in 28.3.1.
]
] 3) REJECT attempt to have same names for object types: This
] is what 265 tries to do, albeit it is short-sighted (leading
] to much confusion) focusing plainly on sv_user_vpi.h
] "cleanup" and did not seriously consider changes in names
] needed to VPI diagrams, or the different access mechanisms at
] all and proper consolidation. So since the 2 namings schemes
] are from different mechanisms/motivation this task is not
] really warranted. I suggest that 265 be dropped i.e. closed
] with an explanation that the different object types are for
] the different access mechanisms explained above.
]
] ** Action Items (once we are all agreed on them...):
] - Close 265 with an explanation of "not a bug"
] - Discuss, then file new tickets as above.
]
] Thx.
] -Bassam.
]
] --
] Dr. Bassam Tabbara
] Architect, R&D
] Novas Software, Inc.
] (408) 467-7893
]
]
Received on Thu Oct 28 05:50:25 2004