Subject: VerilogAMS Committee Meeting Minutes - 12th Jan 2004 (Device Mode ling Extensions)
From: Chandrasekaran Srikanth-A12788 (Srikanth.Chandrasekaran@motorola.com)
Date: Tue Jan 13 2004 - 18:45:41 PST
Date: 12 Jan 2004, 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 2.x(Functions), Section 3.x(Terminals and Nodes) and Section 4.x(Simulation) 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 2.1: More Flexible Functions
* The proposal to extend analog functions to have inout/output arguments was generally agreed upon. These would be treated as pass-by-reference values.
* The Argument order would be based on the order in which the input/output/inout arguments are declared within the function.
* It will be good to check with SystemVerilog syntax and handling of function for other types of pass-by values also and how it is done in SV.
Section 2.2: Access to Derivatives (ddx)
* This is a derivative to get operating point information, taking in expression and node name as arguments and returns derivative of the expression with respect to the potential of the node (having all other node potentials constant).
* Sematically it will be restricted to have potential of a node rather than a branch for the second argument of the ddx function to make it clear what terminals are held constant.
* ddx is a symbolic partial derivative and is no dependent on timesteps and hence tolerance values do not apply to these derivatives. These will not take tolerance argument and this should be clarified in the documentation.
* Sematics of the first argument, expr, should be clarified in the document. expr, can be any expression that can be contributed on. Digital signals will be viewed as dc type signal.
* There was a suggestion to make the syntax of ddx from an analog operator to a system task ($ddx) to avoid more keywords. It was agreed that it will be kept as a analog operator, consistent with ddt, idt operators. The problem with keywords and converting analog operators as system tasks will be considered seperately.
Section 3.1: Optional Terminals
* It was suggested to use $portConnected instead of $connected to avoid clashes with the IEEE 1364. It was felt that there might be naming clash and it was decided to keep it as $portConnected even if it doesn't clash with digital syntax.
* The instantiation of modules with optional terminals will follow standard Verilog rules.
Section 3.2: Descriptions
* Descriptions of terminal will be made as attributes rather than tha "---" syntax that was proposed. This will also be consitent with suggestion to make parameter, variable descriptions as attributes.
* It will be good to standardize the attribute used, but may not be an easy task. SystemVerilog also probably don't have standardized attributes.
Section 4.1: Non-repetitive warning messages
* Using @(above) to check threshold crossing in dcsweep to avoid repetitive warning messages.
* Cadence mentioned that the design intention of @(above) is to detect the crossing in the dc step handling the initial condition, and its design intention was not for non-repetitive warning messages tho' that seems to be an useful by-product of that feature. The original intention was to avoid if followed by cross in transient steps using a single feature.
* The main issue seems to be the lack of definition of DCSweep in the LRM and its behaviour when it comes to variable remembering its internal state between DC points vs Flushing out every dc timepoint within a DCSweep analysis. Probably most vendors support variables remembering its state between dc points of the same dcsweep analysis.
* The issue of DCSweep is to be taken up by the VerilogAMS committee itself (once again) and this needs to be flused out and documented in the LRM.
Section 4.2: Global simulator parameter access
* Need to clarify the values that second argument of $simparam can take and the type of expression. This will become clear once the BNF is defined. The second argument can take only 0 or 1 value.
* Verilog2001 supports similar functionality $value$plusargs and $test$plusargs to test and check for the values which is similar to the functionality proposed. However the Verilog2001 syntax do not take a 3rd argument.
* The committee was open to the idea of having a similar syntax notation (for ex: $test$simargs/$value$simargs). The committee was also open to having the syntax proposed for AMS to have 3rd argument defining the default value to avoid two systemtasks and unnecessary code.
* The list of standard parameter names along with the description should probably be put in a table similar to Annex E: spice compatibility (probably as an extra table in that chapter). These are the standard names but not restrictive to just these names and the simulator can have access to other parameters that are vendor specific. If simulator uses different standard names then the "aliasParam" could be used.
Section 4.3: Simulator specificity
* Making "Vendor_Product" name as a predefined macro was felt as a good addition for interoperability and porting code. It was discussed whether product version name or LRM version should be introduced as the maco (and support `if and '>' than operator). This was discussed and dismissed because the benefit and how it would be used was unclear.
* It was also felt a macro for device modeling specific syntax (similar to __VAMS_ENABLE__ that exists today) would also be beneficial (__DEVICE_MODEL_EXTN__ ??).
Section 4.4: Convergence aids
* Introduce $limit and $previous system tasks along with a "limiting function". The $limit system task will define the function that needs to be executed to limit the expression. Takes in 3 arguments, expression to be limited, function name as string, followed by other args to the function. So this task takes in variable arguments depending on number of arguments to the function. The first two arguments are mandatory.
* It was felt that the current existing "analog function" could be reused instead of introducing new syntax for limiting function. The two functions are very similar and it was felt that it would be better to extend analog functions to support $previous system task. Analog functions that are used as limiting functions can be distinguished as these would be called from the $limit system task, if they require some semantics different to analog functions.
* It was suggested to swap the first and second argument in the proposal. It was better to have all the arguments to the limiting function coming in the same sequence.
* $previous would give the value of the expression in the previous iteration of the same timepoint(and not the previous timepoint). So this system tasks gives information of some of the internal simulator data. The current version of the LRM does not have any specific syntax/semantics defined with regards to iteration values.
Section 4.5: Diagnosis modes
* Proposal to add $debug to give ability to print for every iteration.
* Currently $strobe gives values at the end of accepted timepoint as per LRM, and since LRM doesn't specifically deal with internal iterations of a timepoint the $display task behaves same as strobe.
* It was felt whether $display task could be used to display the value at every iteration rather than introducing a new system task called $debug. The message will be printed as the statement is encountered and executed.
All the sections/proposals have been covered. The device modelling committee will make necessary changes to the documentation based on the last two meetings and also they are currently working on the BNF/implementation grammer to more clearly define the syntax and semantics of the proposed extensions. The updated documented will be put on the eda.org website at the above mentioned site.
Next VerilogAMS Meeting: 19th January 2004, 4:30pm US PST to take up the rest of the BNF syntax work that's been happening in the committee.
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 Jan 13 2004 - 18:46:15 PST