RE: [sv-ac] 1757 accept_on/reject_on proposal

Two additional comments:

1.	Table 16-25 shows the -> and <-> operators. I would show this
table in a way that is not dependent on that proposal.
2.	The terminology "reset expression" is used in reference to the
disable iff (see the second sentence after Table 16-25).   I struggled
to understand the intent of the sentence "There are seven kinds of
property: sequence, negation, disjunction, conjunction, if-else,
implication, and instantiation."  I think the intent was to state
constructs that cause an expression to be interpreted uniquely as a
property_expr versus a sequence_expr.   If this is true,  then disable
iff should also have been mentioned.  Where I am headed with this is
that I don't think the discussion on disable iff should be independent
of the discussion on accept_on, reject_on.  Add disable iff  to the "h)"
list and better integrate the discussion with disable iff.
3.	The reference to page 340 is actually 342 in draft3a
4.	The proposal states that the sampled value is used, and that
triggered can be used.  So does that mean that  
	"accept_on (triggered(seqA)" is actually interpreted as
"accept_on $sampled(triggered(seqA))" 
5.	There is a sentence in 16.13.6 (description of triggered) that
states:  "This method shall only be used in wait statements or boolean

expressions (see 9.4.4) outside of sequence context or in the disable
iff boolean expression for properties."  Perhaps change "disable iff" to
"a reset expression", depending on where they will all be "reset
expressions"

 

The dog is staring at me so I need to go!

 

Lisa

 

 

________________________________

From: Bustan, Doron [mailto:doron.bustan@intel.com] 
Sent: Sunday, September 23, 2007 5:05 AM
To: Lisa Piper; sv-ac@eda-stds.org
Subject: RE: [sv-ac] 1757 accept_on/reject_on proposal

 

Hi Lisa,

I made some changes according to the notes below.

 

1.      in 16.12, there is discussion of several kinds of properties.  I
am trying to relate this to the F.2.1 list.  F.2.1 does not list the
if-else and it references the "and" and "or" forms instead of
"conjunction" and "disjunction".  I'm not sure what the instantiation
means unless it is the parenthesized form. Should we use the same
terminology?  

[DB] That is a good question and we probably do something about it. But
since it is more then the accept_on reject_on issue, I would put it in
another mantis item. I did change the form to reset in annex F.

Also note the extra space in the new text "reset,   and instantiation"

[DB] fixed.

2.      "In particular, when reject_on ..."   ->  suggest dropping the
"in particular" since the statement before is not the same concept.

[DB] I disagree, the general clause talks about termination of the sub
property inside the accept_on, and the particular clause talks about
termination of the sub property inside the accept_on which happen to be
a reject_on.

3.      The paragraph above Annex F.3.6.1 that starts with "the operator
reject_on has the dual semantics." Needs to be reworded. Are you trying
to say:  "A word w satisfies property "reject_on(b) P" if and only if w
satisfies P before b is asserted. 

 

[DB] I made reject_on a derived operator (not accept_on (b) not P) and
removed this paragraph.

Doron

 

 

 

 

 

 

 

 

 

Lisa

---------------------------------------------------------------------
Intel Israel (74) Limited
 
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
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.