Date: Sat Jun 16 2012 - 23:39:56 PDT
Hi Jim,
We should distinguish between the keywords and the names of procedures. For example, always (in Courier 9) procedures mean always, but not always_ff, always_comb, etc. Is it your intent?
There are many such examples in the LRM.
P. 12: "It cannot contain always procedures, primitive instances, module instances, interface instances, or other program instances."
P. 13: "In addition to subroutine methods, an interface can also contain processes (i.e., initial or always procedures) and continuous assignments, which are useful for system-level modeling and testbench applications."
and many others.
Thanks,
Dmitry
From: Jim Vellenga [mailto:vellenga@cadence.com]
Sent: Friday, June 15, 2012 16:38
To: Korchemny, Dmitry
Cc: sv-xc@eda.org
Subject: RE: Email Ballot due Monday June 18th
Dimitry,
In the proposal for 3127, the keywords were deliberately set in Boldface constant-width font in accordance with "1.6 Syntactic description" and with the text copied from "D.8 $reset, $reset_count, and $reset_value."
Regards,
Jim Vellenga
From: owner-sv-xc@eda.org<mailto:owner-sv-xc@eda.org> [mailto:owner-sv-xc@eda.org]<mailto:[mailto:owner-sv-xc@eda.org]> On Behalf Of Korchemny, Dmitry
Sent: Friday, 15 Jun 2012 5:03 AM
To: Rich, Dave; sv-xc@eda.org<mailto:sv-xc@eda.org>
Subject: RE: Email Ballot due Monday June 18th
Hi Dave,
Here are my votes.
Thanks,
Dmitry
3525: Abstain
This proposal introduces one backward incompatibility. The following property declaration:
property p;
if (a) b else c
endproperty
becomes illegal though it was legal.
The only legal way to write it now is:
property p;
if (a) b else c;
endproperty
I am fine with this change, but if one wants to preserve the backward incompatibility then one more change is required in the BNF:
property_spec ::=
[clocking_event ] [ disable iff ( expression_or_dist ) ] property_expr
| if ( expression_or_dist ) property_expr [ else property_expr ]
4045 Yes
Minor note: in the preamble it is written: "... the LRM says explicitly twice in the text that a checker may contain a nested checker declaration (in 17.2 and 3.11) ...", but I could not find this statement in 3.11.
3968 Yes
3505 Yes
4126 Yes
4146 No
Should also be mentioned new definition of assertion sampling and enhancements in assertions and checkers
4145 Yes
3127 Yes
Friendly amendment: '"initial" and "always" procedures' should be typeset as a normal text (Time New Roman 10).
4120 Yes
4127 No
The suggested syntax
bit [7:0] d: coverpoint y[31:24];
does not look natural to me. If there is such a precedent in the LRM I change my vote to Abstain.
3710 Yes
3982 Yes
3065 Yes
2840 Yes
4138 Yes
Friendly amendment: fix fonts (not very essential since the wrongly typeset text is being deleted).
4129 No
There should be an explanation or a note in the text what integer_expression means, similar to the explanation about integer_covergroup_expression.
Friendly amendments:
* "Proposal" statement with CHANGE .. TO in the preamble is misleading and may lead to a confusion. I suggest to delete it from there.
* The added terminals '(' and ')' should be in red, and not in blue.
3298 Yes
Why is "inlined" spelled as "in-lined" in the proposal and in the LRM (18.7.1)?
From: owner-sv-xc@eda.org<mailto:owner-sv-xc@eda.org> [mailto:owner-sv-xc@eda.org]<mailto:[mailto:owner-sv-xc@eda.org]> On Behalf Of Rich, Dave
Sent: Tuesday, June 12, 2012 11:00
To: sv-xc@eda.org<mailto:sv-xc@eda.org>
Subject: {Disarmed} Email Ballot due Monday June 18th
The following is a list of ballot items up for a one week e-mail vote due June 18th. All members present at either the May 21st or June 11th meetings are eligible to vote.
A "No" vote must include a recommended course of action to change your vote to a "yes". That action could be a fix for the proposal, or a different response to the item, ,i.e. that we leave it alone.
Any issue with at least one "no" vote will not pass and will go up for the next e-mail vote, or will be discussed in the next meeting. Proposal owners are encouraged to modify their proposal to address "no" votes as soon as possible so that others may change their vote to a "yes"
EDA.org Mantis - SystemVerilog P1800
ID<view_all_set.php?sort=id&dir=ASC&type=2&print=1>
Summary<view_all_set.php?sort=summary&dir=ASC&type=2&print=1>
0003525<view.php?id=3525>
2012 Ballot comment 41: property_statement should not be part of property_expr
0004045<view.php?id=4045>
2012 Ballot comment 43: checker_declaration BNF does not allow nested checker declaration
0003968<view.php?id=3968>
2012 Ballot comment 38: sequence_formal_type includes redundant 'event'
0003505<view.php?id=3505>
2012 Ballot comment 60: $ missing from param_expression
0004126<view.php?id=4126>
2012 Ballot comments 34, 35: allow for-loop initialization, step, termination statements to be null
0004146<view.php?id=4146>
2012 Ballot comment 10: confusing definitions on p2
0004145<view.php?id=4145>
2012 Ballot comment 13. What does "variation" mean in 23.11
0003127<view.php?id=3127>
2012 Ballot comment 57: cbStartOfReset and cbEndOfReset callbacks are not documented
0004120<view.php?id=4120>
2012 Ballot comments 21,27: mistake in 6.6.8 code example of generic interconnect from 0003724<view.php?id=3724>
0004127<view.php?id=4127>
2012 Ballot comments 23, 48: difference between BNF and example whether data_type appears before or after cover_point_identifier
0003710<view.php?id=3710>
2012 Ballot comment 32: Example may work wrong, negative values may be generated while positive expected when using $random %
0003982<view.php?id=3982>
2012 Ballot comment 36: clocking_decl_assign allows expression or just hierachical_identifier
0003065<view.php?id=3065>
2012 Ballot comment 59: Peculiar BNF for hierarchical_btf_identifier
0002840<view.php?id=2840>
2012 Ballot comment 28: Virtual interface datatype BNF incomplete
0004138<view.php?id=4138>
2012 Ballot comment 53: cross type compatibility inconsistency
0004129<view.php?id=4129>
2012 Ballot comment 50: Need to clarify ambiguous binding of matches operator
0003298<view.php?id=3298>
2012 Ballot comment 24: Use of 'this' in a coverpoint expression
Dave Rich
Verification Technologist
Mentor Graphics Corporation
[Description: Description: Twitter-32]<http://www.twitter.com/dave_59>[Description: Description: Technorati-32]<http://go.mentor.com/drich>
-- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, 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<http://www.mailscanner.info/>, 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.
