Minutes July 27th : Re: [Fwd: Draft syntax changes for constant_expression and analysis()]

Summary of discussions from the Verilog-AMS meeting: July 27th

Attendees:
Martin O'leary - Cadence
David Miller - Freescale
Jim Barby - Uni of Waterloo
Graham Helwig - ASTC
Sri Chandra - Freescale

* analysis() function cannot be used in any declaration syntax.
* analysis() function cannot be used in any nature/discipline declarations
* analysis() function cannot be used within the attribute syntax
* analysis() function cannot be used within tolerance expressions of 
cross/timer/above analog events - This would clean up the syntax since 
in the current draft the events syntax is duplicated once for 
event_expression and once for analog_event_expression because they use 
different constant expressions. This can be merged into one syntax.

All of the above will refer to constant_expression which will *not* have 
analysis() expression as part of that syntax. There was agreement on this.

* support of analysis() functions in RHS of contribution statements or 
variable assignment statements.

The support for the above is bit unclear. The current standard LRM2.2 
does not allow the usage of analysis functions in RHS of these 
statements. It refers to analog_expression. The draft version attempts 
to put an explicit note on this restriction. However, its unclear 
whether existing implementations support this. Also, need to look at 
whether this usage is useful on the context of assignment/contribution 
statements. Need to clarify this.

* Finally, it looks like analysis() usage makes sense in conditionals 
only, from the current usage. Also, in an if-else-if conditionals if the 
top level is a constant expression are the conditional expression need 
to be constant. This is to cleanly support the usage of analog operators 
inside conditionals.

* The current syntax (draft proposal submitted by Graham) to support 
analysis() correctly is bit messy because now we have expression, 
analog_expression, constant_expression, constant_analog_expression. 
Also, above this, the syntax for conditionals and case is duplicated for 
the usage of analysis() function.

There are possibly two solutions for this that was discussed

* support analysis() as part of analog_expression. This will remove the 
need for have two separate syntax item for case/conditionals. However 
this will lead to other problems, with usage of analog operators and 
also we need to document clearly and explicitly where analysis() cant be 
used if the syntax uses analog_expression

* The other option is keep analysis separately (somewhat similar to 
LRM2.2) instead of merging with constant_expression syntax. Since its 
required only in conditional/case statement we can explicitly allow 
analysis_function_primary in these conditional expressions.

Regards,
Sri

Sri Chandra wrote:
> 
> 
> -------- Original Message --------
> Subject: Draft syntax changes for constant_expression and analysis()
> Date: Mon, 19 Jun 2006 14:09:46 +0930
> From: Graham Helwig <graham.helwig@astc-design.com>
> To: Sri Chandra <srikanth.chandrasekaran@freescale.com>
> CC: VerilogAMS Reflector <verilog-ams@eda.org>
> 
> Hello Sri and others,
> 
> I have generated a new draft version of merged syntax detailing changes
> to analog constant_expression and analysis() function. It can found at
> http://www.verilog.org/verilog-ams/htmlpages/public-docs/merged_syntax_constantAnalogExpression.pdf. 
> 
> 
> I have created the analog_constant_expression syntax item. I have
> removed analysis() call from constant_expression. All
> constant_expression syntax items within the analog block have been
> replaced with analog_constant_expression, except for:
> - expression within parameter and variable declarations within named
> sequential blocks
> - local and hierarchical references of array identifiers (inc. nets,
> branches, variables, parameters).
> This is because this syntax is common between analog and digital parts
> of the syntax.
> 
> Expressions within nature and discipline declarations will remain as
> constant_expression.
> 
> Can analysis() function be used within the attribute syntax within the
> analog block?
> 
> There is separate syntax for cross/above/timer usage in analog and
> digital contexts. Should analysis() be allowed in the these functions at
> all or only in the functions present within the analog context?
> 
> The analog_expression syntax still does not support analysis() fucntion
> calls.  So the  following  type of analog behavior will not be allowed:
> 
>    V(brn1) <+ analysis("static");
>    V(brn2) <+ (analysis("ac")) ? ..... : ......;
>    var1 = analysis("static");
>    var2 = (analysis("ac")) ? ..... : ......;
> 
> In order to use analysis() function in conditional statements, I have
> created constant versions of the analog_conditional_statement and
> analog_case_statement syntax items. By doing this, it has the following
> effects:
> - if the conditional expression of the case statement is constant, so
> then the case item expression must be constant.
> - Similarly if the condition expression of an 'if' statement is
> constant, so then the 'else if' condition expression must also be constant.
> Constant and non-constant expression cannot be mixed. NOTE:
> analog_expression is not an extension of analog_constant_expression, the
> are derived from different primary syntax items.
> I see one of 2 ways of fixing this is:
> 1) remove the constant version of the analog_conditional_statement and
> analog_case_statement syntax items and allow analysis() calls in
> analog_expression
> 2) remove the constant version of the analog_conditional_statement and
> analog_case_statement syntax items and replace the conditional
> expression within these statements with a condition_expression syntax
> item. The conditional_expression syntax item is:
> 
>    conditional_expression ::= analog_constant_expression |
> analog_expression
> 
> More generally, should I use analog_constant_expression or
> constant_analog_expression syntax item name?
> 
> In summary, analog behavior has a blend of constant_expression and
> analog_constant_expression. This will be more difficult to maintain and
> extend in the future.
> 
> Regards
> Graham
> 
> 
> 
> 
> 
> 

-- 
Srikanth Chandrasekaran
DTO Tools Development
Freescale Semiconductor Inc.
Ph: +91-120-439 4056 F: x5199