Re: [sv-bc] Constant method calls

From: Surya Pratik Saha <spsaha_at_.....>
Date: Thu Feb 07 2008 - 21:10:52 PST
Hi Greg,
I am not design expert. But if we consider the following e.g.

module top;
    enum {A, B, C} e;
    initial begin
       for (int i = 0; i < e.next(); i ++) begin:b
          reg[e.next(): 0] r;
       end
    end
endmodule

The e.next is called in 'for' loop expression part, does it not anyway 
effect the 'e.next' call when 'r' is declared. If not then 'next' can be 
considered as constant, but if yes, then 'next' is not constant.

Regards
Surya



-------- Original Message  --------
Subject: Re:[sv-bc] Constant method calls
From: Greg Jaxon <Greg.Jaxon@synopsys.com>
To: Surya Pratik Saha <spsaha@cal.interrasystems.com>
Cc: Greg Jaxon <Greg.Jaxon@synopsys.com>, Steven Sharp 
<sharp@cadence.com>, sarani@cal.interrasystems.com, sv-bc@eda.org, 
sv-ec@eda.org
Date: Friday, February 08, 2008 10:15:25 AM
> Surya,
>
>    For enum { A=1, B, C }   A.next is always B,  B.next is always C.
>    I think the method is constant when applied to a constant enum value.
>    Only some LRM wording and some implementation effort is needed to
>    make it so.  A compelling example would probably be needed to persuade
>    the implementers on the committee.
>
> Greg
>
>
> Surya Pratik Saha wrote:
>   
>> Hi Gordon,
>> 'next' method is not constant because the value of 'next' method depends
>> on the no. of call of that method. And this no. of call is not
>> elaboration time constant. Is it not correct?
>>
>> Regards
>> Surya
>>
>>
>>
>> -------- Original Message  --------
>> Subject: Re:[sv-bc] Constant method calls
>> From: Greg Jaxon <Greg.Jaxon@synopsys.com>
>> To: Surya Pratik Saha <spsaha@cal.interrasystems.com>
>> Cc: Steven Sharp <sharp@cadence.com>, sarani@cal.interrasystems.com
>> Date: Thursday, February 07, 2008 10:46:56 PM
>>     
>>> Surya,
>>>
>>>    I concur with Steven's reading of the LRM, but as he hinted, the next
>>> method when applied to a constant enum returns a deterministic result and
>>> has no side-effects.  I don't understand why you'd say it isn't
>>> "constant",
>>> except that the LRM currently makes no accommodation for these methods in
>>> the rules about constant expressions.
>>>
>>> Greg
>>>
>>> Surya Pratik Saha wrote:
>>>  
>>>       
>>>> Hi Steven,
>>>> Is 'next' method call also allowed? I think no, though the method is
>>>> called on a constant object. Because return value of 'next' is not at
>>>> all constant. I think LRM should provide the list of method can be
>>>> applied in const_expression context to avoid any confusion instead of
>>>> leaving for the vendor tool.
>>>>
>>>> Regards
>>>> Surya
>>>>
>>>>
>>>>
>>>> -------- Original Message  --------
>>>> Subject: Re:[sv-bc] Constant method calls
>>>> From: Steven Sharp <sharp@cadence.com>
>>>> To: sv-bc@eda-stds.org, sarani@cal.interrasystems.com
>>>> Date: Tuesday, February 05, 2008 11:36:44 PM
>>>>    
>>>>         
>>>>>> From: Sarani Roy <sarani@cal.interrasystems.com>
>>>>>>             
>>>>>>             
>>>>>  
>>>>>      
>>>>>           
>>>>>> Since according to LRM "An enumerated type declares a set of integral
>>>>>> named constants."
>>>>>> It is not clear to me why we cannot use atleast first() , last() and
>>>>>> num()
>>>>>> enum methods as constant function call.
>>>>>> As pointed out by Gord all the normal rules regarding constant
>>>>>> function behavior would apply to
>>>>>> to these function calls.
>>>>>>             
>>>>>>             
>>>>> While I don't think that there is a technical problem with allowing
>>>>> these
>>>>> to be constant functions, I agree with Brad Pierce that the current LRM
>>>>> text does not allow them.
>>>>>
>>>>> 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 Thu Feb 7 21:13:11 2008

This archive was generated by hypermail 2.1.8 : Thu Feb 07 2008 - 21:14:50 PST