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.