RE: [sv-cc] Assertion VPI discussion

What's that saying ? The minute you publish something it becomes outdated ?

More fixes todo:

31.37, "immediate assert" should be "immediate assert type"

Replace

assume property 437
assert property 437
cover property 437
immediate assert 441, 443
property inst 439
sequence inst 441

with:

assume type 437
assert type 437
cover type 437
immediate assert type 441, 443
property type 439
sequence type 441

Thx.
-Bassam.

--
Dr. Bassam Tabbara
Architect, R&D
Novas Software, Inc.
(408) 467-7893
-----Original Message-----
From: Bassam Tabbara [mailto:bassam@novas.com] 
Sent: Thursday, October 28, 2004 11:15 AM
To: 'Jim Vellenga'; 'sv-cc@eda.org'
Subject: RE: [sv-cc] Assertion VPI discussion
Hi Jim,
Yes indeed thx a lot for the reminder. I guess you could say it's been going
in and out of my thinking dunno why :-)! From my email (below) (1), (2) (use
*same handles* regardless of how you get it (navigation walk or direct
access)) cannot co-exist with (3) (do no change ANYTHING). So yes you are
right (3) forgets the fact that you need to have some common (lower) layer,
some set of types you get to in order to query for the values... Guess I had
some wishful thinking when I wrote (3) there, and forgot why I filed 265 to
begin with !
** Note: To address your example vpiAssertion and vpiConcurrentAssertion can
co-exist the former covers all of immediate, concurrent, property and
sequence ... Basically anything that can have a "match" on an "attempt" ....
Your point below would indeed apply to things like: vpiAssertProperty vs.
vpiAssertType and so on ... [So again the idea is that if you iterate on
vpiAssertion (handle) you can quickly get at all of the things (instances)
that would have data]. The name conflict stems from VPI model dealing with
"structure" (mimics BNF), while Assertion VPI in 28 deals with the "type of
instance" and data access, but as Jim points out we should have the same
name for same type, otherwise it's really confusing !
** (3) SAME NAMES TO SAME object types: Looking at 265, I had already made
proposal/notes there to change some things (sv_user_vpi.h and figs), but
it's not complete at all, currently my list is:
 - 31.35, "immediate assert" should be "immediate assert type",
 - 31.30, "assert property" should be "assert type", 
	"assume property" should be "assert type", 
	"cover property" should be "cover type",
	"property inst" should be "property type"
 - 31.31 "property inst" should be "property type"
 - 31.32 "property inst" should be "property type"
 - 31.33 "property inst" should be "property type"
 - 31.34 "sequence inst" should be "sequence type"
 - 31.35 "sequence inst" should be "sequence type"
 - 31.41 "sequence inst" should be "sequence type"
 - 31.42 "sequence inst" should be "sequence type"
 - 31.39 "sequence instance" should be "sequence type"  <<<< This is a bug
to begin with ("inst-ance-")...
 - Index "sequence inst 441" should be "sequence type 441"
 - sv_vpi_user.h delete the following:
	#define vpiAssertProperty 650
	#define vpiAssumeProperty 651
	#define vpiCoverProperty 652
	#define vpiPropertyInst 660
	#define vpiSequenceInst 664
	#define vpiImmediateAssert 665
Also note (from below), 2 new tix:
] ] 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.
      ** Must also add a new class defn for "assertion"
		- class definition would have "vpiAssertionType" property ]
] ] ] 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. 
** BTW, since VPI chapter was the late arrival it is the one that should be
victim of the change i.e. 28 integrated into it, not to mention the changes
are fairly easy/obvious/localized there.
Thx guys!
-Bassam.
P.S. If someone has a "soft version" of the VPI chapter I can try to hack it
... File the tix and append appropriate proposal fixes....
--
Dr. Bassam Tabbara
Architect, R&D
Novas Software, Inc.
(408) 467-7893
-----Original Message-----
From: Jim Vellenga [mailto:vellenga@cadence.com]
Sent: Thursday, October 28, 2004 8:18 AM
To: bassam@novas.com; sv-cc@eda.org
Subject: 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
] ]
] ]
]
]
]