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

"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. 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
>