[sv-ac] RE: 1599 review

Hi Lisa, comments below.
 
Thx.
-Bassam.
 

________________________________

From: Lisa Piper [mailto:piper@cadence.com] 
Sent: Friday, June 01, 2007 1:41 PM
To: john.havlicek@freescale.com; Bassam Tabbara
Cc: sv-ac@eda.org
Subject: 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.
[Bassam Tabbara] This section is talking about coverage for properties
and the history of this (805) meant to emphasize that disabled is not an
interesting / tracked state here and does not get folded into one of the
other counts except for attempt hence the wording and why killed
(applies to assertion attempt) is not mentioned. Disabled evaluation is
described elsewhere (with reference back to 16.12). 

If you have some particular text in mind please share. 

2.      in 39.5.3, there is no definition and example of the
vipAssertKillCovered. 
[Bassam Tabbara] Good point, thx. Added and updated the proposal. 

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.  
[Bassam Tabbara] No. The disable/enable are control actions (vpi_control
or corresponding system task), they are not evaluation results (aka
state of being). This is the on/off with legacy enable/disable different
naming in API.

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.   
[Bassam Tabbara] It's the CB section for the VPI control tasks.

 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). 
[Bassam Tabbara]  They should be yes and all can be explained, if you
keep in mind 2 things:
a) The naming of system task/VPI API while similar does not necessarily
mean they are same. In fact, we already know it's not (e.g. enable/on,
disable/off)
b) Moreover the control facilities are not necessarily one-to-one. The
VPI API is more detailed than the assertion tasks which group some
useful functions (on/off/kill) in a useful sense i.e. group all of
"system" (all assertions) or scope of, or individual ones under same
umbrella call.

The vpiAssertionKill kills an *attempt* not the assertion (i.e. set of
attempts) note how it takes a start_time as additional argument ? The
$assertkill (assertionhere argument) should be mapped to the
vpiAssertionReset + vpiAssertionDisable, note that $assertkill without
args would correspond to vpiAssertionSysKill and have a
cbAssertionSysKill. 

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)
[Bassam Tabbara]  As I mention above, you should get cbAssertionReset
and cbAssertionDisable. The cbAssertionKill is for individual attempts,
no system task has that capability.

** BTW: Of course would've been nice if we had 1-1 CBs to the tasks, but
the history is that the CBs were designed for API, and the tasks got
created later ... no reason to add more CBs really.

** Please note: The "kill" result in the proposal is meant to cover what
the VPI section says is "discarded" (whether under kill/reset) ... I
found one issue to correct now that we have this "kill" result -- added
as last item in proposal.

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.
[Bassam Tabbara] It's a good goal, we should think how best to present
the info -- I think a set of tables is best, a state diagram would be
overly populated and too confusing, better to break up concerns as in
cb/control/result -- much like the sections do but may be a summary
table would help organize more.

Lisa


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