There are several simulator and synthesis tools that use "memory" or "memories" in tool-generated messages involving one-dimensional arrays. If the term is removed from the LRM and not from software tools, user's will have no way to find out what these messages are referring to. I would be much more inclined to support removing the definition of what a "memory" is from the LRM if I thought that at least the EDA vendors who are active in the SV standards work would actually support removing the term from their tools. Maybe I'm just being pessimistic, but I don't think any vendor will. I would also support the CC committee deprecating VPI memory access, or at least adding it to the annex on items under consideration for deprecation. 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 Bresticker, Shalom > Sent: Thursday, April 26, 2007 1:36 AM > To: Warmke, Doug; Brad Pierce; sv-bc@server.eda.org > Subject: RE: [sv-bc] Ballot for proposed changes for 1800-2008 Draft 3 > > 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 > <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 Thu Apr 26 10:38:27 2007
This archive was generated by hypermail 2.1.8 : Thu Apr 26 2007 - 10:38:56 PDT