RE: [sv-bc] Serious issue with default expressions for task and function arguments

> Parse a default argument expression in the scope where it is written.
> Evaluate it once at each call site that exercises that default.
> This is a powerful software engineering tool for injecting
> code at each call site, without editing them all.  Gord's definition is
> consistent with most compiled languages that offer this feature (e.g.
> F90, C++, Algol68).

I assume by "parse" here you mean just convert the character string into
an AST without resolving any identifiers and "evaluate" means resolving
the identifiers. If the default value is non-constant, you cannot fully
evaluate the expression to a constant.  

I think it is the meaning of "elements of the expression" which is causing
the confusion here. Apparently different people think this means different
things.

I think the idea of default values and non-constant default values was a
test bench feature. The wording of the LRM probably came from the EC and
was some attempt to accommodate hierarchical references. 

In addition to the possibilities mentioned by Gord, you could also outlaw
the use of non-constant default values on all hierarchical or interface
function/task calls. You might still have some confusion for the case:

module A();
parameter p = 1;
function int foo(int x = p);
   return x;
endfunction

initial
begin
   int p = 2;
   $display(foo());
end

endmodule

Is this legal? If so, what value is displayed? 

Since the average engineer looking at this would not be sure what default
value is used in this case, I have no problem with saying this is illegal.

Mark Hartoog
700 E. Middlefield Road
Mountain View, CA 94043
650 584-5404
markh@synopsys.com 

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]On Behalf Of Greg
> Jaxon
> Sent: Thursday, March 03, 2005 11:02 AM
> To: Gordon Vreugdenhil
> Cc: Mark Hartoog; ieee1800@eda.org; SV_BC List
> Subject: Re: [sv-bc] Serious issue with default expressions for task and
> function arguments
> 
> 
> Parse a default argument expression in the scope where it is written.
> Evaluate it once at each call site that exercises that default.
> This is a powerful software engineering tool for injecting
> code at each call site, without editing them all.  Gord's definition is
> consistent with most compiled languages that offer this feature (e.g.
> F90, C++, Algol68).
> 
>     Mark wants a principle of syntactic substitution to apply.
> He'd like a simple rewrite rule to be 100% correct.
> 
> If someone wants defaults which can, for example, grab the local
> clock wherever the routine is called, SV already has a macro facility
> that can copy the expression into the caller's scope.  If the clock
> had a distinct data type, this could even be rendered reasonably safe.
> 
> To say that the two approaches are BOTH right but the
> call is legal only if they mean the same thing is unrealistic.
> 
> I concur with Gord.
> 
> Greg
> 
> Gordon Vreugdenhil wrote:
> > 
> > 
> > Mark Hartoog wrote:
> > 
> >> "The elements of the expression must be visible at the scope of 
> >> subroutine
> >> and, if used, at the scope of the caller."
> >>
> >> My interpretation of this was that all identifiers in the expression
> >> had to resolve to the same object (element) in both the subroutine 
> >> scope and the caller scope. 
> > 
> > 
> > That is not what the text says however.
> > 
> > In my case, "p1" is visible at the scope of the subroutine and at
> > the scope of the call.  There is no stated obligation that they
> > must be the same object.
> > 
> > If there is an obligation for the names to be the same object,
> > then the requirement of resolving the name in the caller's scope
> > is meaningless since the name is required to be resolved in the
> > context of the routine as well.  In that case, simply removing
> > the text related to visibility in the scope of the caller would
> > end up with the same effect (and would resolve my concerns).  The
> > fact that the current text does differentiate works against your
> > argument.
> > 
> > Gord.
> > 
> >  > So in your example:
> > 
> >>
> >>
> >>>    module A;
> >>>       parameter p1 = 1;
> >>>       function integer f(integer x = p1) ......
> >>>    endmodule
> >>>
> >>>    module B;
> >>>       real p1;
> >>>       A a();
> >>>       initial $display(a.f);
> >>>    endmodule
> >>
> >>
> >>
> >> the call would be illegal because in the calling scope 'p1' does not 
> >> resolve to the parameter 'p1' in the module 'A'.
> >> The only way to make this legal would be to make the default 'B.a.p1',
> >> which would resolve the same in both scopes. As a practical matter, 
> >> non-constant default values are probably not useable on hierarchical
> >> task and function calls, but I do not see any problem with that
> >> since I expect most default values will be constants.
> >>
> >> We could change the language of that section to make this clearer.
> >>
> >> Mark Hartoog
> >> 700 E. Middlefield Road
> >> Mountain View, CA 94043
> >> 650 584-5404
> >> markh@synopsys.com 
> >>
> >>> -----Original Message-----
> >>> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]On Behalf Of
> >>> Gordon Vreugdenhil
> >>> Sent: Thursday, March 03, 2005 8:49 AM
> >>> To: ieee1800@eda.org; SV_BC List
> >>> Subject: [sv-bc] Serious issue with default expressions for task and
> >>> function arguments
> >>>
> >>>
> >>>
> >>> While reviewing aspects of the draft SV standard, we came across
> >>> the following in Section 11.4.3 (Default argument values [Tasks and
> >>> Functions]):
> >>>
> >>>    The default_value is an expression. The expression is evaluated in
> >>>    the scope of the caller each time the subroutine is called. The
> >>>    elements of the expression must be visible at the scope of subroutine
> >>>    and, if used, at the scope of the caller. If the default_value is not
> >>>    used, the expression is not evaluated and need not be visible at the
> >>>    scope of the caller.
> >>>
> >>>
> >>> The LRM requires that the terms of the default expression to be resolved
> >>> in the context of the **caller**.  This is not at all reasonable
> >>> as a general programming language semantic definition, nor in
> >>> the context of separate compilation and hierarchically referenced
> >>> tasks and functions.
> >>>
> >>> Consider obvious examples such as:
> >>>
> >>>    module A;
> >>>       parameter p1 = 1;
> >>>       function integer f(integer x = p1) ......
> >>>    endmodule
> >>>
> >>>    module B;
> >>>       real p1;
> >>>       A a();
> >>>       initial $display(a.f);
> >>>    endmodule
> >>>
> >>> The LRM currently requires that actual parameter value used in
> >>> the call of a.f will be the value of "p1" from B.p1.
> >>>
> >>> Although in the context of synthesis, one could conceivably make
> >>> an argument that this "macro" view of default values might be
> >>> useful (since hierarchical calls aren't allowed), in the context
> >>> of simulation, this is not reasonable.
> >>>
> >>> This issue will be raised as part of Mentor's official response, but
> >>> I wanted to raise this immediately since we consider this to be
> >>> a very significant flaw.
> >>>
> >>> Gord
> >>> -- 
> >>> --------------------------------------------------------------------
> >>> Gordon Vreugdenhil,  Staff Engineer               503-685-0808
> >>> Model Technology (Mentor Graphics)                gordonv@model.com
> >>>
> >