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.