Minutes of LRM Committee Meeting - Sept 13/14th 2005

Attendees:
Marq Kole (Philips)
Jim Barby (Uni. of Waterloo)
Geoffrey Coram (Analog Devices)
Ilya Yusim (Cadence)
Prasanna Tamhankar (Freescale)
Martin O'leary (Cadence)
Sri Chandra (Freescale)
Kevin Cameron (Sonics Inc)
Graham Helwig (Freescale)

Recent Updates
  * Accellera received approval from IEEE for using 2005 for AMS LRM 2.3 
edit purposes. Johny has sent a version.
  * Graham will try to do the same updates for Chapter 10 (as was done 
with one of the earlier draft versions with the latest std which can be 
used as the starting point)

Verilog-AMS/Spice translation and testbench for Verilog-AMS
  * These items were discussed at last meeting. The resolution was to 
look at both of these efforts outside the current scope of the AMS 
committee.
  * It was agreed that the testbench for Verilog-AMS will prove very 
useful in verifying adherence to standards and interoperability.


Mantis database tickets:

  * 867: Error in section 6.6.2 will be addressed. This is just a minor 
correction on specifying the width that is syntactically correct (left 
of identifier) and will be addressed as part of LRM2.3

  * 868: Parameter declaration inside analog function. This is allowed 
as per BNF, Marq felt might be good to clarify with example.
    - LRM makes a reference in analog function section saying UDF will 
reference only local variables defined in that scope.
    - Not very clear whether this refers to just "variable identifiers" 
defined inside UDF or also parameters
    - There is a school of thought where parameters are seen as global 
to module scope and hence UDF can reference parameters at module scope. 
If parameter with same name exists in UDF scope, then the local scope 
will be taken
    - This needs to be clarified in LRM2.3

  * 869: Array arguments for UDF
    - This is defined in BNF but was felt to be useful to give example 
and clarify in the section

  * 870: BNF for analog UDF port declarations in section 4.6.1 refers 
digital
    - This is accepted and will be resolved as part of LRM2.3

  * 874: Usage of vsource. Table E.2 describes set of parameters, and it 
is implicitly assumed to be for vsrc
    - The consensus for the committee will be to drop Table E.2 from the 
Annex and merge this with Table E.1 (details of parameter names etc)
    - There is no need for vsrc as the individual vX are already present 
- vsine, vpwl, vexp etc
    - Also the way the syntax is currently defined for vsrc this doesnt 
fit the AMS syntax description.

  * Conflict in array range between inout declaration and electrical 
declaration.
    - If they are differing width it will be an error.
    - With regards to same width but LSB/MSB swapped - after some 
discussion (just to honour inout of port connectivity) it was agreed to 
flag this as an error.
    - With regards to string match vs expression match (ie. inout [0:P] 
neta; electrical [0:3] neta; where P=3) it was felt that compiler can 
error out based on string match results instead of requiring elaboration 
to resolve value of P. Nobody felt that there was a need why one of them 
would be a constant expression and other parameter tho' they resolved to 
the same value.
 
  * Discussion on param arrays support in AMS
    - [Joined in bit late into the call, hence unable to minute it]
 
  * $node_collapse
    - This was discussed as part of Device Modeling committee and was 
dropped as a required feature at language level as the simulator can 
handle this internally.
    - This is often done in compact models through a short (0 voltage 
source) if the nodes can be collapsed.
    - It was felt adding the feature may result in more work for 
simulator as it had to still check for the validity of collapsing the 
nodes (and) hence may also be error prone.
    - Lead to discussions about supporting if-else blocks at the 
structural level and instantiating different modules & different 
structural net declarations based on conditional statements outside the 
analog block scope. This will be available as part of inheriting 
1364-2005, but also may require support for multiple analog blocks.
    - Graham will send out an example detailing this to the committee 
reflector.
 

Next week:
  * Any new tickets that are raised in Mantis to make sure recent issues 
are discussed
  * Also will go through where we left off in resolving 
critical/high/low prioritization on existing tickets
  * It will also be good to start discussing proposals that are 
available for any of the tickets that have already been accepted as 
critical for LRM2.3 instead of waiting for all tickets to be prioritized.

cheers,
Sri

-- 
Srikanth Chandrasekaran
Design Technology (Adelaide)
Freescale Semiconductor
Ph: +61-(0)8-8168 3592 Fax: x3201