RE: [sv-bc] Ballot for proposed changes for 1800-2008 Draft 3

Comments on some of Stu's:

> > 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.

[SB] I think it looks silly to have both dated and non-dated references.
The references to 1800 are all to either:

1. previous versions, in which case the references in Clause 2 need to
be dated. That does not mean that the references in the text need to be
dated also,

OR

2. future versions, for which of course a listing in Clause 2 is not
relevant,

OR

3. the current document, in which case a listing in Clause 2 is also not
relevant.

Regarding references to 1364, the vast majority are dated. Of those that
are not, I saw some that need to be updated to internal references
within the same document. For others, it would be sufficient to add a
note saying that undated references refer to the 2005 version.


> > 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.

[SB] The comment includes the proposal to delete the entire sentence as
it adds nothing to the LRM as the term is not used elsewhere.


> > 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).

[SB] Did you mean to vote no?
The proposal was for the editor to create the wording.



> > SB1-11-2  yes ___ no _X_ abstain ___
> The description of the wording problem is not detailed enough for the
> editor
> (me) to implement.

[SB] The wording problem is that the sentence says that the operator
returns an expression, whereas it actually returns the value of an
expression.


> > SB1-21-1  yes ___ no _X_ abstain ___
> This is an enhancement request that needs to be a separate Mantis
> item.

[SB] Isn't this trivially obvious? 


> > 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.

[SB] This is updating 1364 text to 1800 as you have done in dozens of
places.


> > 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] Clause 33 (SDF) is closely related to Clauses 27-30 (Gate-level,
UDPs, Specify blocks, and Timing checks) whereas it has no connection to
31 and 32 (Configurations and Encryption).


> 
> > SB-O-8    yes _X_ no _X_ abstain ___
> This is a duplicate of SB1-10-2, of which I am also in favor.

[SB] They are not duplicates. SB1-10-2 proposes to move the subclause on
Assignment patterns into the clause on Structures and arrays, whereas
this comment proposes that the subclauses on Structure and array
literals should be unified with the subclause on Assignment patterns.
SB1-10-2 says nothing about the subclause on Structure and array
literals.

> > 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.

[SB] What about the note in 19.3.2?


> > 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.

[SB] MH-1 supercedes this.


> > 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.

[SB] Maybe, but the referenced 12.3.3 does not mention how
unique/priority do this. In addition. I also don't see how they reduce
the pessimism. They don't change the behavior of the case, just produce
warnings.


> > 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.

[SB] It is not a duplicate and the proposal contains the exact changes
needed. Remember, this is replacing text that you added, not text from
the original LRM.


> > 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".

[SB] That is indeed the proposal.

Shalom

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.