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

Hi all,

Sorry for not scheduling a meeting for today and sending out an agenda. 
I was on leave earlier in the week and hence didnt get it scheduled. 
Apologies to people who dialed in (especially for people from Europe).

The main item i want to discuss next week is the merged P1364-2005-AMS 
syntax. Graham has a syntax that has been merged with the latest digital 
standard (draft8) that we have, and this will get posted to the 
reflector once we resolve some of the minor points in the merged syntax. 
I am hoping to have the LRM committee call next week - same time & day 
and hopefully this would give people enough time to have a look through 
the merged doc. The documentation that will be posted is the Merged BNF 
and merged Keywords section.

Regards,
Sri



Martin O'Leary wrote:

>Are we having a meeting today - if not when is the next meeting? 
>
>-----Original Message-----
>From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
>Behalf Of Sri Chandra
>Sent: Wednesday, September 14, 2005 2:14 AM
>To: Verilog-AMS LRM Committee
>Subject: 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
>
>
>
>  
>

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