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

From: Surya Pratik Saha <spsaha_at_.....>
Date: Tue Feb 05 2008 - 18:47:53 PST
Hi Steven,
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.?

Regards
Surya



-------- 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.
Received on Tue Feb 5 18:48:31 2008

This archive was generated by hypermail 2.1.8 : Tue Feb 05 2008 - 18:48:40 PST