[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