Hi Stu, I'd like to respond to your no-vote on 907 Please read on. Thanks, Doug -----Original Message----- From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Stuart Sutherland Sent: Friday, October 12, 2007 2:38 PM To: 'Maidment, Matthew R'; sv-bc@server.eda.org Subject: RE: [sv-bc] E-mail Ballot: Respond by Oct 14, 2007 8am PDT I figured I had missed the deadline due to my travel schedule, so I did not vote. If not too late, here's my votes... > > SVDB 907 ___Yes _X_No > http://www.eda.org/svdb/view.php?id=907 I vote NO for four primary reasons. 1) I do not feel this enhancement adds any value to the language. Are any real end-users of SystemVerilog asking for this? Does the enhancement add anything to the language that cannot be done already? DOUG: Yes, real users have asked for this. The main point is that this is a way to enforce a "mandatory parameter override". Sometimes there is simply no good default. The author of a design unit wants to obligate the client to specify the parameter. This is the way to achieve that modeling goal. This kind of facility exists in class-based design in SystemVerilog already, with pure virtual functions. In C++, template parameters are not required to have defaults. This also obligates client code to specify a parameter value that makes sense for it. Now that SV TB's are here, Object Oriented design is in the language. The kind of design and modeling enabled by features like mandatory parameter overrides are more prevalent in the O-O world than in the RTL world. 2) this enhancement may have some impact on the VPI, which expects all paramters to have a type and value. Has the CC committee reviewed this proposal? DOUG: I checked with my colleague, Abi Moorhouse, of SV-CC. The impact on VPI is minimal - not trivial, but certainly one of the less complex challenges facing the SV-CC. In general there is a large part of VPI that is moving towards a post-elab information model. After elaboration, all parameters *must* have received values. These defaultless parameters will have received values from overrides of some sort, not their default (since they have no default). The end effect is the same: any parameter VPI visits will have a value. 3) I feel the difference between parameter redefinition affecting a single instance and all instances is too subtle, and too easy for users to get behavior they were not expected. This latter concern could be addressed by requiring parameters without a default value to be declared as "static", similar to a static class property. DOUG: I don't follow this point. I don't believe anyone is proposing a "mass parameter override" feature. Just a "mandatory parameter override" for all instances. I think this might be a reflection of the confusion that others have pointed out in the proposal's text. Here is Dave Rich's suggested rewording of the paragraph in the proposal that starts with "In the declaration of a parameter...". (I made a slight grammatical modification) I attached an amended proposal to 907 with this wording. It has the revision number "3" in its filename. In the declaration of a parameter in a parameter_port_list, the specification for its default value may be omitted, in which case the parameter shall have no default value. If no default value is specified for a parameter of a design element, then an overriding parameter value shall be specified in every instantiation of that design element (see 22.9). Also, if no default value is specified for a parameter of a design element, then a tool shall not implicitly instantiate that design element (see 22.3, 22.4, and 23.3). If no default value is specified for a parameter of a class, then an overriding parameter value shall be specified in every specialization of that class (see 8.24). For convenience, here is a link to Issue 907: http://www.eda-stds.org/svdb/view.php?id=907 <http://www.eda-stds.org/svdb/view.php?id=907> And here is a link to Dave's email with the proposed rewording: http://www.eda-stds.org/sv-bc/hm/6867.html <http://www.eda-stds.org/sv-bc/hm/6867.html> 4) I object to the last change in the proposal that "the parameter keyword shall be a synonym for the localparam keyword". I never understood why Verilog had this restriction on not being able to redefine parameters and would rather see that restriction removed. Even if not removed, I would prefer simplay stating that these parameters cannot be redefined, rather than saying those parameters are localparams. DOUG: This text you quoted and its effect is already in the LRM. See the last paragraph of Clause 6.3.2 in IEEE 1800-2005. Also, 6.20.1 in 1800-2005 already specifies this behavior. Mantis 907 is just rewording it for consistency with 6.3.2. If you don't like the automatic conversion of parameters to localparams in certain contexts, I think that is a subject for a different Mantis. This Mantis is just rewording that existing behavior. Thanks and regards, Doug > > SVDB 1134 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=1134 > > SVDB 1294 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=1294 > > SVDB 1348 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=1348 I am voting yes, but the addition "A statement label on a for or foreach loop names the implicit block created by the for or foreach loop." raises a question... Does a label before a for or foreach loop now allow hierarchical reference to the loop variables? For example, in: loop: for (int i=0; i<= 15; i++) ... Can "i" be referenced hierarchically with "loop.i" at the end of the path? If so, is this stated anywhere in the LRM? > > SVDB 1464 _X_Yes _X_No > http://www.eda.org/svdb/view.php?id=1464 > > SVDB 1468 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=1468 > > SVDB 1588 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=1588 > > SVDB 1619 ___Yes _X_No > http://www.eda.org/svdb/view.php?id=1619 I vote no for the followign reasons: 1) The new wording in 22.3.2.3 on .name seem awkward. Why does the "purpose" of default values need to be explained here? Any purpose and usage should be described where the construct is defined, not where it is used. 2) Also in 22.3.2.3, the new wording is not clear on if .name will infer an unnconnected port if the port name is not listed, or if an unconnected port is only inferred if explicitly listed as unconnected (e.g. using ".in_port()"). I feel strongly that unconnected ports with .name and .* should only be inferred if explicitly shown as unconnected, but I am aware of at least two tools that do not require this. 3) I re-read the new paragraph being added to 22.3.2.4 on .* several times, and still cannot figure out what it is trying to define as rules. Everytime I read the paragraph I come up with a different interpretation. This paragraph needs to be rewritten, perhaps with a dashed-list of succinctly stated rules. > > SVDB 1792 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=1792 > > SVDB 1940 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=1940 > > SVDB 2024 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=2024 > > SVDB 2056 _X_Yes ___No > http://www.eda.org/svdb/view.php?id=2056 > Stu ~~~~~~~~~~~~~~~~~~~~~~~~~ Stuart Sutherland Sutherland HDL, Inc. stuart@sutherland-hdl.com 503-692-0898 > -----Original Message----- > From: owner-sv-bc@server.eda.org > [mailto:owner-sv-bc@server.eda.org] On Behalf Of Maidment, Matthew R > Sent: Friday, October 12, 2007 1:17 PM > To: sv-bc@server.eda.org > Subject: RE: [sv-bc] E-mail Ballot: Respond by Oct 14, 2007 8am PDT > > I have responses from: > > Gord, Brad, Karen, Heath, Don, Tom > > We need at least one more response to make this vote official. > Please respond if you have not done so already. > > Matt > -- > Matt Maidment > mmaidmen@ichips.intel.com > > > >-----Original Message----- > >From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On > >Behalf Of Maidment, Matthew R > >Sent: Thursday, October 04, 2007 1:30 PM > >To: sv-bc@eda.org > >Subject: [sv-bc] E-mail Ballot: Respond by Oct 14, 2007 8am PDT > > > > > >-You have until 8am PDT, Sunday, October 14, 2007 to respond > >-An issue passes if there are zero NO votes and half of the eligible > > voters respond with a YES vote. > >-If you vote NO on any issue, your vote must be accompanied by > >a reason. > > The issue will then be up for discussion during a future conference > >call. > >-Note: For some issues, the proposed action is captured in > the bug note > > (resolve as duplicate, already addressed, etc.). > > > >As of the October 1, 2007 meeting, the eligible voters are: > > > >Brad Pierce > >Shalom Bresticker > >Cliff Cummings > >Mark Hartoog > >Francoise Martinolle > >Karen Pieper > >Dave Rich > >Steven Sharp > >Gordon Vreugdenhil > >Stu Sutherland > >Alex Gran > >Don Mills > >Heath Chambers > >Tom Alsop > > > > > >SVDB 907 ___Yes ___No > >http://www.eda.org/svdb/view.php?id=907 > > > >SVDB 1134 ___Yes ___No > >http://www.eda.org/svdb/view.php?id=1134 > > > >SVDB 1294 ___Yes ___No > >http://www.eda.org/svdb/view.php?id=1294 > > > >SVDB 1348 ___Yes ___No > >http://www.eda.org/svdb/view.php?id=1348 > > > >SVDB 1464 ___Yes ___No > >http://www.eda.org/svdb/view.php?id=1464 > > > >SVDB 1468 ___Yes ___No > >http://www.eda.org/svdb/view.php?id=1468 > > > >SVDB 1588 ___Yes ___No > >http://www.eda.org/svdb/view.php?id=1588 > > > >SVDB 1619 ___Yes ___No > >http://www.eda.org/svdb/view.php?id=1619 > > > >SVDB 1792 ___Yes ___No > >http://www.eda.org/svdb/view.php?id=1792 > > > >SVDB 1940 ___Yes ___No > >http://www.eda.org/svdb/view.php?id=1940 > > > >SVDB 2024 ___Yes ___No > >http://www.eda.org/svdb/view.php?id=2024 > > > >SVDB 2056 ___Yes ___No > >http://www.eda.org/svdb/view.php?id=2056 > > > >-- > >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.Received on Fri Oct 12 21:45:50 2007
This archive was generated by hypermail 2.1.8 : Fri Oct 12 2007 - 21:46:04 PDT