Re: [sv-ec] RE: Mantis 2506 BNF for coverpoint

Regards
Surya

Hillel,

 

When you are stating that coverpoint name is used in the with expression I presume you are satisfied with the functionality introduced by 2506? The coverpoint name may be reference to the left of the with, but item is used to refer to the value of the coverpoint name in the actual expression.  For example,

 

coverpoint a

{

  bins mod3[] = a with (item % 3 == 0);

}

 

The current LRM uses a self-determined type for the coverpoint expressions.  It isn’t a new idea.  The definition can be found in 6.23 and is “The type operator applied to an expression shall represent the self-determined result type of that expression. “

 

Thanks,

Scott

 

From: Miller Hillel-R53776 [mailto:r53776@freescale.com]
Sent: Tuesday, January 31, 2012 9:45 AM
To: Rich, Dave; Little, Scott; Bresticker, Shalom; 'Arturo.Salz@synopsys.com'; 'sv-ec@eda.org'
Subject: RE: Mantis 2506 BNF for coverpoint

 

Dave,

 

If the coverpoint identifier/name is used in the with expression it should have a datatype associated to it.

Is there precedence in the standard in using “self determined types”? How risky is this? Do we have a formal definition on how “self determination works”?

 

Thanks

Hillel

 

From: Rich, Dave [mailto:Dave_Rich@mentor.com]
Sent: Tuesday, January 31, 2012 11:32 AM
To: Miller Hillel-R53776; Little, Scott; Bresticker, Shalom; 'Arturo.Salz@synopsys.com'; 'sv-ec@eda.org'
Subject: RE: Mantis 2506 BNF for coverpoint

 

I don’t agree with that last statement, plus it is not backward compatible with existing semantics.  You only specify a data type if you want to cast the coverpoint expression to something different from its self-determined type.

 

Dave

Mentor Graphics

 

From: Miller Hillel-R53776 [mailto:r53776@freescale.com]
Sent: Tuesday, January 31, 2012 9:25 AM
To: Rich, Dave; Little, Scott; Bresticker, Shalom; 'Arturo.Salz@synopsys.com'; 'sv-ec@eda.org'
Cc: Miller Hillel-R53776
Subject: RE: Mantis 2506 BNF for coverpoint

 

Agree, also we should mention in this case it should have its datatype specified.

Thanks

Hillel

 

From: Rich, Dave [mailto:Dave_Rich@mentor.com]
Sent: Tuesday, January 31, 2012 11:22 AM
To: Miller Hillel-R53776; Little, Scott; Bresticker, Shalom; 'Arturo.Salz@synopsys.com'; 'sv-ec@eda.org'
Subject: RE: Mantis 2506 BNF for coverpoint

 

I think the problem you mention is more general to covergroup_expressions than anything specific to the 2506. It current says

 

A coverpoint coverage point creates a hierarchical scope and can be optionally labeled. If the label is

specified, then it designates the name of the coverage point. This name can be used to add this coverage

point to a cross coverage specification or to access the methods of the coverage point. If the label is omitted

and the coverage point is associated with a single variable, then the variable name becomes the name of the

coverage point. Otherwise, an implementation can generate a name for the coverage point only for the purposes

of coverage reporting, that is, generated names cannot be used within the language.

 

It should say that the label replaces the implicit name, and that a coverpoint name can be used inside a covergroup_expression.

 

 

Dave

Mentor Graphics

 

From: Miller Hillel-R53776 [mailto:r53776@freescale.com]
Sent: Tuesday, January 31, 2012 8:46 AM
To: Little, Scott; Bresticker, Shalom; Rich, Dave; 'Arturo.Salz@synopsys.com'; 'sv-ec@eda.org'
Subject: RE: Mantis 2506 BNF for coverpoint

 

Scott,

 

Where does it say we can use a cover_point_identifier in the with_covergroup_expression? This needs to be mentioned explicitly and explained.

 

Thanks

Hillel

 

From: Little, Scott [mailto:scott.little@intel.com]
Sent: Monday, January 30, 2012 10:54 AM
To: Miller Hillel-R53776; Bresticker, Shalom; 'Dave_Rich@mentor.com'; 'Arturo.Salz@synopsys.com'; 'sv-ec@eda.org'
Subject: RE: Mantis 2506 BNF for coverpoint

 

I apologize for my delayed responses.  I will try to answer a bunch of items here.

 

Why do we want a syntax to explicitly specify a data type?

As Hillel points out 2506 adds the ability to use the cover_point_identifier in the with_covergroup_expression.  Given the additional location where the coverpoint name may be used, we wanted to give users the ability to explicitly declare a type for the coverpoint to enhance clarity and ease of use.  I would argue that an explicit type is much easier to read than a type cast. If the user doesn’t want to specify the type it will be inferred (the only method possible in the 2009 LRM).

 

How should we fix the BNF issue?

If I go back to the changes between v1 and v2 (thanks for pointing me to the source of the change Shalom) I see that the original BNF was:

 

[ [ data_type_or_implicit ] cover_point_identifier : ] coverpoint

 

With the restriction that “If a data type is specified, then a cover_point_identifier shall also

be specified. “

 

I looked back at the minutes of the previous meeting (http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_February_14_2011_Minutes.txt).  It appears that this syntax was discussed, and I looked at it and changed the BNF to not require a cover_point_identifier as well as removing the restriction.  I do not recall why I decided to do this.  My current opinion is that we should revert to the BNF and restriction shown above. 

 

This is an example of why I find removing old proposals from mantis to be less effective.  I happen have the old copies around, but it would be nice to keep them in the public record.

 

What are the outstanding issues with 2506 in d4?

1.       page 551 line 47 (pg. 587 in the pdf) the bin should be two[2] instead of two[1].

2.       Clarify assignment compatible/casting behavior for with_covergroup_expression and set_covergroup_expression (footnote 25 and 19.5.1.2)

3.       BNF for coverpoint data type (and possibly additional restriction)

 

Thanks,

Scott

 

From: Miller Hillel-R53776 [mailto:r53776@freescale.com]
Sent: Sunday, January 29, 2012 5:00 PM
To: Bresticker, Shalom; 'Dave_Rich@mentor.com'; 'Arturo.Salz@synopsys.com'; Little, Scott; 'sv-ec@eda.org'
Subject: Re: Mantis 2506 BNF for coverpoint

 

Type declaration is desirable because coverpoint identifiers are used as variables within the "with" expression.
 

From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
Sent: Sunday, January 29, 2012 04:07 AM
To: Rich, Dave <Dave_Rich@mentor.com>; Arturo Salz <Arturo.Salz@synopsys.com>; Miller Hillel-R53776; Little, Scott <scott.little@intel.com>; sv-ec@eda.org <sv-ec@eda.org>
Subject: RE: Mantis 2506 BNF for coverpoint
 

I personally think that the type declaration form is more readable.

 

Regarding Hillel's comment, Scott Little's mail from February 18 contains the following:

 

-Removed restriction in the first new paragraph of 19.5 that a cover_point_identifier must be specified if a data type is specified and updated the grammar.

 

Regards,

Shalom

 

From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Rich, Dave
Sent: Saturday, January 28, 2012 6:17 AM
To: Arturo Salz; Miller Hillel-R53776; Little, Scott; sv-ec@eda.org
Subject: [sv-ec] RE: Mantis 2506 BNF for coverpoint

 

Right, a typedef would be needed in this case to get to a casting_type.

 

However, a simple integer can be used to size the cast of an integral expression, so you could do

 

d: coverpoint 8’(y[31:24])

 

Do anyone remember why the type declaration was desirable?

 

Dave

Mentor Graphics

 

From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
Sent: Friday, January 27, 2012 7:58 PM
To: Rich, Dave; Miller Hillel-R53776; Little, Scott; sv-ec@eda.org
Subject: RE: Mantis 2506 BNF for coverpoint

 

Dave,

 

The cast argument was the rationale I used for not requiring the type declaration. We did discuss this in the meeting and it was decided that the type declaration was desirable. Also, you’d probably have to declare the type as opposed to inlining the bit field as you have done below.

 

                Arturo

 

From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Rich, Dave
Sent: Friday, January 27, 2012 3:37 PM
To: Miller Hillel-R53776; Little, Scott; sv-ec@eda.org
Subject: [sv-ec] RE: Mantis 2506 BNF for coverpoint

 

Hillel,

 

I think we are all in agreement that the proposed BNF is wrong. This will need to become a ballot comment.

 

I’m not sure if the data is required. Why can’t you use a cast?

 

d: coverpoint bit [7:0]’( y[31:24]);              // creates coverpoint "d" covering …

 

 

Dave

Mentor Graphics

 

From: Miller Hillel-R53776 [mailto:r53776@freescale.com]
Sent: Friday, January 27, 2012 9:23 AM
To: Rich, Dave; Little, Scott; sv-ec@eda.org
Subject: RE: Mantis 2506 BNF for coverpoint

 

Rich,

 

I believe 2506 turns the coverpoint label into a typed variable, I don’t think we can call it a label anymore. Correct me if I have got this wrong.

 

Therefore if there is a data type there needs to be a variable identifier following it.

 

So: If there is a type it needs to be followed by a variable identifier.

 

Regards

Hillel

 

From: Rich, Dave [mailto:Dave_Rich@mentor.com]
Sent: Friday, January 27, 2012 11:14 AM
To: Miller Hillel-R53776; Little, Scott; sv-ec@eda.org
Subject: RE: Mantis 2506 BNF for coverpoint

 

Hillel,

 

The current BNF allows

 

bit [7:0] a&b  // no label

 

are you suggesting this?

 

cover_point ::=                                                                                      // from A.2.11

               [[data_type_or_implicit ] cover_point_identifier  : ] coverpoint expression [ iff ( expression ) ]

 

 

This means if you supply a data type, you must also supply a label

 

bit [7:0] ab : a&b

 

Dave

Mentor Graphics

 

From: Miller Hillel-R53776 [mailto:r53776@freescale.com]
Sent: Friday, January 27, 2012 9:01 AM
To: Little, Scott; Rich, Dave; sv-ec@eda.org
Subject: RE: Mantis 2506 BNF for coverpoint

 

It’s not consistent with p1800’s typed variable syntax. If we are to treat coverpoints as typed variables, let’s be consistent.

 

From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Little, Scott
Sent: Friday, January 27, 2012 10:53 AM
To: Rich, Dave; sv-ec@eda.org
Subject: [sv-ec] RE: Mantis 2506 BNF for coverpoint

 

Hi Dave,

 

Thanks.  This point has been raised to me as well as a couple of other fixes that are needed.

 

I would prefer to adjust the BNF to be consistent with the example as I believe that is a more intuitive way to write it.  Do you foresee any issues with that BNF change?

 

cover_point ::=                                                                                      // from A.2.11

              [ cover_point_identifier  : ] data_type_or_implicit  coverpoint expression [ iff ( expression ) ]

 

 

Thanks,

Scott

 

From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Rich, Dave
Sent: Friday, January 27, 2012 8:48 AM
To: sv-ec@eda.org
Subject: [sv-ec] Mantis 2506 BNF for coverpoint

 

While I’ve got your attention for mantis 2506,

 

The BNF for a coverpoint says

 

cover_point ::=                                                                                      // from A.2.11

              data_type_or_implicit [ cover_point_identifier  : ] coverpoint expression [ iff ( expression ) ]

 

 

Yet a later example has

 

d: bit [7:0] coverpoint y[31:24];              // creates coverpoint "d" covering …

 

Which is correct?

 

 

Dave Rich
Verification Technologist
Mentor Graphics Corporation

 

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

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

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