RE: [sv-cc] Assertion VPI discussion

My apologies: In my second code paradigm, that should
be "vpi_get_str" rather than "vpi_get_handle". Thanks
to Charles Dawson for catching it.

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 Jim Vellenga
] Sent: Thursday, October 28, 2004 8:50 AM
] To: bassam@novas.com; sv-cc@eda.org
] Subject: 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 08:18:34 2004