RE: [sv-bc] e-mail ballot: respond by Dec 3, 8am PST

Stu,

1339 - has been updated.  This changes your vote to a yes. (I just saw
your update, thanks)

1338 - I'll follow up on Shalom's comment later today, but I appreciate
your suggestions and will fix the proposal.

1619 - I will work on this later today as well.  I hope everyone here
has a built in resilience to newbies, my wordsmithing skills will
improve over time as I become more intimate with the language of the
LRM.   "Placeholders" did not make any sense to me since it means that
it will be replaced at a later time.  "Filler" fit the context better so
I used it instead.  Regardless, I'll rework the proposal over again with
the suggestions you have made.  I'm glad the proposal is technically
sound.  It just means we have to iron out the wording.

-Tom

>-----Original Message-----
>From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
>Behalf Of Stuart Sutherland
>Sent: Wednesday, November 28, 2007 9:46 PM
>To: Maidment, Matthew R; sv-bc@server.eda.org
>Subject: RE: [sv-bc] e-mail ballot: respond by Dec 3, 8am PST
>
>
>Stu's votes...
>
>
>> SVDB  329 _X_Yes   ___No
>> http://www.eda.org/svdb/view.php?id=329
>>
>> SVDB 1338 ___Yes   _X_No
>> http://www.eda.org/svdb/view.php?id=1338
>
>I do not object to the technical aspects of the proposal, but found the
new
>text and example to be confusing.  The paragraphs starts off talking
about
>`", but the new sentence that begins with "A string literal embedded
inside
>a macro..." at the end of the paragraph and the new example after the
>paragraph do not use `".  I suggest moving this new sentence and
>accompanying example and the new paragraph after the new example to all
>come
>after the original example and accompanying description, instead of
before.
>
>>
>> SVDB 1339 ___Yes   _X_No
>> http://www.eda.org/svdb/view.php?id=1339
>
>I think striking the phrase "not preceded by a backslash" is the wrong
>thing
>to do.  Since the preceding sentence is talking about preceding a
newline
>with a backslash, this phrase is necessary in order to make it clear
that
>it
>not the backslash-newline that ends the macro text.  I will change my
vote
>to yes if this phrase is left in.
>
>>
>> SVDB 1548 _X_Yes   ___No
>> http://www.eda.org/svdb/view.php?id=1548
>>
>> SVDB 1571 _X_Yes   ___No
>> http://www.eda.org/svdb/view.php?id=1571
>
>I'm voting no only because I'm not sure how to best handle the
dependency
>of
>1571 on 1957.  If 1957 passes all the way through the working group,
then I
>have no problems with 1571.  If 1957 does not pass, however, then the
>proposal for 1571 needs to be rewritten.  Perhaps a better way to
handle
>this dependency is to fold 1957 into this proposal, and close 1957 as a
>duplicate.
>
>>
>> SVDB 1619 ___Yes   _X_No
>> http://www.eda.org/svdb/view.php?id=1619
>
>I am OK with the technical change, but feel some of the wording needs
work.
>
>1) In many places throughout the proposal, I think "will" should be
"shall".
>
>2) The first part of the first sentence in the proposed new subclause
>22.2.2.4 is superfluous, at best.  "To handle common cases or allow for
>unused input ports, SystemVerilog allows a module declaration..." can
be
>simplified as just: "A module declaration...".
>
>3) In the fourth paragraph of the proposed new subclause 22.2.2.4, I
found
>the last sentence confusing.  First, it says "If a ***VALUE*** is
omitted
>from an input port...".  What "value"?   Second, the sentence ends
saying
>"...the port will either be left unconnected or generate an error", but
>does
>not explain which it will be, or where to look for the answer.  I
suggest
>changing the last sentence to:
>
>"If an input port is left unconnected and the port does not have a
default
>value, then depending on the connection style (ordered list, name
>connections, implicit named connections, or implicit .* connections),
the
>port shall either be left unconnected or generate an error, as
discussed in
>22.3.2.1 through 22.3.2.4."
>
>4).  In the fourth paragraph of the proposed new subclause 22.2.2.4, I
do
>not understand the intent of the sentence that reads: "These omitted
(or
>empty) input port connections can be considered fillers for default
values,
>allowing the use of nonconsecutive default values."  What is meant by
>"filters" and what is meant by "nonconsecutive default values"?
>
>5).  Why is it necessary to change the active-low rst_n signal to an
>active-high rst signal in module xtend?  Cannot default port values be
used
>with active-low resets?
>
>>
>> SVDB 1957 _X_Yes   ___No
>> http://www.eda.org/svdb/view.php?id=1957
>>
>> SVDB 2102 _X_Yes   ___No
>> http://www.eda.org/svdb/view.php?id=2102
>>
>> SVDB 2106 _X_Yes   ___No
>> http://www.eda.org/svdb/view.php?id=2106
>>
>> SVDB 2152 _X_Yes   ___No
>> http://www.eda.org/svdb/view.php?id=2152
>>
>> SVDB 2163 _X_Yes   ___No
>> http://www.eda.org/svdb/view.php?id=2163
>>
>> SVDB 2169 _X_Yes   ___No
>> http://www.eda.org/svdb/view.php?id=2169
>>
>> SVDB 2170 _X_Yes   ___No
>> http://www.eda.org/svdb/view.php?id=2170
>>
>> SVDB 2178 _X_Yes   ___No
>> http://www.eda.org/svdb/view.php?id=2178
>>
>> SVDB 2184 _X_Yes   ___No
>> http://www.eda.org/svdb/view.php?id=2184
>>
>
>
>Stu
>~~~~~~~~~~~~~~~~~~~~~~~~~
>Stuart Sutherland
>Sutherland HDL, Inc.
>stuart@sutherland-hdl.com
>503-692-0898
>
>
>
>--
>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.