VerilogAMS Committee Meeting Minutes - 15 December 2003


Subject: VerilogAMS Committee Meeting Minutes - 15 December 2003
From: Chandrasekaran Srikanth-A12788 (Srikanth.Chandrasekaran@motorola.com)
Date: Tue Dec 16 2003 - 17:35:42 PST


Date: 15 Dec 2003, 4:30pm PST.

* Verilog-A extensions to compact modeling was discussed in this meeting. The meeting was to mainly go through the syntax of the proposal to make sure there was no conflict with the BNF updates happening in the AMS committee. The technical details of the proposal are being discussed within the device modelling subcomittee.
* Section 1 of the document "Parameters and Variables" was covered in the meeting.

Reference Document:
Device Modelling Document - http://www.eda.org/verilog-ams/htmlpages/public-docs/Verilog-A_Compact_Model_Extensions.pdf

Section 1.1 - Description & Units:
* There was a concern about the new syntax regarding the "description" for parameters. The suggestion was to do description with attributes instead of introducing a new syntax to the language.
* With regards to units - it was felt that this could be added to the syntax as a string, but also some of the members had the same concern as above, and were of the opinion that units can also be done using attributes.
* Some of these attributes for description can be a standard predefined attributes. Currently the language do not support any standard set of attributes defined as part of the LRM, but there is a possibility that this could be introduced.
* Since the AMS language is common for both digital and analog, any new syntax changes apply to both analog and digital in the new syntax (for the common portions of the language like declarations and other parts). Hence the opinion was to avoid introduction of any new syntax if possible and also new keywords.
* Strings are currently supported in SystemVerilog and 1364-2001 and should probably be resued directly. Also its probably a better idea to sync up with SystemVerilog including all extensions of SV in one shot rather than one feature at a time.

Section 1.2 - Detecting whether a parameter was specified:
* There seems to be no issues with this. $param_given will be an additional analog system task.
* The argument will just be a single parameter rather than a list of parameters.

Section 1.3 - Parameter aliases:
* Instead of introducing a new keyword "alias" to the parameter declaration (parameter alias va = vaf), it was proposed to use "aliasparam" to denote aliased parameters (its likely alias might already be used in existing models)
* Each alias would be on individual declaration lines, with only one parameter reference on the RHS of the parameter declaration.
* The RHS expression has to be an original parameter and not expressions or another alias.
* There can be mulitple aliases created for the same parameter.
* The model equations would be formulated in terms of the original parameter name and the simulator will also check for usage of both original parameter and the alias.
* This feature is useful for dumping out the parameters and also for using different versions of the model where the name of the parameter has changed, but they still refer to the same thing.
* Its not possible to have an alias as well as original parameter by the same name.

Section 1.4 - Output, operating point parameters
* The requirement was to hide certain variables being visible outside. The proposal was to declare all the variables at the top level, and making only those variables visible.
* In the current language standards, all variables are available to be exposed. However vendors hide internal variables due to performance reasons but LRM does allows visibility of all the variables.
* This proposal was not accepted as it has been proposed wherein lot of changes need to be done to existing models.
* This can be a general recommendation to have variables declared at the top but cannot be a requirement of the language.
* Could the same feature be accompolished by the usage of attributes?

Next VerilogAMS Meeting: 5th January 2004, 4:30pm US PST. We will continue with the rest of the sections in the device modelling proposal.

cheers,
Sri

--
Srikanth Chandrasekaran
Global Software Group, EDA
Motorola, Australia
Ph: +61-8-8168 3592 Fax: 3501



This archive was generated by hypermail 2b28 : Tue Dec 16 2003 - 17:36:18 PST