Re: Questions on BNF

Dave,

Dave Miller wrote:
> G'day Graham,
> thanks for the answers, I have embedded some comments below,
> 
>>> 1. ddx(). In the BNF we now mention explicitly the arguments to the 
>>> analog_filter_functions. But it now allows the second argument of 
>>> ddx() to be a branch_probe_function_call which allows things like: 
>>> ddx(expr, V(a,b)); (before it had to be the flow of a branch or 
>>> potential of a single pin).
>>> Is this intended, should the BNF change, or should I just make the 
>>> restriction in the text of the document (I couldn't figure out how to 
>>> define the BNF to enforce this - I(br1), V(a)).
>> In order to keep the syntax simple and avoid many variants of the 
>> almost that syntax all over the place, I have used common 
>> branch_probe_function_call syntax item. I suggest explicitly stating 
>> what is allowed and not allowed for argument 2 in the ddx() section.
> No worries, I will make the semantic restriction in the ddx() section. 
> Also I wasn't quite sure why we had the restriction on the second 
> argument to be a single node, it seems to be reasonable to ask what is 
> the dependency of the input expression with respect to the branch 
> V(a,b), but anyway, I will leave as is with the semantic restriction.\


I remember that we had this discussion in the committee during LRM2.2 
meetings. The reason (probably Geoffrey might remember better) was to 
very clearly state when writing the equation which terminals are held 
constant while taking the symbolic derivative. Hence it was decided to 
go for the voltage of a node.

As an aside, i think there were some request for the second argument to 
be for eg. temperature since people would want to take derivative with 
other quantities. That discussion was deferred.


>> 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?
> 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.


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)?


>>
>>> 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); ??



cheers,
Sri