[sv-ac] 1599 review

	Hi Bassam and John,

	I re-reviewed this and still have comments, but I think my
comments may be going beyond the intent of this proposal which was to
incorporate 805 related changes.  We might want to create a different
proposal to address #4 below.  I think comment #1 and #2 need to be
addressed in this proposal  and then it is ready for vote.    #3 and #4
need to be addressed but perhaps in a separate proposal.

1.	In 16.14.3, why wouldn't we also add the disabled evaluation
counter?  Once you specify a vpi to count it,  you might as well have it
here too.
2.	in 39.5.3, there is no definition and example of the
vipAssertKillCovered. 
3.	in 38.4.2, the cbAssertionDisable states that the "assertion is
disabled" (e.g. as a result of a control action, ...)    Should this be
"assertion reaches the disabled state" like the ones above.  Same
applies to the other control action callbacks.  
4.	Now I am confused!  I looked at the link to control action
(38.5.2) and see the vpi assertion control actions.  I always thought
this referenced the $asserton/off/kill of section 19.10.   In fact, the
vpiAssertionKill is not the same definition as $assertkill.  $assertkill
(and vpiAssertionSysKill also) disables all subsequent attempts while
vpiAssertionKill only kills the one in progress but leaves it enabled.
I would think all of these would have a consistent definition and that
all forms of assertion control (38.5.1, 38.5.2, and 19.10)  would impact
the assertion states/counters consistently. Another disconnect is that
the vipAssertionKill also says that it does not reset the state used by
the assertion, whereas other descriptions presumably do (since this is
not mentioned). Also, if I do an assertkill, I know that I should get a
callback on the cbAssertionKill, but it is not clear if I should also
get one on cbAssertionDisable.  I would think yes assuming that
assertions are disabled after a kill, but I'm not sure that would be
desired. (this assumes that assertions are disabled after a kill)


My view is that there should be a set of states that are defined for an
assertion attempt.  Create a bubble diagram that shows all state
transitions possible, including all 3 types of control mechanisms as
well as normal assertion evaluation progress.  For each state, define
the state of variables (default initial or current value), and what
counters get incremented on the transition to the state,  

1.	initial: 
2.	active:  enabled but has not reached another state
3.	vacuous
4.	success
5.	disabled 
6.	off
7.	killed
8.	reset 

Then it becomes easy to clearly define all the controls consistently,
and it becomes clear what the differences are (e.g. is reset state
different from killed state, does a system kill do the same as a VPI
assertion kill as a VPI system kill).  It is difficult to determine.
This clarity will help ensure consistency across tools.  I would also
like to show scheduling implications on this diagram if possible.

Lisa


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