I think it remained in 1364-2001/2005 only because of PLI back-compatibility. We could have handled other references to memories, e.g., $readmem, without much trouble. It needs to be SV-CC's decision. Shalom ________________________________ From: Warmke, Doug [mailto:doug_warmke@mentor.com] Sent: Thursday, April 26, 2007 11:04 AM To: Bresticker, Shalom; Brad Pierce; sv-bc@server.eda.org Subject: RE: [sv-bc] Ballot for proposed changes for 1800-2008 Draft 3 Hello all, Personally I would like to take advantage of the merge to remove the concept of "memory" from the LRM. It is a perfect subset of unpacked fixed-size arrays. Such redundancy can only lead to confusion and reduce the LRM's integrity. There are implications in PLI, as well as other places in the LRM. Currently the SV-CC is working through some difficult issues with arrays. I think the idea of removing "memory" as a special kind of array wouldn't be too much additional work, and may even help them simplify their problem space. I think we could make this happen. Regards, Doug ________________________________ From: owner-sv-bc@server.eda.org on behalf of Bresticker, Shalom Sent: Wed 4/25/2007 11:54 PM To: Brad Pierce; sv-bc@server.eda.org Subject: RE: [sv-bc] Ballot for proposed changes for 1800-2008 Draft 3 1364-2005 has the following: 4.9.3 Memories A one-dimensional array with elements of type reg is also called a memory. These memories can be used to model read-only memories (ROMs), random access memories (RAMs), and reg files. Each reg in the array is known as an element or word and is addressed by a single array index. An n-bit reg can be assigned a value in a single assignment, but a complete memory cannot. To assign a value to a memory word, an index shall be specified. The index can be an expression. This option provides a mechanism to reference different memory words, depending on the value of other variables and nets in the circuit. For example, a program counter reg could be used to index into a RAM. 4.9.3.1 Array examples 4.9.3.1.1 Array declarations reg [7:0] mema[0:255]; // declares a memory mema of 256 8-bit // registers. The indices are 0 to 255 Shalom > -----Original Message----- > From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] > On Behalf Of Brad Pierce > Sent: Thursday, April 26, 2007 9:50 AM > To: sv-bc@server.eda.org > Subject: Re: [sv-bc] Ballot for proposed changes for 1800-2008 Draft 3 > > 7.2.4 in the draft under review begins > > "A one-dimensional array with elements of types reg, logic or bit > is > also called a memory." > > In SystemVerilog this would include > > logic M[1024]; > > but not > > reg [15:0] M[1024]; > > -- Brad > > -----Original Message----- > From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] > Sent: Wednesday, April 25, 2007 11:38 PM > To: Brad Pierce; sv-bc@eda.org > Subject: RE: [sv-bc] Ballot for proposed changes for 1800-2008 Draft 3 > > Stu meant there is one unpacked dimension. > He did not say there are no packed dimensions. > > So this: > > > reg [15:0] M[1024]; > > is and always has been a memory. > > I don't know about this: > > > Is the following a memory? > > > > reg [3:0] [3:0] M[1024]; > > Verilog never had anything like this, so memories never related to it. > > Shalom > > > -----Original Message----- > > From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] > > On Behalf Of Brad Pierce > > Sent: Thursday, April 26, 2007 9:26 AM > > To: sv-bc@server.eda.org > > Subject: RE: [sv-bc] Ballot for proposed changes for 1800-2008 Draft > 3 > > > > Stu writes -- > > > > >> BP1-7-1 yes ___ no _X_ abstain ___ > > >I disagree with the suggested change. This subclause is > specifically > > > >defining a "memory" as a one-dimensional unpacked array. There is > no > > > >"fastest varying unpacked dimension". An array with multiple > > unpacked > > >dimensions is not a memory, and referring to one as such would > break > > the VPI > > >definitions of memories and arrays. > > > > Yet the sentence in question is -- > > > > "Each packed dimension in the array is known as a memory element > or > > word" > > > > If there's only one dimension, then why is it talking about 'each > > packed dimension'? And how could a dimension, let alone each packed > > dimension, be an element? And why isn't the following a memory? > > > > reg [15:0] M[1024]; > > > > It is an array with one unpacked dimension, but it is a two- > > dimensional array. > > > > Is the following a memory? > > > > reg [3:0] [3:0] M[1024]; > > > > -- Brad > > > > -----Original Message----- > > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of > > Stuart Sutherland > > Sent: Tuesday, April 24, 2007 11:47 PM > > To: sv-bc@eda.org > > Subject: RE: [sv-bc] Ballot for proposed changes for 1800-2008 Draft > 3 > > > > Matt, > > > > Here's my votes. > > > > I am traveling the morning of the conference call to discuss the > > voting. > > I should be able to call in for the first 30 minutes of the call. > > > > Stu > > ~~~~~~~~~~~~~~~~~~~~~~~~~ > > Stuart Sutherland > > Sutherland HDL, Inc. > > stuart@sutherland-hdl.com > > 503-692-0898 > > > > > > > SB1-1-1 yes _X_ no ___ abstain ___ > > > SB1-1-2 yes _X_ no ___ abstain ___ > > > SB1-1-3 yes _X_ no ___ abstain ___ > > > SB1-1-4 yes _X_ no ___ abstain ___ > > > SB1-1-5 yes _X_ no ___ abstain ___ > > > SB1-2-1 yes ___ no _X_ abstain ___ > > There are many references in the LRM to "1364" and "1800" without a > > specific year. Either these references need to be changed to > > "1364-2005" or "1800-2005", or the definition of "IEEE 1364" and > "IEEE > > > 1800" should be left in. Most references to "1364" and "1800" can > > have a year added, but some may need to stay generic; specifically > > 1.7, 5.5.2, 21.12 (multiple places), C.2.1, C.2.2, I.12, I.12.1 > > (multiple places). I will change my vote to yes if the committee > > decides that all references to "1364" and "1800" have a specific > > version added. > > > > > SB1-3-1 yes ___ no _X_ abstain ___ > > I have no problems with the current wording, and no new wording is > > recommended. I will change my vote to yes of specific wording > changes > > > are recommended. > > > > > SB1-3-2 yes _X_ no ___ abstain ___ > > > SB1-3-3 yes _X_ no ___ abstain ___ > > A question is raised as to whether "config" should be listed as a > > design unit, but no recommendation given. I will change my vote to > > yes if the committee agrees to remove "config", or for a description > > of config to be added to clause 3 (saying editor is to create the > > wording is OK). > > > > > SB1-5-1 yes _X_ no ___ abstain ___ > > > SB1-5-2 yes _X_ no ___ abstain ___ > > > SB1-5-3 yes ___ no _X_ abstain ___ > > I think the discussion of time values makes more sense where it is > > than in clause 4. > > > > > SB1-5-4 yes _X_ no ___ abstain ___ > > > SB1-5-5 yes _X_ no ___ abstain ___ > > > SB1-5-6 yes _X_ no ___ abstain ___ > > > SB1-6-1 yes _X_ no ___ abstain ___ > > > SB1-6-2 yes _X_ no ___ abstain ___ > > > SB1-6-3 yes _X_ no ___ abstain ___ > > The suggestion is: "6.14 and 7.6 both describe strings. Merge them > > ***or*** have only a two-sentence paragraph in 6.14". I do not > > approve of removing 6.14. I do approve of I approve of having a > > two-sentence paragraph in 6.14 with a forward reference to 7.6. > > > > > SB1-7-1 yes _X_ no ___ abstain ___ > > > SB1-7-2 yes _X_ no ___ abstain ___ > > > SB1-10-1 yes ___ no _X_ abstain ___ > > This needs to be a separate mantis item that goes through the full > > discussion, voting, and approval process. > > > > > SB1-10-2 yes _X_ no ___ abstain ___ > > > SB1-11-1 yes ___ no _X_ abstain ___ > > I think a more correct fix is to change the term "procedural > > assignment operators" in 10.3 and 10.3.1 to "assignment operators", > so > > > as to match the description of these operators in 11.2.7 and A.6.3. > > > > > SB1-11-2 yes ___ no _X_ abstain ___ > > The description of the wording problem is not detailed enough for > the > > editor > > (me) to implement. > > > > > SB1-11-3 yes ___ no _X_ abstain ___ > > This is an open mantis item (#1004), and needs to be addressed using > > the standard discussion, voting and approval method. > > > > > SB1-11-4 yes _X_ no ___ abstain ___ > > > SB1-12-1 yes _X_ no ___ abstain ___ > > > SB1-16-1 yes _X_ no ___ abstain ___ > > > SB1-19-1 yes _X_ no ___ abstain ___ > > > SB1-19-2 yes ___ no _X_ abstain ___ > > This is an alleged errata in 1364-2005, and should be addressed as a > > separate Mantis item. > > > > > SB1-20-1 yes _X_ no ___ abstain ___ > > > SB1-20-2 yes _X_ no ___ abstain ___ > > > SB1-21-1 yes ___ no _X_ abstain ___ > > This is an enhancement request that needs to be a separate Mantis > > item. > > > > > SB1-21-2 yes ___ no _X_ abstain ___ > > This is a change to a definition in 1364-2005. It should be a > > separate Mantis item for discussion, voting and approval. > > > > > SB1-21-3 yes _X_ no ___ abstain ___ > > > SB1-22-1 yes _X_ no ___ abstain ___ > > > SB1-22-2 yes _X_ no ___ abstain ___ > > > SB1-22-3 yes _X_ no ___ abstain ___ > > > SB1-22-4 yes ___ no _X_ abstain ___ > > I agree with the principle of the change, but this is a definition > > that does not exist in either 1364-2005 or 1800-2005. It needs to > be > > a separate Mantis item with discussion, voting and approval. > > > > > SB1-25-1 yes _X_ no ___ abstain ___ > > > SB1-25-2 yes _X_ no ___ abstain ___ > > > SB1-25-3 yes _X_ no ___ abstain ___ > > > SB1-27-1 yes _X_ no ___ abstain ___ > > > SB1-33-1 yes ___ no ___ abstain _X_ > > I think the current order of clauses 30-33 is fine, but will change > > order if the committee approves. > > > > > SB-O-1 yes ___ no _X_ abstain ___ > > This needs committee discussion on what the correction should be. > > Make > > it a > > separate Mantis item. > > > > > SB-O-2 yes ___ no _X_ abstain ___ > > This needs committee discussion on what the correction should be. > > Make > > it a > > separate Mantis item. > > > > > SB-O-3 yes ___ no _X_ abstain ___ > > This needs committee discussion on what the correction should be. > > Make > > it a > > separate Mantis item. > > > > > SB-O-4 yes ___ no _X_ abstain ___ > > I think the current split on string literal topics is correct. 5.9 > > discusses string literal syntax in the same clause with other > > literals. > > 11.6.1 discusses operations on string literals in the same clause on > > operations on other types of data. > > > > > SB-O-5 yes ___ no _X_ abstain ___ > > Moving the discussion on string literals and string types closer > > together because they are related would only move other closely > > related topics further apart. This is one of those cases where > there > > is no perfect solution to how to group topics. I prefer to keep > > string literals with other literals and string arrays with other > > arrays. > > > > > SB-O-6 yes ___ no _X_ abstain ___ > > This needs committee discussion on what the correction should be. > > Make > > it a > > separate Mantis item. > > > > > SB-O-7 yes ___ no _X_ abstain ___ > > This needs committee discussion on what the correction should be. > > Make > > it a > > separate Mantis item. > > > > > SB-O-8 yes _X_ no _X_ abstain ___ > > This is a duplicate of SB1-10-2, of which I am also in favor. > > > > > SB-O-9 yes ___ no _X_ abstain ___ > > This needs committee discussion on what the correction should be. > > Make > > it a > > separate Mantis item. > > > > > SB-O-10 yes ___ no _X_ abstain ___ > > I think this should be left as-is. > > > > > SB-O-11 yes ___ no _X_ abstain ___ > > Discussion on this should be turned over to the SV-CC committee. > > > > > SB2-6-9-1 yes _X_ no ___ abstain ___ > > > > > > > BP1-5-1 yes ___ no _X_ abstain ___ > > The note in 5.8 should remain deleted. It is redundant with the > same > > note in 5.7. The Greek letter has already been corrected for draft > 3. > > > > > BP1-5-2 yes _X_ no ___ abstain ___ > > > BP1-5-3 yes ___ no _X_ abstain ___ > > This would be changing a definition in 1800-2005. It is also part > of > > a larger issue that has been raised on consistent usage of "data > type" > > and > > "data object" throughout the LRM, and should be dealt with in a > Mantis > > > item on that topic. > > > > > BP1-5-4 yes ___ no _X_ abstain ___ > > This is part of a larger issue that has been raised on consistent > > usage of "data type" and "data object" throughout the LRM, and > should > > be dealt with in a Mantis item on that topic. > > > > > BP1-5-5 yes ___ no _X_ abstain ___ > > This is part of a larger issue that has been raised on consistent > > usage of "data type" and "data object" throughout the LRM, and > should > > be dealt with in a Mantis item on that topic. > > > > > BP1-5-6 yes _X_ no ___ abstain ___ > > > BP1-5-7 yes ___ no _X_ abstain ___ > > This is part of a larger issue that has been raised on consistent > > usage of "data type" and "data object" throughout the LRM, and > should > > be dealt with in a Mantis item on that topic. > > > > > BP1-5-8 yes ___ no _X_ abstain ___ > > This is part of a larger issue that has been raised on consistent > > usage of "data type" and "data object" throughout the LRM, and > should > > be dealt with in a Mantis item on that topic. > > > > > BP1-6-1 yes _X_ no ___ abstain ___ > > > BP1-6-2 yes ___ no ___ abstain _X_ > > I will go along with what the committee decides. > > > > > BP1-6-3 yes _X_ no ___ abstain ___ > > > BP1-6-4 yes _X_ no ___ abstain ___ > > > BP1-6-5 yes ___ no _X_ abstain ___ > > This is already covered in Mantis 507, and is scheduled to be > > corrected in draft 3. > > > > > BP1-6-6 yes ___ no ___ abstain _X_ > > I will go with what the committee decides regarding removal of the > > editor question, but personally I do not think this is an > appropriate > > usage of an informative note. I think this note should either be > > deleted or be made part of the preceding paragraph. > > > > > BP1-7-1 yes ___ no _X_ abstain ___ > > I disagree with the suggested change. This subclause is > specifically > > defining a "memory" as a one-dimensional unpacked array. There is > no > > "fastest varying unpacked dimension". An array with multiple > unpacked > > > dimensions is not a memory, and referring to one as such would break > > the VPI definitions of memories and arrays. > > > > > BP1-7-2 yes _X_ no ___ abstain ___ > > > BP1-7-3 yes _X_ no ___ abstain ___ > > > BP1-7-4 yes ___ no _X_ abstain ___ > > I disagree with removing the paragraph. An introduction paragraph > and > > > general definition of a structure is needed. If the text is not > > correct, then a proposal on correct wording should be made, > discussed, > > > and voted on. > > > > > BP1-8-1 yes _X_ no ___ abstain ___ > > > BP1-9-1 yes _X_ no ___ abstain ___ > > > BP1-9-2 yes _X_ no ___ abstain ___ > > > BP1-9-3 yes _X_ no ___ abstain ___ > > > BP1-9-4 yes _X_ no ___ abstain ___ > > > BP1-10-1 yes _X_ no ___ abstain ___ > > > BP1-10-2 yes _X_ no ___ abstain ___ > > > BP1-10-3 yes _X_ no ___ abstain ___ > > > BP1-11-1 yes _X_ no ___ abstain ___ > > > BP1-12-1 yes ___ no ___ abstain _X_ > > I will go along with the committee decision. I think it is helpful, > > but not essential, to mention that a default branch is not the only > > way to catch x/z values in the case expression. > > > > > BP1-12-2 yes _X_ no ___ abstain ___ > > > BP1-12-3 yes _X_ no ___ abstain ___ > > > BP1-12-4 yes _X_ no ___ abstain ___ > > > BP1-12-5 yes _X_ no ___ abstain ___ > > > BP1-13-1 yes _X_ no ___ abstain ___ > > > BP1-13-2 yes _X_ no ___ abstain ___ > > > BP1-13-3 yes _X_ no ___ abstain ___ > > > BP1-13-4 yes _X_ no ___ abstain ___ > > > BP1-13-5 yes _X_ no ___ abstain ___ > > > BP1-13-6 yes _X_ no ___ abstain ___ > > > BP1-13-7 yes _X_ no ___ abstain ___ > > > BP1-22-1 yes _X_ no ___ abstain ___ > > > BP1-22-2 yes _X_ no ___ abstain ___ > > > BP1-22-3 yes _X_ no ___ abstain ___ > > > BP1-22-4 yes _X_ no ___ abstain ___ > > > BP1-22-5 yes _X_ no ___ abstain ___ > > > BP1-A-1 yes _X_ no ___ abstain ___ > > > MH-1 yes ___ no _X_ abstain ___ > > This is a duplicate of BP1-7-4. A Mantis item should be created > with > > a proposal for the exact changes needed. > > > > > MH-2 yes ___ no _X_ abstain ___ > > A Mantis item should be created with a proposal for the exact > changes > > needed (one Mantis item could cover both MH-1 and MH-2). > > > > > MH-3 yes _X_ no ___ abstain ___ > > I approve based on the assumption that the requested change is to > > delete the words "Verilog syntax for" instead of the currently > deleted > > > "Verilog syntax". > > > > > HC-D-1 yes _X_ no ___ abstain ___ > > > HC-D-2 yes _X_ no ___ abstain ___ > > > HC-E-1 yes _X_ no ___ abstain ___ > > > HC-O-1 yes _X_ no ___ abstain ___ > > > HC-O-2 yes _X_ no ___ abstain ___ > > > HC-O-3 yes _X_ no ___ abstain ___ > > > HC-O-4 yes _X_ no ___ abstain ___ > > > HC-O-5 yes _X_ no ___ abstain ___ > > > HC-O-6 yes _X_ no ___ abstain ___ > > > HC-O-7 yes _X_ no ___ abstain ___ > > > > Most of Heath's issues were about formatting. The note at the > > beginning of these annexes already states that formatting still > needs > > to be done. > > No > > review or voting on this type of issue was needed. > > > > > > > > > > > > -- > > 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. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Apr 26 01:36:48 2007
This archive was generated by hypermail 2.1.8 : Thu Apr 26 2007 - 01:36:57 PDT