Tom, ________________________________ From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Alsop, Thomas R Sent: Friday, September 28, 2007 10:29 AM To: Maidment, Matthew R; sv-bc@server.eda.org Subject: RE: [sv-bc] E-mal Vote: Respond by 8am PDT, Sunday Sep 30, 2007 My votes below. I do have an issue with 907. I would like to ask for clarification of the following sentence "If a parameter of a design element has no default value, then the design element shall not be implicitly instantiated (see 22.3, 22.4, and 23.3)" My request is to not redirect the reader to these 3 huge clauses so they can understand the sentence. I think what I see missing in the proposal was an explanation of what happens when the call doesn't have a parameter value _and_ tne declaration doesn't assign a default. I think this sentence is attempting to explain this but can we make put this in more laymen's terms? I'd like to see something like "If a default is not assigned in the declaration and no value is provided in the call, an error shall be issued". I think the assumption being that when default values are not in the declaration, the call must provide them. Correct me if I am wrong:-) [DR] The point was that you shouldn't have to remove modules that were never called (instantiated is the proper term) from your design. The concepts of which modules are in your design vary from tool to tool anyways. Also, the LRM is not a user manual. Although it needs to be as clear as we can make it, we should not be repeating definitions of functionality because they have a habit of getting out of sync when updates and enhancements are made. On 1468, I move that we use Shalom's friendly change. The wording will be "The always_latch procedure is almost identical to the always_comb procedure. All statements in 9.2.2.2 shall apply to always_latch as well. The exception is that software tools may perform additional checks to warn if the behavior in an always_latch procedure does not represent latched logic, whereas in an always_comb procedure, they may check and warn if the behavior does not represent combinational logic." [DR] "almost identical" is a phrase up there with "jumbo shrimp" and "military intelligence" Why don't we just say "The always_latch construct is identical to the always_comb construct except that software tools may perform additional checks and warn if the behavior in an always_latch construct does not represent latched logic, whereas in an always_comb construct, they may check and warn if the behavior does not represent combinational logic." -Tom -----Original Message----- From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Maidment, Matthew R Sent: Thursday, September 27, 2007 9:28 AM To: sv-bc@server.eda.org Subject: RE: [sv-bc] E-mal Vote: Respond by 8am PDT, Sunday Sep 30, 2007 Just a reminder to please respond. We need at least half of the voters to respond, otherwise we will review and vote on each issue during Monday's meeting. -- Matt Maidment mmaidmen@ichips.intel.com [Alsop, Thomas R] >-----Original Message----- >From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On >Behalf Of Maidment, Matthew R >Sent: Friday, September 21, 2007 12:53 PM >To: sv-bc@eda.org >Subject: [sv-bc] E-mal Vote: Respond by 8am PDT, Sunday Sep 30, 2007 > > >-You have until 8am PDT, Sunday, September 30, 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 September 17, 2007 meeting, the eligible voters are: > >Brad Pierce >Shalom Bresticker >Cliff Cummings >Surrendra Dudani >Mark Hartoog >Francoise Martinolle >Karen Pieper >Dave Rich >Steven Sharp >Gordon Vreugdenhil >Stu Sutherland >Alex Gran >Don Mills >Heath Chambers >Tom Alsop > >SVDB 699 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=699 > >SVDB 907 ___Yes _X_No >http://www.eda.org/svdb/view.php?id=907 > >SVDB 1035 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=1035 > >SVDB 1228 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=1228 > >SVDB 1425 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=1425 > >SVDB 1468 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=1468 > >SVDB 1710 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=1710 > >SVDB 1747 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=1747 > >SVDB 1846 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=1846 > >SVDB 1940 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=1940 > >SVDB 1949 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=1949 > >-- >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 <http://www.mailscanner.info/> , 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 Sep 28 12:06:08 2007
This archive was generated by hypermail 2.1.8 : Fri Sep 28 2007 - 12:06:40 PDT