Subject: Minutes of Jan 15th AMS Committee Conference Call
From: Srikanth Chandrasekaran (schandra@asc.corp.mot.com)
Date: Mon Jan 14 2002 - 19:46:39 PST
Attendees: Jon, Martin (Cadence), Kevin (NSC), Sri, Graham (Motorola)
Date: 14th Jan, 3:30pm, US PST.
* Status on "Accessing of discrete nets in continous context" proposal
- The proposal would be sent by the end of the week. Just required some
clarifications as to what was discussed when this issue was taken up about
6 weeks back.
Action (Sri): To complete write up and post it by end of week.
* Issue with using port names for instantiating digital primitives
- Currently LRM does not support digital primitives to be instantiated from
an AMS module.
- This would require having to define port names for digital primitive ports
since the "split" case in discipline resolution where a connect module is
instantiated for each port is created with instance name
"SigName__InstName__PortName"
- However digital primitives do not have any concept of port names
- The LRM would limit the use of these port names
1. The port names shall only be used for creating unique instance names
and for accessing a specific instance (say for example overiding parameter
value using 'defparam' statement).
2. Named Port Connections shall be disallowed while instantiating a
digital primitive. Digital primitives shall have to be instantiated using
ordered connections
Action (Sri): The appropriate LRM section would be modified to capture the
above two points on digital primitive instantiation
* Disussion on Section 8.7.2, which states that the discipline_list specified
in connect-resolveTo statement have to be compatible.
connect <discipline_list> resolveTo <discipline>
- There was a lot of debate on this with regards to "Port vs Process" bound
approaches in relation to discipline resolution.
- It was agreed that there may not be a need for having the restriction.
Infact it would be useful in cases where a top level module instantiates a
digital block with an implicit net at top level connected to digital port,
and the same top level instantiates an analog block where the implicit net
is connected to a continous port.
Action (Sri/Graham): To send a list of examples and a proposal to remove the
restriction on the "connect-resolveTo" syntax
* Inherited Connection Proposal used by Cadence
- Jon has discussed that with Cadence management with regards to presenting
this proposal used within cadence with respect to patent etc
- Looks like there may not be any issues with this, and Jon would be posting
the Inherited Connections Proposal to the AMS committee
Action (Jon): To send this the AMS committee mailing list
* Proposal on disciplines of analog primitives using compiler directives
DEFAULT_ANALOG_PRIMITIVE & DEFAULT_DIGITAL_PRIMITIVE
- Martin & Jon are working on a proposal that gives the ability to override
the default_discipline on an instance-by-instance basis. However this may
not use the compiler directives as was discussed earlier
- Also Kevin discussed the possibility of using similar capability like C++
override methods using Module overriding.
Action (Martin/Kevin): To post their respective proposals which would be
discussed further in the next committee call
* Discussions on some ambigous & incomplete specifications on the LRM
- Currently it is not clear with connect-resolveTo statement whether the
resolved disciplines have to be one of the disciplines in the list
specified
connect x1 x2 x3 resolveTo y; Should y be one of x1, x2, x3??
- Also does it imply subsets also fulfil the same rule statements.
connect cmos1 cmos2 cmos3 resolveTo cmos1;
Is it implied by the above statement that a connection between cmos2 and
cmos3 (subset of above) would resolve to cmos1?
- If there are two rules
connect cmos1 cmos2 cmos3 resolveto cmos1
connect cmos1 cmos3 resolveto cmos3
Which rule applies for a connection between cmos1 & cmos3? The LRM is
ambigous on this.
Action (Sri): To send a posting on the above issues to the committee and also
any possible suggestions on resolving the same. This will be
discussed in the next committee call.
* What happened to Derived Disciplines?
- There is an example in Section 3.8 which gives an example with derived
disciplines. However there is no BNF to support this.
- It was discussed that this part of some legacy verilog-a std definition
pre LRM1.0 version. The example would be modified in the LRM to remove
this ambiguity.
Next AMS Committee Call: 28th Jan, 3:30pm, US PST.
-----------------------
cheers,
Sri
-- Srikanth Chandrasekaran Global Software Group, EDA SBU Motorola Australia. Phone: +61-8-8168 3592 Fax: x3501 email: schandra@asc.corp.mot.com
This archive was generated by hypermail 2b28 : Mon Jan 14 2002 - 19:55:00 PST