Re: [sv-bc] Confusion in function evaluation approach

Here is a more complete example to make this more precise:

   function integer f(input integer x, input integer y);
   begin
      f = x;
   end
   endfunction

   initial $display(f(f(1,2),f(3,4)));

We effectively have the following set of assignments
to "f.x" --
    x = 1
    x = 3
    x = f(1,2)

The problem that you are observing is the the ordering
of "x=3" with respect to "x=f(1,2)" is not defined.
That is correct, it isn't.  This is an area in which the
LRM is silent and/or explicitly allows for different
approaches.  For example, in SV, when assignments occur
in a side-effecting operation verus when "intermediate"
values are read is not defined (i.e. f(i++, i++)).  This
indeterminate behavior is intentionally permitted in
order to allow more optimization choices.  If one
is using side effects, you can't rely on the behavior.
In this case there is a (slightly surprising) side-effect --
the static variable "f.x" is assigned a value.  You
cannot rely on the behavior in such cases.

I agree that "3" would be a surprising answer here, but it
isn't illegal.

Gord.

Surya Pratik Saha wrote:
> Hi,
>      Consider the scenario
> 
> *     function signed [15:0] func;
>        **input [7:0] ix1,cond;**   
>         [...]
>      endfunction *
> 
>     *assign in1  = func(func('sb1110111,3),func('sb11001100,2));
> 
> *        Now we can follow two different approaches during propagation 
> of value form actual to formal argument for the above function call
> 
> *Approach 1: *
> - evaluate first argument func('sb1110111,3) and propagate the evaluated 
> value to the corresponding formal argument of *func*( 
> (func('sb1110111,3),func('sb11001100,2)).
> - evaluate the second argument func('sb11001100,2) and propagate the 
> evaluated value to
>    the corresponding formal argument of *func*( 
> func('sb1110111,3),func('sb11001100,2)).
> 
> By this approach - during value propagation of the second argument of 
> function call func(func('sb1110111,3),*func('sb11001100,2)*) the 
> propagated value of the first formal argument for 
> *func*(func('sb1110111,3),func('sb11001100,2)) got changed due to 
> propagation of value form actual to formal argument during evaluation of 
> func('sb11001100,2). So after value propagation from actual to formal 
> arguments the first formal argument of the function call 
> *func*(func('sb1110111,3),func('sb11001100,2)) will contain value 
> 'sb11001100, not evaluated value of func('sb1110111,3).
> 
> *Approach 2:*
>  - evaluate arguments func('sb1110111,3) and func('sb11001100,2) and 
> stores the evaluated values at the table.
> - propagate the stored evaluated value to the formal arguments for 
> func(func('sb1110111,3),func('sb11001100,2).
> 
> By this approach - first fromal argument of function call 
> func(func('sb1110111,3),func('sb11001100,2) will contain evaluated value 
> of func('sb1110111,3) not 'sb11001100. But this approach is similar to 
> automatic function evaluation whereas the original function is a static one.
> 
>  LRM is not clear on function call value propagation. Can someone help 
> me what would be the right approach. Different tools behave differently 
> here.
> 
> -- 
> Regards
> Surya
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


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