Re: [sv-ec] transition coverpoints and iff

From: Neil Korpusik <neil.korpusik@oracle.com>
Date: Fri Sep 06 2013 - 14:25:18 PDT
<forwarding bounced email>


-------- Original Message --------

Date: Fri, 06 Sep 2013 14:42:45 +0200
From: Daniel Mlynek <danielm@aldec.com>
To: "Tipp, Brandon P" <brandon.p.tipp@intel.com>
CC: "Rich, Dave" <Dave_Rich@mentor.com>, Daniel Mlynek 
<danielm@aldec.com.pl>,
         "sv-ec@eda.org" <sv-ec@eda.org>
Subject: Re: [sv-ec] transition coverpoints and iff

I've reported
http://www.verilog.org/mantis/view.php?id=4735


W dniu 9/5/2013 5:49 PM, Tipp, Brandon P pisze:
>
> I agree with Daniel that for coverage points containing transition
> bins the LRM is at best ambiguous and at worst self-contradictory.  I
> interpret “ignored” to mean that no sample occurred, but I also
> interpret “disables” to mean that the transition sequence is killed.
> I think that a Mantis item should be filed to clarify this.
>
> Both of those interpretations contradict the handling of an iff
> condition on an individual transition bin.  From 19.5.1 of the LRM:
>
> “The expression within the *iff *construct at the end of a bin
> definition provides a per-bin guard condition. If
>
> the expression is false at a sampling point, the count for the bin is
> not incremented.”
>
> That implies that for a transition bin, the iff construct will only be
> evaluated at the end of the transition sequence to determine if the
> count of the bin is incremented.  Is that is the intention? I would
> prefer it if the iff condition on a coverpoint would act exactly as if
> the same iff condition were placed on each bin of the coverpoint.
>
> -Brandon
>
> *From:*owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] *On Behalf Of
> *Rich, Dave
> *Sent:* Thursday, September 05, 2013 8:20 AM
> *To:* Daniel Mlynek; sv-ec@eda.org
> *Subject:* RE: [sv-ec] transition coverpoints and iff
>
> “The expression within the *iff *construct specifies an optional
> condition that disables coverage for that *coverpoint*.
>
> If the guard expression evaluates to false at a sampling point, the
> coverage point is ignored.”
>
> I interpret “ignored” to mean as if no sample() had occurred: 1)
>
> You are perceptive to point out that the behavior of a reset should
> really be similar to that of a property’s disable construct. But I
> would prefer to keep transition bins simple and leave anything more
> complex to a cover directive.
>
> Dave
>
> Mentor Graphics**
>
> *From:*owner-sv-ec@eda.org <mailto:owner-sv-ec@eda.org>
> [mailto:owner-sv-ec@eda.org] *On Behalf Of *Daniel Mlynek
> *Sent:* Thursday, September 05, 2013 6:11 AM
> *To:* sv-ec@eda.org <mailto:sv-ec@eda.org>
> *Subject:* [sv-ec] transition coverpoints and iff
>
> LRM do not explains for iff should behave for transition coverpoints.
> I see at least 2 options - when iff condition is false at the moment
> of sampling:
> 1. skip this sample
> 2. kill whole transition sequence
> There could be also 3rd possibility that iff is async but it rather
> wont be compatybily with other covergroup features.
>
> Am I missing the description of this feature?
> How it should work?
> Should I report mantis on that?
>
> Consider example should "b" be covered or not (for 1st solution it
> should be for 2nd it should not)
>
> module top;
>     int i,i1,i2,i3,i4,i5;
>     bit r;
>     covergroup CG;
>         type_option.merge_instances = 1;
>         coverpoint i4 iff(!r){
>             bins b = (1=>2=>3);
>         }
>     endgroup
>      CG cg = new;
>      initial begin
>         i4=0;r=0;
>          #1;cg.sample;#1;
>         i4=1;r=0;
>          #1;cg.sample;#1;
>         i4=10;r=1;//here iff condition is tunred off
>          #1;cg.sample;#1;
>         i4=2;r=0;
>          #1;cg.sample;#1;
>         i4=3;r=0;
>          #1;cg.sample;#1;
>     end
> endmodule
>
>
> DANiel
>
> --
> 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.
Received on Fri Sep 6 14:25:37 2013

This archive was generated by hypermail 2.1.8 : Fri Sep 06 2013 - 14:25:51 PDT