Minutes of discussions on Chapter 6 (reviewed till 6.3.1)

Date: 15th June, 3pm, US Pacific

Attendees:
Geoffrey Coram, Analog Devices
Graham Helwig, ASTC
Jim Barby, Uni of Waterloo
Martin O'leary, Cadence
David Miller, Freescale
Patrick O'Halloran, Tiburon
Boris Troyanovsky, Tiburon
Peter Liebmann, Xpedion
Sri Chandra, Freescale

* Discussion on constant expression vs analog constant expression
  - option 1: Leave syntax as is, and semantic restrict where analysis 
functions cannot be used in the language. It was felt that this wasnt a 
very clean option as it required to document the semantics everywhere.
  - option 2: Create analog constant expression which includes analysis 
function; analog expression also needs to be updated with analysis 
function in the BNF. This also has similar problems as option 1. The way 
the BNF is structed, analog block uses analog expressions for 
conditionals which necessitates the inclusion of analysis() as part of 
that. Once again we need to document all the restrictions where analog 
expressions are used to state whether analysis() can be allowed or not 
(for ex: cannot be used as RHS in contribution etc)
  - option 3: Create analog constant expression and create duplicate 
syntax for the statements that may use analysis function. One thought is 
that the places where analysis is required is smaller in number 
(conditionals, case and loop), so duplicate constant versions of these 
can be created. Duplicates the syntax but may be bit cleaner to detail 
in the LRM
  - Graham will try out some of the options above and make a proposal 
that can be discussed during the next call

* Discussion on support of port branch syntax as source branches 
(extending the syntax from probe to source)
  - Unclear as to what contribution to V(<d>) exactly means
  - Should it mean to refer to V(d,gnd)? Geoffrey was concerned that 
this is already handled by current syntax and no point having different 
means to do the same.
  - Referencing V(<d>) to mean V(d,gnd) does not fit in with what Ken 
was requesting as per the example he has stated.
  - Best to keep the restriction in the language if we are unable to 
define the semantics and usage of the different forms that are allowed.
  - Geoffrey has sent an email in response to Ken's request with the 
above issues stated; proceed further based on the discussions that evolve

* Review of chapter 6 (next review of this chapter starts from 6.3.1.1)
  - Explicitly state blocking events in paragraph #2 of section 6.1
  - (Mantis item) Need to raise a mantis item for support of multiple 
analog blocks in a module: this request has already raised by Kevin for 
supporting multi-rate and also by Graham to be able to incorporate the 
1364-2005 generate block construct with AMS
  - Grammatical correction on paragraph 3 in section 6.1
  - Consistently use shall as a way of formally describing some of the 
rules of the language
  - Rephrase first sentence of paragraph1 on section 6.2 with regards to 
block statements
  - (check with 1364-2005) How does digital handle parameter override 
for parameters declared within a named block? From 1364 defintion it 
looks like this is allowed however semantics are not clearly specified. 
Is it based on the order in which parameters are declared at module 
scope and block scope? Graham was suggesting whether parameter 
declarations inside named blocks be restricted to localparams in which 
case the override issue disappears.
  - Change from "two analog nets" to "one or more analog nets" while 
describing the mathematical relationship between nets described through 
contribution operator in section 6.3.1
  - Cross references section 3.4 about disciplines and natures while 
refering to V & I in the example on section 6.3.1

* Next review of chapter 6 will be taken up from Section 6.3.1

* Change in time for subsequent calls
  - So India time zone needs to be added the current Verilog-AMS LRM 
call time needs to be changed as the current call time is 3:30am in India.
  - Need to suggest an alternative taking into account different 
timezones in US, netherlands, noida, and adelaide. Currently Marq is 
attending the calls late in the night with Australia being early in the 
morning.
  - To suggest some alternative times; however it would be late 
evening/night in some part of the world.

* Next call:
  - Cadence will not be able to open the call for next week; so the next 
call will be in a fortnight
  - Call scheduled for June 27th US, time to be decided.

Regards,
Sri

-- 
Srikanth Chandrasekaran
DTO, Tools Group
Freescale Semiconductors Inc.
Ph: +61-(0)8-8168 3592 Fax: x3201