[sv-cc] RE: VPI issues

Hi Bassam,

 

I would like to get 1503 reassigned to myself and move it to SV-AC.  I
think that SV-AC should create and approve it and then it should move to
SV-CC.  These clarifications are significant and should make the 2008
release.  

 

You state that the callbacks should apply to sequence instances and
property instances.  Please be more specific.   Below is the list of
possible callbacks.  

 

-   cbAssertionStart. An assertion attempt has started. For most
assertions, one attempt starts each and

every clock tick.

- cbAssertionSuccess. An assertion attempt reaches a success state.

- cbAssertionFailure. An assertion attempt fails to reach a success
state.

- cbAssertionStepSuccess. Progress one step an attempt. By default, step
callbacks are not enabled

on any assertions; they are enabled on a per-assertion/per-attempt basis
(see 38.5.2), rather than on a

per-assertion basis.

- cbAssertionStepFailure. Fail to progress by one step along an attempt.
By default, step callbacks

are not enabled on any assertions; they are enabled on a
per-assertion/per-attempt basis (see 38.5.2),

rather than on a per-assertion basis.

- cbAssertionDisable. The assertion is disabled (e.g., as a result of a
control action).

- cbAssertionEnable. The assertion is enabled.

- cbAssertionReset. The assertion is reset.

- cbAssertionKill. An attempt is killed (e.g., as a result of a control
action).

- cbAssertionDisablePassAction. The pass action is disabled for vacuous
and nonvacuous success

for the assertion (e.g., as a result of control action).

- cbAssertionEnablePassAction. The pass action is enabled for vacuous
and nonvacuous success for

the assertion (e.g., as a result of control action).

- cbAssertionDisableFailAction. The fail action is disabled for the
assertion (e.g., as a result of control

action).

- cbAssertionDisableVacuousAction. The pass action is disabled for
vacuous success of the assertion

(e.g., as a result of control action).

- cbAssertionEnableNonvacuousAction. The pass action is enabled for
nonvacuous success of the

assertion (e.g., as a result of control action).

 

These callbacks are specific to a given assertion; placing such a
callback on one assertion does not cause the

callback to trigger on an event occurring on a different assertion. If
the callback is successfully placed, a

handle to the callback is returned. This handle can be used to remove
the callback via vpi_remove_cb(). If

there were errors on placing the callback, a NULL handle is returned. As
with all other calls, invoking this

function with invalid arguments has unpredictable effects.

 

In the above statement, why wouldn't you say it should be ignored,
versus unpredictable affects.

 

In 39.5.3 (coverage API),  do you agree that the coverable entities are
assertions that are not property and sequence instances?  

 

If I remember correctly,  "let" has been applied as an assertion too.
Do you agree that "let instances" should follow the same behavior as
sequence and property instances relative to all of the above?

 

Lisa

 

 

________________________________

From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com] 
Sent: Sunday, October 21, 2007 4:07 PM
To: Lisa Piper; Bassam Tabbara
Cc: sv-ac@eda-stds.org; sv-cc@eda-stds.org; john.havlicek@freescale.com
Subject: RE: VPI issues

 

Hi Lisa,

 

Comment on your question can be found below and yes 1503 is a good
mantis item to use, old proposal there can be deleted. Overall, the
proposal looks good and is mostly consistent with our cleanup discussion
-- thx for putting in the diagramming effort. The one change I do not
agree with is that of 38.4.2 which disallows CBs to seq/inst. As I
explained in some detail before you do need to get the result of
sequence/property inst, otw the data is lacking -- each inst has a
unique handle instance so there is no issue here.

 

Thx.

-Bassam.

 

 

________________________________

From: Lisa Piper [mailto:piper@cadence.com] 
Sent: Saturday, October 20, 2007 7:28 PM
To: Bassam Tabbara
Cc: sv-ac@eda-stds.org; sv-cc@eda-stds.org; john.havlicek@freescale.com
Subject: VPI issues

Hi Bassam,

I have drafted a proposal for the issues we have been discussing.  I
would like to push to get this approved for the 2008 release of the
standard.  I think it would be good to combine this with the existing
1503 since there is a lot of overlap.  The changes of 1503 are included
in the attached with the exception of the changes to the property spec.
Regarding the property spec, I question whether you need to make the
change (that is, add vpiArgument to the property inst box) since this is
shown in the property declaration diagram. 
[Bassam Tabbara] I don't think it's needed, should be on the definition
diagram really -- I had added there on the 1503 mini proposal to be
somewhat consistent with the sequence version. Actually, if you look at
36.48 you can see it's actually there is a weird way in 36.48 (that
iteration to "arguments" !). Not sure exactly what the policy should be
(I would think it needs to be on the *definition* diagram not on rest),
so will leave it up to CC to discuss and figure out exactly the cleanup
needed including 36.48.  And if it is needed, then I would think you
would also need it for the sequence expr, which can be a sequence
instance. 

I would appreciate if you could review the attached so we can jointly
get this to the point of being able to vote on it.  Review the top part
where I point out the things I'm not sure of.  I will be on the road
until Wednesday and may not be able to check email.

<<vpiIdentifier.doc>> 

Lisa

P.S. note that 1503 has not been updated to reflect draft 4 so it will
likely be easier to start from the attached


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.