Re: [sv-ac] 1768 review

Hi Bassam:

> Again, the semantics of such syntax is not defined for sequence --
> disable iff is at top level only so the production you have effectively
> says: cover sequence (property_spec).
> 
> Now, I thought the proposal intent was to distinguish the
> property_spec/sequence_expr confusion (see motivation), and merely add a
> cover sequence syntax for the old cover property (sequence_expr), hence
> my #2 below. If there is more to it, then this needs to be
> clarified/defined and/or new syntax introduced.

My understanding of the proposal and Lisa's comments is that there is 
something new, namely the ability to add the "disable iff" to the 
"cover sequence" directive and still have all match semantics.

I think that this is a good thing for the reasons that Lisa cited.
This "disable iff" is still top level -- it is attached at the 
"cover sequence" directive level and cannot be embedded within the 
sequence_expr.

For the semantics, I think it is intuitively clear that each
sub-attempt of a sequence_expr that completes its match without the
occurrence of the "disable iff" condition should count towards the
all match total for that attempt.  Any sub-attempt that is in progress
and not yet complete at the occurrence of the "disable iff" condition
should be aborted.

Lisa, can you add some language like this to the proposal that
describes the way the "disable iff" behaves together with all match 
coverage?

By the way, I think that this is not really a new semantic concept.
I think that we have the same semantic question of how "disable iff" 
interacts with an all match evaluation of a sequence_expr under the 
existing LRM.  For example, we can write a sequence_expr S that has 
been instrumented with $display match items at the ends of various 
subexpressions and ask which $displays execute for an attempt of

   assert property (disable iff (blah) S |-> 1'b1);

A precise definition of the semantics could be derived by a resolution
of Mantis 0921.

J.H.

> X-Authentication-Warning: server.eda-stds.org: majordom set sender to owner-sv-ac@eda.org using -f
> x-mimeole: Produced By Microsoft Exchange V6.5
> Content-class: urn:content-classes:message
> Date: Wed, 4 Jul 2007 00:05:19 -0700
> Thread-Topic: [sv-ac] 1768 review
> Thread-Index: Ace7/tvvRp2OS1iRQaaXh+QgQIDg1AB7b54AAAFrPvUAAAjtQAADvXMg
> From: "Bassam Tabbara" <Bassam.Tabbara@synopsys.com>
> X-OriginalArrivalTime: 04 Jul 2007 07:05:20.0544 (UTC) FILETIME=[AF1FFA00:01C7BE09]
> X-eda.org-MailScanner: Found to be clean, Found to be clean
> X-Spam-Status: No, No
> X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda-stds.org id l6475XtM016515
> Sender: owner-sv-ac@eda.org
> X-eda.org-MailScanner-Information: Please contact the ISP for more information
> X-eda.org-MailScanner-From: owner-sv-ac@server.eda.org
> 
> Hi Lisa,
> 
> Again, the semantics of such syntax is not defined for sequence --
> disable iff is at top level only so the production you have effectively
> says: cover sequence (property_spec).
> 
> Now, I thought the proposal intent was to distinguish the
> property_spec/sequence_expr confusion (see motivation), and merely add a
> cover sequence syntax for the old cover property (sequence_expr), hence
> my #2 below. If there is more to it, then this needs to be
> clarified/defined and/or new syntax introduced.
> 
> Thx.
> -Bassam.
> 
> -----Original Message-----
> From: Lisa Piper [mailto:piper@cadence.com] 
> Sent: Tuesday, July 03, 2007 9:24 PM
> To: Bassam Tabbara; sv-ac@eda-stds.org
> Subject: RE: [sv-ac] 1768 review
> 
> Hi Bassam,
> 
> The real difference between cover property and cover sequence is whether
> the first match or all match semantics is used.  As it turns out, the
> all match semantics only makes sense for sequences, hense cover
> sequence.  But it is still desireable to not count some cases, such as
> reset. 
> 
> I agree that disable iff goes with property_spec and not sequence_expr,
> which is why it needed to be added to the syntax.
> 
> lisa
> 
> -----Original Message-----
> From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com]
> Sent: Wednesday, July 04, 2007 12:18 AM
> To: Lisa Piper; Bassam.tabbara@synopsys.com; sv-ac@eda-stds.org
> Subject: Re: [sv-ac] 1768 review
> 
> Hi Lisa, 
> 
> To be more specific, what I was getting at is that a disable iff goes
> with property_spec and not a sequence_expr currently. Same reasoning in
> LRM would apply here for cover sequence, leaving the disable at property
> level with cover property.
> 
> THX. 
> -Bassam
> 
> -----Original Message-----
> From: Lisa Piper <piper@cadence.com>
> To: Bassam Tabbara <Bassam.Tabbara@synopsys.COM>; sv-ac@eda-stds.org
> <sv-ac@eda-stds.org>
> Sent: Tue Jul 03 20:47:14 2007
> Subject: RE: [sv-ac] 1768 review
> 
> Hi Bassam,
> 
> Thanks for the comments. I agree with all except #2. There may be times
> when you don't want to report coverage of a sequence, such as during
> reset. I think it applies.
> 
> I have uploaded a revised copy of 1768 to Mantis, attached for
> convenience.
> 
> Lisa
> 
> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> Bassam Tabbara
> Sent: Sunday, July 01, 2007 12:43 PM
> To: sv-ac@eda-stds.org
> Subject: [sv-ac] 1768 review
> 
> Hi Lisa,
>  
> Here's my feedback:
> 
> 1) Syntax 16-16
> 
> Change "Cover_.... :=" to "cover_..."
> 
> 2) "disable iff" does not make sense in above production since this is a
> *sequence*
> 
> 3) ditto on (1)/(2) for A.6.10
> 
> 4) 16.14.3 change "e.g. cover property" to "i.e. cover property"
> 
> 5) For 16.14.3 see (2) above and update
> 
> 6) Last sentence "Whether cover property or cover sequence is used is
> dependent on whether one match or multiple match semantics is desired."
> 
> Change to 
> 
> "Whether cover property or
> cover sequence is used depends on whether one match or multiple match
> semantics is desired respectively.
> 
>  
> Thx.
> -Bassam.
> 
> --
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
> 
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> 

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