Re: Questions on BNF

From: Dave Miller <David.L.Miller_at_.....>
Date: Wed Sep 06 2006 - 03:23:56 PDT
Hi Sri,
Sri Chandra wrote:
>> I didn't realise we were going to allow the analog_function_port_list 
>> similar to what is in digital. Of course I would prefer not to as it 
>> means a parser change :)
>> If we are trying to mimic digital functions, I wonder if we should 
>> remove the restriction on not allowing recursive analog function 
>> calls, so you can support things like a factorial function?
>> I have read through 10.4 and I think I have most of it covered.
>> The main thing I tried to add for analog UDF's is how output and 
>> inout parameters are supported as I tend to find these confusing. 
>> Especially inout parameters. This depends very much on how one 
>> defines "inout", is it pass by reference, copy in - copy out? Anyway 
>> I have documented it as copy in - copy out, and when we do the UDF 
>> section we can discuss further if needed.
> One extra think, after looking at section 10.4 of 1364-2005, I like 
> the level of detail that the standard goes into. However, the LRM 2.2 
> does not go to that level of detail. To what level of detail are you 
> going to to define the analog function and analog function calls?
>
>
> The confusion comes especially when you use repeated arguments ie. 
> udf_fn(a,a,...) where the arguments are inout its a bit confusing what 
> the values should be. In that sense i think it is a good idea to 
> clearly define what the intent is, and i think explicitly stating 
> copy-in/copy-out is probably a good thing. Wonder what C does? Guess 
> it depends on compiler and order of evaluation of the arguments of a 
> function (left-to-right vs right-to-left)?
>

Well C it is a bit clearer as you have to pass  by pointer, so you know 
that you are directly modifying
 the original variable.
>
>>>
>>>> 5. Am I allowed to have constant_analog_function_call? I notice 
>>>> that the syntax only allows for constant_function_call. Should we 
>>>> add a constant_analog_function_call rule and include it in 
>>>> constant_primary?
>>> OK, I think your question points to a bigger issue that has not be 
>>> discussed previously.
>>>
>>> In LRM 2.2 the  function_declaration can only be called from 
>>> 'expression' syntax, while analog_function_declaration can only be 
>>> called  from analog_expression syntax. No overlap wrt. domain. Now 
>>> in the 1364-2005,  constant version of function declarations (see 
>>> section 10.4.5 for the constraints) can be declared and called 
>>> within the constant_expression syntax. This means a constant digital 
>>> function declarations can be called from with the analog behavior 
>>> where ever a constant expression syntax is used. Should this be 
>>> allowed?
>>
>> Well my answer is no, we shouldn't allow this, but I think my answer 
>> is influenced by implementation.
>>
>>>
>>> Even if the answer to the above question is yes,  I believe there is 
>>> little value in supporting constant versions of analog function 
>>> declarations for use in constant expression. My reasoning for this 
>>> is that similar constraints  (as in section 10.4.5 of the 2005 LRM) 
>>> will need to be  applied to the analog function declarations. In 
>>> doing so, the constant analog function declarations will become very 
>>> much like a constant digital function declarations. So it would be 
>>> easier to use the existing constant function call mechanism instead 
>>> of creating constant analog function declaration which basically 
>>> does the same thing. I'll be very interested to know what other 
>>> committee members think about this issue.
>
> I agree that whereever possible if we can use the same syntax as the 
> digital (ie. no need to differentiate and create an analog version of 
> the syntax) i would just go ahead and use the existing ones.
>
> Is this query also related to initializing a parameter with constant 
> UDF calls? Sorry if i didnt understand the usage correctly.
>
> For example:
>   parameter real Q = ...;
>   parameter P = myUDF(Q); ??
>
Yes, I am referring to constant UDF's solely for parameter 
initialisation. Among other reasons, I wanted a constant analog UDFso I 
could initialise a parameter that is declared inside an analog named block.

Cheers...
Dave
>
>
> cheers,
> Sri
>


-- 
=====================================
-- David Miller
-- Design Technology (Austin)
-- Freescale Semiconductor
-- Ph : 512 996-7377 Fax: x7755
=====================================
Received on Wed Sep 6 03:24:03 2006

This archive was generated by hypermail 2.1.8 : Wed Sep 06 2006 - 03:24:05 PDT