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.