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.
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.
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
document that does not have to be there.
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?
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?
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.
Regards
Graham
Received on Sun Sep 3 19:24:25 2006