RE: [sv-ac] Updated proposal for Mantis - restrict property statement

Hi Ed,
 
I extracted the text you can just use this as replace/with ....
Details:

1) Clocking event is always the actual clocking event on which the
assertion is being evaluated, regardless of whether

this is explicit or implicit (inferred).

** Lisa makes a good point -- if the construct has no tracked data then
let's not put under 36.42 which embodies the assertion API (also
coverage) of 38, and no changes in 38/39. So only keep under concurrent
assertion of 36.43 to access construct itself.
 
Thx.
-Bassam.
 

________________________________

From: Eduard Cerny 
Sent: Wednesday, February 06, 2008 6:00 AM
To: Bassam Tabbara; Eduard Cerny; sv-ac@eda.org
Subject: RE: [sv-ac] Updated proposal for Mantis - restrict property
statement


Hello Bassam,
 
I agree, but it seem sto me that the Detail is part of the figure. No?
Do you have the original figure?
 
Thanks,
ed

________________________________

From: Bassam Tabbara [mailto:bassamt@synopsys.COM] 
Sent: Tuesday, February 05, 2008 5:30 PM
To: Eduard Cerny; sv-ac@eda.org
Subject: RE: [sv-ac] Updated proposal for Mantis - restrict property
statement


Hi Ed,
 
For VPI change to 36.43 I think we need a "Detail" note since the "stmt"
arrow applies to whole class -- easier to discount the one than add
arrows to all.
 
Thx.
-Bassam.
 

________________________________

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Eduard Cerny
Sent: Tuesday, February 05, 2008 2:22 PM
To: sv-ac@eda.org
Subject: [sv-ac] Updated proposal for Mantis - restrict property
statement


Hi, please find attached and also on Mantis, an updated proposal for the
restrict property assertion statement, aligned with Draft 4. 
I did not have the source for the vpi diagrams hence I just pointed to
the required change there. If someone has an editable form I would
update the figure too.
Let me know if you find any other issues. 
Best regards,
ed
 

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