Matt, please change my vote to "yes" on 329 based on the P1800_port_decls_proposal_D4-aligned_v3.pdf proposal that Stu just uploaded. So I now have "no" remaining on only 1571 and 2184. Thanks. Gord. Gordon Vreugdenhil wrote: > Matt, I added 2217 at the end in this response. > > I have several no votes -- 329, 1571, 1957, and 2184. > See reasons below. > > I voted yes on 1338 and 1619 but suggested a minor change > in each. My yes votes on those stand with or without the > suggested changes. > > I think my "no" vote concerns can be addressed quickly and > if so, I would be willing to re-cast my votes on those > rather than spend meeting time. > > > Maidment, Matthew R wrote: >> -You have until 8am PST, Monday, December 3, 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 November 12, 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 >> Doug Warmke >> Mike Burns >> >> SVDB 329 ___Yes _X__No http://www.eda.org/svdb/view.php?id=329 > > > The BNF in 329 is not quite right. Instead of: > > [ package_import_declaration ] [ parameter_port_list ] list_of_ports ; > > it should be: > > { package_import_declaration } [ parameter_port_list ] list_of_ports ; > ^^^ ^^^ > in each of the productions. The package_import_declaration production > is a single "import ...;" declaration and we want to allow a list > of them (as in fact the examples use). > > With that change my vote would become "yes". > > >> SVDB 1338 _X_Yes ___No http://www.eda.org/svdb/view.php?id=1338 > > Yes on 1338 (the V5 proposal) but I would suggest a friendly amendment. > > The sentence: > A string literal embedded inside a macro will not replace macro > arguments > or embedded macros within that string. > seems a bit awkward. How about: > Macros and macro arguments within a string literal shall > not be replaced when the string literal occurs within macro text. > > In any case the "will not" should become "shall not". > > My "yes" stands even without the change, but I think a bit of > word-smithing would help here. > > >> SVDB 1339 _X_Yes ___No >> http://www.eda.org/svdb/view.php?id=1339 > >> SVDB 1548 _X_Yes ___No >> http://www.eda.org/svdb/view.php?id=1548 >> >> SVDB 1571 ___Yes _X_No http://www.eda.org/svdb/view.php?id=1571 > > See comments below on 1957 -- I think there is an > incorrect interaction between 1571 and 1957 that > needs to be corrected on one of the two sides. > >> SVDB 1619 _X_Yes ___No >> http://www.eda.org/svdb/view.php?id=1619 > > Suggested friendly amendment -- please change: > parameter logic [7:0] My_DataIn = 8’hFF; > to: > localparam logic [7:0] My_DataIn = 8’hFF; > when used in the $unit scope. > > "parameter" is legal and equivalent to "localparam" > but I really don't like seeing "parameter" used everywhere > like that. > >> SVDB 1957 ___Yes _X_No http://www.eda.org/svdb/view.php?id=1957 > > The 1571 proposal has the following: > `define MACRO2(a=5, b, c="C") $display(a,,b,,c); > `MACRO2 (1, , 3) // ILLEGAL: b omitted, no default > But my reading of 1957 is that "b" should just be empty > here and not illegal. > > What is the intent of 1957 and 1571? Do different rules > apply for macros in which any formal has a default? If so > the example above is Ok but the rule needs to be much more > clearly stated. > > I think that 1571 might intend to say that if an argument > for a formal with a default is omitted, the default is used > and then ALL subsequent omitted arguments must have defaults. > If that is the intent then 1957 and 1571 are Ok together > except for the above example which would be legal. > > > Sorry for the late "no" on this -- I had focussed on the > "blue" text in 1571 previously and it wasn't until I looked > at 1957 separately that I became a bit confused on this point. > > >> SVDB 2102 _X_Yes ___No http://www.eda.org/svdb/view.php?id=2102 >> >> SVDB 2106 _X_Yes ___No http://www.eda.org/svdb/view.php?id=2106 >> >> SVDB 2152 _X_Yes ___No http://www.eda.org/svdb/view.php?id=2152 > > (Yes here is to close as covered by 2097) > >> SVDB 2163 _X_Yes ___No http://www.eda.org/svdb/view.php?id=2163 >> >> SVDB 2169 _X_Yes ___No http://www.eda.org/svdb/view.php?id=2169 >> >> SVDB 2170 _X_Yes ___No http://www.eda.org/svdb/view.php?id=2170 >> >> SVDB 2178 _X_Yes ___No http://www.eda.org/svdb/view.php?id=2178 > >> SVDB 2184 ___Yes _X_No http://www.eda.org/svdb/view.php?id=2184 > > 2184 is bit misleading. The paragraph being changed > starts with: > Constant system function calls are calls to certain > built-in system functions where the arguments are > constant expressions. > > The data/array query routines ($bits, etc) are then > added to the list of routines. But those routines > can be constant even when their arguments are not. > > I'd prefer these routines to be broken out with a > statement similar to the following: > Enables of the data query system functions described in 19.6 and the > array query system functions described in 19.7 are normally > constant expressions even when their arguments are not constant. > See those sections for the conditions under which such enables > are considered to be constant expressions. > > > > SVDB 2217 _X_Yes ___No > > http://www.eda.org/svdb/view.php?id=2217 > > > Gord. > -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Nov 28 22:10:56 2007
This archive was generated by hypermail 2.1.8 : Wed Nov 28 2007 - 22:11:09 PST