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

The default expression is 'p1', which in the scope of the subroutine
resolves to the parameter 'p1' in the Module 'A'. Parameter 'p1' is 
not visible in module 'B', which I think makes it clear that this 
example is illegal. The fact that the identifier 'p1' resolves 
to a different element in 'B' is irrelevant. The element in the default
value expression is not visible from module 'B'.

If an identifier, 'p1' in this case, resolves to the same object in
the calling scope, then that 'element' is visible from the calling
scope. If it does not resolve to the same element, then the element
of the default value expression is not visible, and any call that
uses that default value is illegal.

> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com]
> Sent: Thursday, March 03, 2005 9:38 AM
> To: Mark Hartoog
> Cc: ieee1800@eda.org; SV_BC List
> Subject: Re: [sv-bc] Serious issue with default expressions for task and
> function arguments
> 
> 
> 
> 
> 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
> >>
> 
> -- 
> --------------------------------------------------------------------
> Gordon Vreugdenhil,  Staff Engineer               503-685-0808
> Model Technology (Mentor Graphics)                gordonv@model.com