Shalom, Your assertion that an output argument is not evaluated is not strictly correct. An expression that specifies an L-value is indeed evaluated in the caller. The simplest and perhaps most obvious example is an indexing expression: function void F( output bit y ); y = 1'b1; endfunction bit [5:0] a; int j = 2; initial F( a[ j + 1 ] ); The reason for the original language is that the expression may also contain context-dependent variables such as time scales, otherwise, I it could have been written using verbiage such as "all signal names are bound in the scope containing the declaration". I also have to admit that the original intent was only to provide defaults for inputs (similar to how Steven Sharp suggested before). That's the main reason why outputs were excluded, but, I believe the current proposal is an improvement. Arturo ________________________________ From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Bresticker, Shalom Sent: Thursday, August 16, 2007 1:39 AM To: Rich, Dave; sv-bc Subject: RE: [sv-bc] Mantis 1602: task/function inout arg defaults - draft proposal Dave, ________________________________ From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Rich, Dave Sent: Wednesday, August 15, 2007 9:33 AM To: Bresticker, Shalom; sv-bc Subject: RE: [sv-bc] Mantis 1602: task/function inout arg defaults - draft proposal Hi Shalom, This still does not explain when the default expression is applied to an output, [SB] The section quoted in the proposal does not explain when the default expression is applied to an input either. That explaination follows later in the following paragraph, which says, [SB] "When the subroutine is called, arguments with default values can be omitted from the call, and the compiler shall insert their corresponding values. Unspecified (or empty) arguments can be used as placeholders for default arguments, allowing the use of nonconsecutive default arguments. If an unspecified argument is used for an argument that does not have a default value, a compiler error shall be issued." Maybe we should change the phrase "default value" in that paragraph, since in the case of inouts, outputs, and ref's, it is not really a value. or why you would want to use one. [SB] This was discussed in the previous SV-BC meeting, and the majority was in favor of allowing output defaults, so your argument is not with me. I just asked what the majority opinion was. If you ask what I would use it for, I would say that it is just like any other default. That is, if I would often call the subroutine using the same actual argument for this output, then a default would be useful so that I would not have to write it explicitly each time, just as with an input. If the only purpose is to leave the output unconnected, why don't we use something like output/inout int arg = null; to say that the output may be discarded if left unconnected. [SB] In the SV-BC meeting, several ways of leaving an output unconnected were discussed, and there was not general agreement on any particular way. Yours is one. I wanted to get agreement on output defaults in general before extending them to allow unconnected outputs. I guess one could use 'null' as an actual output argument as well, in order to explicitly unconnect it. We probably should only allow const ref arguments, not ref arguments to specify a default. [SB] Again, the general feeling of the committee was different. I liked the original wording about the default expression being bound to the declaration scope. I don't like words like "as though" to describe behavior. [SB] My proposal essentially preserves that original wording. The original said, "The expression is evaluated in the scope containing the subroutine declaration." My proposal has the wording, "the default expression is evaluated in the scope containing the subroutine declaration, not in the scope containing the subroutine call." The additional sentencethat I added that you refer to is, "the call is treated as though the default had been written explicitly in the subroutine call." The reason I added that sentence is that the phrase, "the expression is evaluated" gives the impression that its value is evaluated and its value is used. That makes sense for an input, but not for an ouput, inout, or even a const ref. Thanks, Shalom ________________________________ From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Bresticker, Shalom Sent: Tuesday, August 14, 2007 10:44 PM To: sv-bc Subject: FW: [sv-bc] Mantis 1602: task/function inout arg defaults - draft proposal Hi, I did not get any responses to this. Please comment. Thanks, Shalom ________________________________ From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Bresticker, Shalom Sent: Friday, August 03, 2007 6:29 PM To: sv-bc Subject: [sv-bc] Mantis 1602: task/function inout arg defaults - draft proposal <<1602_D3a.doc>> Hi, I have attached a draft proposal for Mantis 1602, clarifying the behavior of subroutine inout argument defaults and also allowing output defaults. It still does not cover allowing output arguments to be unconnected. Please comment. The phrasing about identifiers in the defaults being bound from the scope of the subroutine declaration is the same as the original phrasing, but I feel it is not clear enough and requires some examples to clarify it. Thanks, Shalom Shalom Bresticker Intel Jerusalem LAD DA +972 2 589-6852 +972 54 721-1033 -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Aug 16 13:50:19 2007
This archive was generated by hypermail 2.1.8 : Thu Aug 16 2007 - 13:50:43 PDT