RE: [sv-ac] uploaded updated proposals for 1361

Hi Lisa,

 

Thanks for the detailed feedback. My comments are included:

 

________________________________

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Lisa
Piper
Sent: Monday, June 04, 2007 8:21 PM
To: Kulshrestha, Manisha; sv-ac@eda-stds.org
Subject: RE: [sv-ac] uploaded updated proposals for 1361

Hi Manisha,

 

The proposal looks good overall but I do have some comments and
questions:

 

1. 16.3 on Immediate assertions also has a paragraph on action blocks
(immediately below Syntax 16-1)   The note for 16.14.1 should apply here
too so it is clear these apply to both immediate and concurrent
assertions.  I assume that is the intent, though I don't think that
vacuous applies to immediates.

OK, I'll take care of this in the proposal.

 

2. 1460 added the action block to the assume statement so 16.14.2 will
have a similar statement.

OK, I'll take care of this in the proposal.

 

3. this will impact the 1768 proposal for adding "cover sequence" as
there are a couple references to the action blocks in it. Depending on
which one is approved first, we'll have to edit one or the other.

I'll add a note about this in the proposal.

 

4. In 19.12, there is no default behavior described and I don't
understand what this means:  "These system tasks shall not affect the
execution of pass or fail actions until the task is executed."   

 

This is the default behavior. This means that the execution of the
action blocks will happen the way it happens now unless one of these
tasks is executed. Do you suggest any better wording for this ?

 

5.      Isn't $assertpasson really enabling it for both vacuous and
non-vacuous successes, whereas $assertnonvacuouson enables execution for
nonvacuous only.  This should be stated explicitely.

Yes it does. Will new wording like "$assertpasson shall enable execution
of pass action for vacuous and nonvacuous success for all the specified
assertions." Be better ? Any suggestions ?

 

6.      why is it $assertnonvacuouson and $assertvacuousoff    We have
passon/passoff  and failon/failoff.  The switch from vacuous to
nonvacuous seems like an error.

 

Earlier we had $assertvacuouson and $assertvacuousoff. But Doron
objected to that during last ballot (and ballot was not approved due to
his objection). He wanted to rename the functions such that there is no
way a user can switch on execution of action blocks only for vacuous
successes. 

 

7.      I assume that when there are two calls, the last one wins. If
the HDL gives a command and the VPI gives and opposing command, the last
one wins.

 

Yes.

 

8.      In 19.1, there is a reference to assertion control tasks.  I
assume there should be a similar one for assertion action control tasks.

 

OK, I'll update that.

 

9.      in 38.4.2, add a reference to the section that describes the
"control action" to reference 38.5.2 so it is clear that the callback
only occurs as a result of vpi controls and not as a result of
assert_action_control_tasks (to be consistent with others, which is not
to say that I agree with this).

 

10.  on the previous point, why are call backs limited to control
actions. I obviously don't have much experience with how they are used.
I would think if I were trying to debug why an assertion was becoming
disabled, I would want to set the callback and have it react to anything
that might disable it. (This question applies to this and to 1599)

 

I think Bassam has already answered 9 and 10.

 

Lisa

 

 

 

 

________________________________

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Kulshrestha, Manisha
Sent: Saturday, June 02, 2007 1:06 PM
To: sv-ac@eda-stds.org
Subject: [sv-ac] uploaded updated proposals for 1361

 

Hi,

 

I have aligned the proposal to draft3. Also, I have uploaded Word docs
(2007 and 2003 versions) along with pdf file as pdf file is not perfect.
I think this proposal is ready to be voted in sv-ac. Also, probably we
need to send it to sv-cc as it has some API changes.

 

Thanks.

Manisha


-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 
-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 


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