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

A similar analysis could be made for the assignments
to f.f (the function result variable), which is also
static.

This is a call sequence whose Verilog (& Fortran IV)
default behavior isn't easy to make faithful to
mathematical conventions.

First, expression evaluation requires producing a temporary
for everything on the "execution stack" during evaluation.
Then, each function must be fully evaluated and its result copied
out into the expression's temp before binding any arguments
to the next call of f().  If these "automatic" temporaries
exist it covers a lot of "static" sins.

I feel that is one reasonable approach, although standardizing
on it would probably leave some vendors in the dust and
could change memory requirements and even logic for some
supposedly settled legacy designs.  I'd argue that those
designs were never actually conforming, but I'd lose the
argument because so few systems issue warnings in this case.

My gut feeling is that SV ought to break compatibility
with legacy Verilog and fix this ASAP (but that could
leave it a starving, jobless, gut if enough legacy code
uses static functions).  I don't have enough evidence
one way or the other to make a recommendation, only that
my early experience with this Verilog "creature feature"
was that users seldom meant to use static binding, and
a switch to "infer local latches" was very popular,
albeit non-standard and a source of sim/synth mismatch.

Greg Jaxon


Gordon Vreugdenhil wrote:
> 
> 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.
> 


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