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

Stu,  I have made changes per your suggestions to the proposal.  You can
just look directly at the notes section of the mantis item for what I
changed.  Additional comments below. -Tom

>-----Original Message-----
>From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
>Behalf Of Bresticker, Shalom
>Sent: Thursday, November 29, 2007 3:39 AM
>To: stuart@sutherland-hdl.com; Maidment, Matthew R;
sv-bc@server.eda.org
>Subject: 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.
[Alsop, Thomas R] I agree too.  Fixed.

>
>
>> 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.
>
[Alsop, Thomas R] I agree on the superfluous comment.  This now starts
"A module declaration may specify a default value for each singular
input port. ". 

>
>> 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 ...".
>
[Alsop, Thomas R] I completely missed that "value" statement. That
should have been "connection".  I agree with Stu on this one.  I am
changing the sentence to his suggestion.  It is more clear to me and
doesn't leave anyone hanging at the end of the sentence about whether an
error is generated or not and where to get more information about that
last issue.

>
>> 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.
>
[Alsop, Thomas R] Stu makes a good point, through off-reflector mail
that this sentence is really just a "suggestion on how users might
utilize default input values, and serves no technical purpose".  I agree
so I am striking this sentence. 

>
>> 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.
>
[Alsop, Thomas R] Shalom is correct. I wanted to show two different
situations, one with a "reset" in the parent/calling module and one not
in the parent/calling module for the example in 22.3.2.3. The rst_n is
in the parent module but rst is not. This shows what happens when a user
instantiates the xtend module and tries to implicitly connect by name
when a default exists on rst.   Since the parent does not have the rst,
it doesn't matter that the default exists, an error is still generated.

The distinction is further drawn out in the 22.3.2.4 example of the same
code but in this case the default value is used even though the parent
does not have the rst signal. Hence the semantic difference between
.name and .*.

I have uploaded the changes I have indicated in this mail.

-Tom

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