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

These changes resolve my concerns.  I would like to change my vote on Mantis
1619 to Yes.

Thanks, Thomas, for taking the time to work on this, and for considering my
suggestions.

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
Sutherland HDL, Inc.
stuart@sutherland-hdl.com
503-692-0898
 

> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Alsop, Thomas R
> Sent: Friday, November 30, 2007 11:10 AM
> To: Bresticker, Shalom; 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
> 
> 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.
> 
> 
> 


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