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.