The SystemVerilog LRM changed the meaning of 'array'. By the way, I don't agree with the following introductory sentence from 7.2 -- "The term packed array is used to refer to the dimensions declared before the data identifier name. The term unpacked array is used to refer to the dimensions declared after the data identifier name." This says "packed array" where it apparently means "packed" and says "unpacked array" where it apparently means "unpacked". -- Brad -----Original Message----- From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] Sent: Wednesday, April 25, 2007 11:54 PM To: Brad Pierce; sv-bc@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.Received on Thu Apr 26 00:09:12 2007
This archive was generated by hypermail 2.1.8 : Thu Apr 26 2007 - 00:09:48 PDT