Re: Questions on BNF

G'day Graham,
thanks for the answers, I have embedded some comments below,

Graham Helwig wrote:
> Hi Dave,
>> As I finish up chapter 4 I just have a couple of questions on the 
>> BNF. I am referring to the file: 
>> merged_syntax_constantAnalogExpression.pdf, I hope that is the right 
>> one. I am sure that some of these are just my own misunderstanding 
>> between what is a syntax error and what is a semantic error.
> The merged_syntax_constantAnalogExpression.pdf file is used to explore 
> the analysis() function updates to the analog_expression. The changes 
> to the syntax will be merged back into the merged_syntax.pdf once they 
> have been finalized. Best to use the syntax from the merged_syntax.pdf.

Okay, my mistake. I will replace any references I introduced for 
analog_constant_expression to be constant_expression.

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

>> 2. absdelay() is mentioned twice, with the first instance mentioning 
>> that the second argument (td) should be an analog_constant_expression.
>> It can be dynamic can't it? Should this rule be just one:
>> | absdelay ( analog_expression , analog_expression [ , 
>> analog_constant_expression ] )
> Ignore any reference to analog_constant_expression, because based on 
> recent committee discussions the direct of the analysis() usage will 
> not require the introduction of a constant type of analog_expression 
> into the syntax. Just use constant_expression as in the merged_syntax.pdf.
>
> LRM 2.2 states thats changes to argument 2 (td) are ignored when 
> argument 3 (maxdelay) is present and argument 2 is dynamic when 
> argument 3 is not present. So in a very roundabout way, the LRM states 
> that argument 2 is switched between a constant_expression and 
> analog_expression. Also since the Verilog-AMS language has no 
> mechanism to add or remove arguments during a simulation, this 
> constraint on argument 2 can be easily implemented as a syntactic 
> restriction instead of a semantic restriction. As a result in the 
> merged_syntax,pdf I used 2 absdelay function calls instead of one.
>
> I'm happy to revert the current syntax back to what was in LRM 2.2 but 
> this will mean an one extra semantic restriction in the body of the 
> ocument that does not have to be there.
Okay, but very confusing these "dynamic" expressions where we ignore any 
changes made to it, since it is a analog operator it can't be in a 
dynamic conditional, hence we use the initial value of the variable? 
Seems both td and max_delay should just be made constant, but I will 
leave it as it is in the absdelay section. We can discuss further when 
we get to that part of the review if necessary. Feel free to leave the 
syntax alone if you prefer.

>> 3. noise_table has the second argument being an 
>> analog_constant_concatenation. I am thinking that this should be 
>> analog_filter_function_concatenation so that I can pass a constant 
>> concatenation or parameter identifier (which can be my vector of pairs).
> Yes, I like the proposed change. If everyone else agrees with the 
> change then I will change the noise table syntax to:
>
>     | *noise_table (* analog_filter_function_concatenation [ *,* 
> string ] *)*
>
>> 4. analog_functions allow the item declaration to be 
>> input_declaration, output_declaration, inout_declaration. but this 
>> then allows things like discipline_identifier, net_type, wreal etc.
>> do you think we should create a unique type just for analog UDFs? So:
>> analog_function_item_declaration ::=
>>       analog_block_item_declaration
>>     | analog_function_input_declaration
>>     | analog_function_output_declaration
>>     | analog_function_inout_declaration
>>
>> analog_function_input_declaration ::=
>>     *input* [ range ] list_of_variable_identifiers
>>
>> analog_function_output_declaration ::=
>>     *output* [ range ] list_of_variable_identifiers
>>
>> analog_function_inout_declaration ::=
>>     *inout* [ range ] list_of_variable_identifiers
>>
> Yes we can define analog function declaration's ports using custom 
> syntax items like you have described. After looking at the 
> function_declaration port syntax I would change your above syntax to 
> below so that the analog function's port declarations are more 
> consistent across digital function and task declarations.
>
> Since the function_declaration syntax has been expanded, I have also 
> extend the analog_function_declaration syntax in the same way.  Does 
> below look reasonable?
>
> function_declaration ::=
>     *analog function* [ analog_function_type ] 
> analog_function_identifier *;*
>     analog_function_item_declaration { analog_function_item_declaration }
>     analog_function_statement
>     *endfunction*
>     | *analog function *[ analog_function_type ] 
> analog_function_identifier *(* analog_function_port_list *) ;*
>       { analog_block_item_declaration }
>       analog_function_statement
>       *endfunction
> *analog_function_type ::= *
>     integer
>     *| *real
> *analog_function_port_list ::=
>     { attribute_instance } analog_input_declaration { *,* { 
> attribute_instance } analog_input_declaration }
> analog_function_item_declaration ::=
>       analog_block_item_declaration
>     | { attribute_instance } analog_function_input_declaration *;*
>     | { attribute_instance } analog_function_output_declaration *;*
>     | { attribute_instance } analog_function_inout_declaration *;*
> analog_function_input_declaration ::=
>     *input* [ range ] list_of_variable_identifiers
>     | *input* analog_function_type list_of_variable_identifiers
> analog_function_output_declaration ::=
>     *output* [ range ] list_of_variable_identifiers
>     | *output *analog_function_type list_of_variable_identifiers
> analog_function_inout_declaration ::=
>     *inout* [ range ] list_of_variable_identifiers
>     | *inout *analog_function_type list_of_variable_identifiers
>
> 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.
>
>> 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.
Well yes, I thought we would have an 
analog_constant_function_declaration that would have the same 
constraints as the digital one (those constraints seem quite 
reasonable). In Verilog-AMS do we have the concept of analog parameters 
vs digital parameters? Or are they just Mixed signal parameters and 
don't take into account what sort of initial expression is assigned to them?

Cheers...
Dave
>
>
> Regards
> Graham


-- 
=====================================
-- David Miller
-- Design Technology (Austin)
-- Freescale Semiconductor
-- Ph : 512 996-7377 Fax: x7755
=====================================