Re: [sv-bc] query regarding $bits function

Hi Steven,
I understand your point, that - to get the width of a function call 
having dynamic return type the function needs to be evaluated and that 
can cause side effect. To avoid that it is restricted to be used in $bits.
But this is very generic restriction, all functions don't cause side 
effect. We can easily filter out those by imposing constant function 
restriction on that.

Regards
Surya



-------- Original Message  --------
Subject: Re:[sv-bc] query regarding $bits function
From: Steven Sharp <sharp@cadence.com>
To: sharp@cadence.com, spsaha@cal.interrasystems.com
Cc: sv-bc@eda-stds.org, sarani@cal.interrasystems.com
Date: Wednesday, February 06, 2008 9:20:00 AM
>> From: Surya Pratik Saha <spsaha@cal.interrasystems.com>
>>     
>
>   
>> LRM mentions:
>> *It shall be an error to enclose a function that returns a dynamically 
>> sized data type.
>>
>> *Actually from this text the confusion comes. How a function can return 
>> "dynamically sized data types". Can you give an e.g.?
>>     
>
> Yes, that would be the text that applies to your testcase.  The wording
> is rather poor.  It should not say "enclose a function that returns a
> dynamically sized data type", but something more like "enclose a function
> call that returns a value of a dynamically sized data type".
>
> Notice the previous sentence about how the result of $bits is determined
> without evaluating the expression.  This is the issue that I raised with
> the testcase, though I didn't know whether the LRM addressed it.
>
> Your testcase is an example of this, and is therefore illegal.
>
>
>
>   
>> -------- Original Message  --------
>> Subject: Re:[sv-bc] query regarding $bits function
>> From: Steven Sharp <sharp@cadence.com>
>> To: sv-bc@eda-stds.org, sarani@cal.interrasystems.com
>> Date: Tuesday, February 05, 2008 11:50:06 PM
>>     
>>>> From: Sarani Roy <sarani@cal.interrasystems.com>
>>>>     
>>>>         
>>>   
>>>       
>>>> According to LRM:
>>>> It shall be an error to use the $bits system function directly with a
>>>> dynamically sized data type identifier.
>>>>     
>>>>         
>>> I don't think this LRM text is relevant to your example.  When this text
>>> refers to a "dynamically sized data type identifier", it does not mean
>>> "an identifier (e.g. variable) of a dynamically sized data type".  It
>>> means "a data type identifier (e.g. typedef name) that represents a
>>> dynamically sized type".  You cannot ask "how big is a string type?"
>>> You have to ask "how big is this particular string?"
>>>
>>>
>>>   
>>>       
>>>> Is this valid :
>>>>
>>>> module top( input  [10:0] in1, input clk);
>>>> int bit_count;
>>>> string str1;
>>>>
>>>> function string my_func(input bit [10:0] in1);
>>>>    begin
>>>>       str1 = string'(in1);
>>>>      return str1;
>>>>    end
>>>> endfunction
>>>>
>>>> always@(clk)
>>>>  bit_count = $bits(my_func(in1));
>>>> endmodule
>>>>
>>>> Some standard simulators are passing.
>>>>     
>>>>         
>>> The issue here is presumably that you can normally determine $bits
>>> of an expression without having to evaluate it.  In this case, you
>>> would have to evaluate it and actually call the function, possibly
>>> causing side effects.  I can see how some implementors might decide
>>> that this was improper.
>>>
>>> Steven Sharp
>>> sharp@cadence.com
>>>
>>>
>>>   
>>>       
>>
>>
>>
>> -- 
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>>     
>
> Steven Sharp
> sharp@cadence.com
>
>
>
>
>
>   





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