Minutes of LRM call- 8th/9th April 2002

Subject: Minutes of LRM call- 8th/9th April 2002
From: Sri Chandra (schandra@asc.corp.mot.com)
Date: Mon Apr 08 2002 - 20:52:10 PDT

Meeting Minutes for LRM Committee call held on 8th/9th April 2002

Attendees: Kevin (National Semiconductor), Jon, Martin (Cadence), Graham, Sri (Motorola),
                   Joe Daniels

Status of various issues being addressed were discussed
Issue 1:
Proposals for removing ambiguity on connect-resolveto as specified in Section 8.7.
(Syntax: connect <discipline_list> resolveto <resolved_discipline>)
Details:
This issue addresses broadly the following problems with the LRM
1. It is not clear whether the resolved discipline is part of the discipline_list
2. LRM does not clearly define how the disciplines are resolved when there is more than one rule that could apply in a situation
3. connect-resolveTo shall not be used to set the disciplines of simulator primitives but only for DR
Status: Resend with recommendation from meeting
There was general agreement on the proposal that was posted. However "Warning" was preferred to "Error" messages when multiple rules could be applied to resolve the discipline. Sri will update the changes and resend the proposal.

Issue 2:
Proposal for reinclusion of digital port names for instantiating digital primitives. This port name shall only be used to create unique instances for a connect module, and to access specific instance. This instance name shall not be used as a mechanism for named port connections while instantiating digital primitives.
Details:
1. Inclusion of port names for digital ports to support instantiation of digital primitives from analog blocks
2. port names shall be used in the "split" case to create unique instances for a connect module and to access a specific instance
3. Port names on digital primitives shall not be used as a mechanism for named port connections while instantiating digital primitives
Status: Closed (LRM to be modified)
Jon has sent a proposal for digital port name inclusion. This has been discussed in the Committee call and was agreed. It was agreed that the 'Naming Mechanism' issue would be treated as a seperate problem and discussed independently.

Issue 3:
Inherited Connection proposal used by Cadence.
Details:
Jon is working on this proposal and would post it to the committee once it is complete.
Status: To be reviewed post 2.1
This issue would not be discussed as part of LRM 2.1, and would be taken up in later revision.

Issue 4:
Overriding default_discipline for the analog/digital primitives on an instance-by-instance basis
Details:
1. The default discipline for analog SPICE primitives would be electrical
2. The default discipline for digital primitives shall be set by `default_discipline as defined in the LRM or a simulator specific option
3. The compiler directive `default_discipline shall only apply to nets in discrete domain and shall not affect nets in continous domain
4. Scope option references from the LRM on default_discipline shall be removed (Section 3.6, 3.7, 11.1)
5. The discipline of spice primitves shall only use the default discipline if the discipline cannot be resolved via other methods as detailed in the proposal
Status: Closed (LRM to be modified)
A proposal had been posted to the LRM committee and has been discussed. Sri/Graham would have a look at item #5, and a closure to be reached in the committee call scheduled for 23rd April.

Issue 5: Reference to derived disciplines in LRM examples without supporting BNF syntax.
Details:
There are reference in the LRM to derived discipline.
Status: Not yet done (will be addressed in 2.1)
The reference to derived discipline would be dropped from the LRM.

Issue 6:
Port vs Process Bound approach for Discipline Resolution.
Status: No activity
Antrim was working on a proposal sometime back but not much has happened recently.

Issue 7:
Proposal for re-writing Section 8.3.2 (4-state logic, X & Z bits access in analog context)
Details:
1. Ambiguity for support of X & Z bits in the continous context
2. Assigning an expression containing X & Z to a branch shall be illegal
3. Assigning an expression containing X & Z bits to a analog variable
Status: Closed (To be modified in LRM)
A proposal rewritting the above mentioned section has been discussed in the LRM calls. A related issue, for support of NaN (Not-A-Number) was also discussed but this would be treated as a seperate issue. Also distinguishing case & if statements based on expressions (digital or analog was identified as a new issue)

Issue 8:
Real valued ports & real net declaration semantics in the LRM.
Status: Post LRM 2.1??
This issue was taken up to be in sync with Verilog++ / System Verilog. Apparently this is not being driven by the Verilog++ committee. Not clear as to how this is going to be addressed.

Issue 9:
Parasitic Back Annotation issue.
Status: Post LRM 2.1??
Proposals have been sent/resent by Kevin in the past.

Note: These issue numbers mentioned above do not reflect the issue numbers in the spreadsheet and are just used for reference between different calls.

Outstanding/New Issues Identified
1. AMS Data & Simulation Model posting by Kevin
"The intention is to define the relationship between the various classes and objects in the "real" world and those required for simulation so that we can bring Verilog-AMS into line with them both." - Quote by Kevin

2. Support for NaN in analog context
This issue has already been submitted by Kevin. This is to deal with support of X & Z assignemts to analog variable and being able to handle them as the hardware supports NaN.

3. Distinguishing case/if statements based on conditional expression
This is partly to do with item #1, to support NaN and be able to treat it in the analog context. A case or an if statement in an analog context should be treated based on the conditional expression. If the conditional expression is digital (containing X & Z expressions) this should be treated as a digital expression and not converted to a real value in the analog context.

Agenda for the Future conference calls
It was decided that the committee should close some of the minor issues identified in the spreadsheet for the LRM 2.1 version before voting. So there has been two conference calls that have been scheduled one to go through the spreadsheet and the other one to follow-up on actions discussed in todays call.

* Conference call on 15 April 2002, 4:30pm (US - PST), ie 16th April 2002, 9:00am (Adelaide time)
   - go through the spreadsheet
* Conference call on 22 April 2002, 4:30pm (US - PST), ie 23rd April 2002, 9:00am (Adelaide time)
   - followup on todays call and close all the open issues/recommendations

Thanks & Regards,
Sri

This archive was generated by hypermail 2b28 : Mon Apr 08 2002 - 20:53:25 PDT