Subject: VerilogAMS LRM Committee Meeting Minutes - 19 Jan 2004
From: Chandrasekaran Srikanth-A12788 (Srikanth.Chandrasekaran@motorola.com)
Date: Wed Jan 21 2004 - 23:37:14 PST
Date: 19 Jan 2004, 4:30pm PST.
* The changes to the BNF under section A.9.1 (Attributes), A.9.2 (Comments), A.9.3 (Identifiers), A.9.4(Identifier Branches), A.9.5(White Space) were covered.
Reference Document:
BNF Doc: http://www.eda.org/verilog-ams/htmlpages/public-docs/syntax_2_1_updated.pdf
Please see detailed minutes below:
Section A.9.1 (Attributes)
* The attribute syntax has been sync'ed up with 2001 and its same as attributes in 1364.
* The LRM2.1 reference has "integer_decl" as part of the attribute syntax in it (Section E.3.3.1) as part of supporting spice syntax. This will be removed to make the attributes consistent with digital and Section E will be updated to reflect this.
Section A.9.2 (Comments)
* Same as 2001 syntax.
Section A. 9.3 (Identifiers)
* analog_block_identifier same as block_identifier in digital syntax
* alg_func_identifier same as function_identifier in digital syntax.
* alg_systemTask_identifier - The draft version differentiates analog system task and digital system task. The reason is that they used to allow different character sets. Analog didn't allow use of numbers as first character and usage of "$" as part of system task which digital allows. It was recommended to allow these in analog and merge digital and analog into one.
* alg_sysFunction_identifier - Same as above. combine analog and digital.
* analysis identifier - an indentifier has been created for analysis instead of hardwired keywords like "op", "ac" etc. This identifier is restricted to be a string in the BNF - refer analysis_fn_call syntax.
* Branch identifier - made branches as identifier in new syntax
* connect module/discipline/nature identifier - made as identifiers
* simple, escaped identifier - made same as 2001.
* Nature_Attr_identifier (predefined and userdefined) - Some of the syntax in nature is treated as keywords - units, abstol, ddt_nature, idt_nature and access are treated as keywords in the language. This will be kept the same.
Section A.9.4 (Identifier Branches)
* No change
Section A.9.5 (White Space)
* End of line (eol) is part of white space.
* formfeed can be removed from the current draft version because formfeed has become part of the eol syntax.
Long range plans before next version with new syntax:
* The BNF updates review has been done. Now these reviews have to be incorporated into the individual sections and all the sections updated to reflect new syntax.
* Its quite likely that an intermediate LRM version will be released with the device modeling updates before the new syntax version is released.
* The updated BNF version might be released as a separate version after the device modeling updates and the following items would also be addressed as part of that version release.
- DCSweep behaviour
- Incorporating $table_model functions as part of the LRM
- IC analysis for mixed signal
cheers,
Sri
* There is no need to have digital_mintypmax_expression as part of analog primary. This was there in LRM2.1 version but there doesn't seem to be any use of this syntax in analog context.
* constant_primary has been merged between analog & digital. However, specparam, const_mintypmax and constant function call would be semantically restricted in the analog context.
* branch_probe_function_call and port_probe_function_call has been added to analog primary. These are extensions in the digital language to support mixed signal syntax of probing analog nets in digital.
* no changes to module_path_primary
Section A.8.5 (Expression left-side values)
* the variable identifier must be a local
* supports scalar or scalar element of vector with the index expression being dynamic expression also.
* Filter function calls will be semantically restricted as part of dynamic expression usage in indexing.
* Hierarchical variable references will be restricted on the analog side. Supporting hierarchical reference will lead to ambiguities and race conditions since analog blocks are computed as parallel processes. Hierarchical reference of variable is supported on digital side.
* bvalue has been renamed as branch_lvalue to be consistent with the rest of the documentation in the BNF.
Section A.8.6 (Operators)
* Currently, as per the updated syntax, analog unary operators is a subset of the digital unary operator
* Same with digital binary operators with exception of >>> and <<< operators (arithmetic shift operators in digital) [With regards to ~& and ~| the current documentation in LRM2.1 does not make any mention of these and should be part of unary operators]
* The general consensus was that the unary and binary operators between analog and digital would be merged. There is no requirement to differentiate the two. The next revision would be updated to reflect this. Any operators that are applicable only the digital side would be restricted semantically and these would be handled by the individual simulation tools.
* X & Z states would be handled by the use of 4-state logic on the analog context.
* Support of ** notation for power (and deprecate pow). This was suggested to be included to reduce the number of keywords.
Section A.8.7 (Numbers)
* The number syntax has been merged between digital and analog with extension of scale factor to the 2001 sytnax which will be used as part of real_number.
* The syntax of 'sign' which was used in decimal and real number in LRM2.1 has changed. 'sign' will only be used as part of 'exp' syntax in the new BNF.
* The old notation of using 'sign' in analog would now be treated as an unary '+' or '-' operator.
* Question: Should scale factors be allowed in the digital context. The consensus was that the language spec should allow the syntax and this may be semantically restricted in digital side. Also semantic restriction of scale factors in delay specification - part of assignment statements.
Section A.8.8 (Strings)
* No change.
* There was a request from device modelling committee with regards to consideration of unicode to support characters from other languages. It was felt that this would be referred to the IEEE 1364 committee.
Section A.8.9 (Analog References)
* Semantic restriction of accessing idt_nature and ddt_nature has been put in place. The return values are expected to be real/int.
* Need to update the new documentation to also restrict accessing of "access" function of nature.
* Only accessing of abstol value and units string and user defined attributes will be supported.
* There was a suggestion of removing analog_port_reference and just use analog_net_reference in the BNF. Currently analog_port_reference is used by the port_probe_function_call syntax. It was decided to leave this as is, as per the current documentation.
* Hierarchical access would be restricted in the analog_port_reference syntax.
* Question: Should hierarchical reference be allowed for analog_net_reference? Currently this is restricted. Allowing this is a bigger change (but is felt might be required) to support OOMR. But this might have impact on discipline resolution also. Currrently no change is going to be done on the updated syntax documentation with regards to this until a proposal with impact on discipline resolution is worked out.
* Question: (same as above) Should hierarchical branch references be supported? Currently the identifier in analog context is not hierarchical.
* The real_identifier in variable_reference refers to the digital variables.
* Net_references - access of digital nets in analog blocks can be scalar, vector, bitselect and part select. Net references are discrete nets only.
* If hierarchical nets are used it has to be digital nets. Its like a coercion of the net to digital discipline of the net is undeclared. The section "Discipline of wires in undeclared nets" (section 3.4.2.4) in LRM2.1 needs to be updated.
Meeting over the Holiday Period:
* There will be a meeting on the 15th of decemeber. The AMS committee will go over the features that are planned to be proposed by the device modelling committee (the document is still under review by the device modelling committee). This is just to check for potential conflicts and resolutions if any exists between the changes in AMS and those proposed by device modelling committee.
* The next AMS meeting will be held on the 5th of January continuing on the changes of the BNF.
Next Call: 15th December 2003, 4:30pm PST. Agenda will be sent out soon.
cheers,
Sri
-- Srikanth Chandrasekaran Global Software Group, EDA Motorola, Australia Ph: +61-8-8168 3592 Fax: 3501
This archive was generated by hypermail 2b28 : Wed Jan 21 2004 - 23:41:28 PST