[sv-ec] FW: Question about coverpoint bin specification

From: Bresticker, Shalom <shalom.bresticker@intel.com>
Date: Thu Aug 14 2014 - 04:18:38 PDT
Comments, please.

Thanks,
Shalom

From: Bresticker, Shalom
Sent: Thursday, August 14, 2014 10:31
To: Bresticker, Shalom
Subject: FW: Question about coverpoint bin specification

From: Bresticker, Shalom
Sent: Thursday, April 11, 2013 12:29 AM
To: Little, Scott; Molina, Olga
Cc: DTS CCT-E Lira Developers
Subject: RE: Question about coverpoint bin specification

Hi, Scott.

Usually, the grammar does not work that way.

Usually, if you get "( expression )", then you decide where to go in the grammar, and only afterwards do you decide whether it is legal.

It would be better to differentiate between the two types of expression in the grammar itself.
One way to do that would be to specify in a footnote that a trans_list may not be composed of a single covergroup_expression.

In any case, the LRM is currently ambiguous what to do in this case.

Regards,
Shalom

From: Little, Scott
Sent: Wednesday, April 10, 2013 18:25
To: Bresticker, Shalom; Molina, Olga
Cc: DTS CCT-E Lira Developers
Subject: RE: Question about coverpoint bin specification

I agree with Shalom.  The snippet below cannot qualify as a set_covergroup_expression.  In 19.5.1.2 the LRM specifies that a set_covergroup_expression must yield an array.

Regarding how to disambiguate a trans_list from a set_covergroup_expression, there is some ambiguity in the grammar.  Both a set_covergroup_expression and a trans_list may legally be a covergroup_expression.  I do believe it is disambiguated by the LRM text.  Below are rules for what is allowable based on text in the LRM outside of the grammar.

1.       A set_covergroup_expression is an array yielding expression whose element type is compatible with the coverpoint type.

2.       A trans_list specifies one or more sets of ordered value transitions.  I don't see how a single array can stand as a trans_list given this requirement as a single array can't specify a transition.

Shalom, do you agree?  Olga, does this help solve your problem?

Thanks,
Scott

From: Bresticker, Shalom
Sent: Wednesday, April 10, 2013 4:11 AM
To: Molina, Olga
Cc: DTS CCT-E Lira Developers; Little, Scott
Subject: RE: Question about coverpoint bin specification

I believe that your question is that (0) could be interpreted as a set_covergroup_expression (::= expression).

Yes, that appears to be an ambiguity in the LRM.

However, I think the intent is that the outer parentheses mark it as a transition bin.

Besides that, in order to be a legal set_covergroup_bin, it needs to be an array, and "0" is not an array.

If there were an array inside the parentheses, then the ambiguity would be greater.

Scott, what do you think?

Regards,
Shalom

From: Molina, Olga
Sent: Tuesday, April 09, 2013 15:39
To: Bresticker, Shalom
Cc: DTS CCT-E Lira Developers
Subject: Question about coverpoint bin specification

Hi Shalom,

I have a question about coverpoint bins.
In LRM (section 19.5.2) the syntax for specifying transition bins is:
bins_or_options ::=
coverage_option
| [ wildcard ] bins_keyword bin_identifier [ [ [ covergroup_expression ] ] ] =
{ covergroup_range_list } [ with ( with_covergroup_expression ) ]
[ iff ( expression ) ]
| [ wildcard ] bins_keyword bin_identifier [ [ [ covergroup_expression ] ] ] =
cover_point_identifier with ( with_covergroup_expression ) ] [ iff ( expression ) ]
| [ wildcard ] bins_keyword bin_identifier [ [ [ covergroup_expression ] ] ] =
set_covergroup_expression [ iff ( expression ) ]
| [ wildcard] bins_keyword bin_identifier [ [ ] ] = trans_list [ iff ( expression ) ]
Also LRM says:
Transition bin specifications of length 0 shall be illegal. These are transition bin specifications containing a
trans_set production of a single covergroup_value_range, e.g., (0) or ([0:1]), or a single
covergroup_value_range with a repeat_range evaluating to 1, e.g., (0[*1]) or ([0:1][*1]).

Consider following example:

covergroup sg @(posedge clk);
a: coverpoint x
{
    bins b = (0);
}
endgroup

Is b should be illegal transition bin (rule  [ wildcard] bins_keyword bin_identifier [ [ ] ] = trans_list [ iff ( expression ) ] )
or a legal state bin (rule : [ wildcard ] bins_keyword bin_identifier [ [ [ covergroup_expression ] ] ] = set_covergroup_expression [ iff ( expression ) ] )

It seems like LRM are not well defines this case, could you please clarify what should be a correct behavior?

Thank you in advance,
                Olga.
---------------------------------------------------------------------
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, and is
believed to be clean.
Received on Thu Aug 14 04:19:21 2014

This archive was generated by hypermail 2.1.8 : Thu Aug 14 2014 - 04:19:36 PDT