Minutes of the Verilog-AMS Committee Meeting: 3 Aug 2006

Attendees:

Marq Kole, Philips
Jim Barby, University of Waterloo
David Miller, Freescale
Martin O'leary, Cadence
Graham Helwig, ASTC
Geoffrey Coram, Analog Devices
Patrick O'Halloran, Tiburan
Sri Chandra, Freescale

Analog constant expression
   * Graham is yet to work on the new proposal. Will be reviewed once 
that is complete. Look for minutes from last week's meeting for 
discussions and options.
   * Making analysis() as part of analog expression is a non-trivial 
change in terms of syntax and its implementation (and the restriction of 
analysis where analog_expression is used needs to be documented). Hence 
the alternative option mentioned in the last meeting minutes (keeping 
analysis separate) is preferable, based on whether we are backward 
compatible or not and what is supported today. LRM2.2 does not allow use 
of analysis() as part of the RHS expression as it was a separate genvar 
function expression that cannot be used in that context - however 
implementations may have supported it based on need with no workarounds.
     * Martin to provide example of usage for analysis as part of RHS in 
contribution statement if there is one being used.


Review of Chapter 6:
   * Section 6.2.2 Block Names
     - Based on IEEE 1364 standard have disabled the overriding of named 
scope parameters from instantiation. This was included as part of the 
first draft version, which has been removed.
     - Correct paragraph 3 on page 110. Remove 1st sentence is 
contradictory to the last sentence on that paragraph and not required. 
Parameters inside named scope can be overridden using defparam.
     - There was a general query on defparam, as it was discussed a 
while back that its going to be deprecated in future versions and P1800. 
It looks like this feature is still available in P1800 version.

   * Section 6.3.1.3
     - Replace the usage of time points as value retention is applicable 
for different analysis, not just transient simulations.

   * Section 6.3.1.4
     - Can contribution statements be allowed inside events and are they 
treated like a switch branch syntax? The syntax allows this usage, 
however it was not allowed semantically in earlier versions of the 
language - not clear whether this is documented or not, and whether tool 
implementors already support this feature if it has not been documented.

   * Section 6.3.2
     - Remove redundant section number from title
     - Change operators to operator in the 2nd paragraph.
     - Verify whether section 5.1.3.4 is accurate. This was verified to 
be okay. It was felt that this might be a duplicate to the section 6.3.2 
which also now describes about the diode, but section 6.3.2 is used more 
for described implicit contribution syntax.
     - Error on the diode equation; I*r value needs to be divided by $vt 
also. This example uses a named branch convention of section 5.1.3.4 
where "a,c" branch is replaced by the named branch "diode"

   * Section 6.3.3
     - First paragraph: One such case instead of once such case
     - indirect branches are now referred more as contribution 
statements rather than assignment operators. This is due to the fact 
that their behavior and solving is more closely related to contribution 
rather than assignment. It was agreed that this would be fine.

   * Section 6.3.3.2
     - Instead of "across same pair of analog nets" - say across same 
pair of analog nets (or any of its parallel branches).
     - The second paragraph that existed in the original LRM2.2 has been 
dropped in the draft version. This paragraph referred to external branch 
reference within a module. The author felt that external branches could 
not be used anyway within a module (assuming external branches referred 
to hierarchical reference of a branch). However Geoffrey pointed out 
that Section 7.5, page 148, below figure 7-3 makes a reference to 
external branches.
     - Is this supported? See some discussion on hierarchical branches 
below. Should this line be reinstated back if hierarchical branch 
references can be used as source (LHS of contribution operators).

   * Support for Hierarchical branches in Verilog-AMS
     - The syntax for branches on the source side of the contribution 
operator (LHS) does not allow hierarchical references. This has been 
changed to simple_identifier which restricts such usage. This was based 
on the assumption that this was never supported in AMS to contribute to 
a branch of a different module.
     - Hierarchical references are used in RHS expressions ie. probing 
of branch, variable, parameters. There are no issues with that.
     - It was felt that this would be useful to model mutual inductors, 
and cadence mentioned that they have had lot of requests from testbench 
users to be able to contribute to an external branch outside the module 
using hierarchical dot references.
     - Allowing this feature would possibly prohibit threading and 
parallelism as now the branch evaluation become order dependent. 
Depending on the order in which modules are instantiated, one might get 
different results
     - Value retention would also pose a big problem if potential and 
flow contributions can be done to an external branch using hierarchical 
dot references.
     - Should the hierarchical references be allowed for both named and 
unnamed branches?
     - Explicitly specifying this restriction - will it break backward 
compatibility. Did the language allow and did tool implementors support 
it? and are there cases where it would be useful and cannot be done by 
any other means.
     - Cadence is going to post an example to reflector on the usage of 
external branches. Based on those discussions, the syntax and the 
relevant sections detailing hierarchical branches and external branches 
will be documented.

   * Items that need clarification, backward compatibility for existing 
usage
     - usage of analysis() in the RHS of contribution statement (Martin)
     - usage of hierarchical branches as a source (LHS of contribution 
statements)

Regards,
Sri
-- 
Srikanth Chandrasekaran
DTO Tools Development
Freescale Semiconductor Inc.
Ph: +91-120-439 7021 F: x5199