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

 

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

Yes.


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

This was copied from the parallel text in 13.5.3, on subroutine argument
defaults. But it can be changed as you suggest.

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

Even better would be 
"If a connection is not specified for an input and the port does not
have a default value ...".


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

This was also based on the parallel text in 13.5.3, 

"Unspecified (or empty) arguments can be used as placeholders for
default arguments, allowing the use of nonconsecutive default
arguments."

Tom replaced 'placeholders' with 'fillers' (not 'filters').
I don't like this text, either.
I think the intent of 'nonconsecutive default arguments' was that you
can mix defaults and non-defaults in any combination. So for example, if
you connect by order, then you can use defaults for args/ports 1, 3, and
5 by using commas as placeholders. If you connect by named association,
then you can just omit those you want defaults for.


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

Sure it can. Module accum shows an active-low reset. But rst_n is not
connected to rst.
By using two different reset signal names, then in 22.3.2.3 with .name,
it shows two different special situations:
.rst_n() leaves rst_n unconnected even though it has a default
.rst causes an error because rst does not exist in the instantiating
module alu_accum3.
But I think the same could have been achieved by deleting rst_n from
alu_accum3.

Shalom
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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