Minutes from AMS call of July 26

Verilog-AMS conference call of July 26
Attendees:
Srikanth Chandrasekaran, Freescale
Jon Sanders, Cadence
Shekar Chetput, Cadence
Jim Barby, U Waterloo
Geoffrey Coram, Analog Devices

We reviewed AMS LRM 2.2 draft "f", which is available
on the eda.org web site. We jumped right to section 7,
hierarchical structures, since that was where most of
the changes were, relative to draft "b" that was last
reviewed by the committee.

Section 7.1.2:
* Specifies what constant modules cannot have - no ports, branches etc.
  One suggestion was it was a better way to specify what they can
  actually have. That way when new syntax at module level is added there
  is no need to modify this section.
* Some discussions on how to distinguish constant module. There is no
  keyword to distinguish a constant module. Its has same as a normal
  module with some restrictions specified in the section.
* What if the user specifies delay as part of the initial block -
  would that still be treated as constant module?
* From the example, and the specification it looks like the constant
  module is purely digital? Is that a precondition for constant modules?
* Would it be better to use the "initial_step" analog syntax rather than
  "initial" syntax. There might be some issues with using initial_step also.
  Currently while doing a dcsweep initial_step fires only for the first
  point in the dcsweep. However, the initial_step block will be executed
  for all iterations of the first point. This will be a problem while
  using $random, or $rdist_ functions in initial_step, as the requirement
  for modelling mismatch would be for random to be called only for the
  first iteration and not subsequent iterations.
 
* There was some discussion on reusing the VHDL packages if its already
  been imported in the SV language - to check with Kevin on this.
 
Section 7.3:
* Usage of variables in paramset
- There is a big concern on the way variables are used in the paramset.
  Variables are dynamic expressions and are evaluated only during runtime.
  However paramset needs to be calculated pre-simulation as part of the
  elaboration flow. The current proposal goes against this philosophy by
  introducing a special variable time in paramset which needs to be
  calculated pre-simulation. The variable is used for setting the seed
  using the random function.
- Also the use of OOMR to a variable is also probably not a correct way
  to initialize the parameter inside the paramset block. Variables are
  once again dynamic expressions and wont be the proper way of using them
  to initialize parameters.

* In general, the approach to supporting statistics and Monte-Carlo
  needs work. The main problem is that the $rdist_ functions are not
  constant_expressions (and have an inout argument) that makes them
  unusable for parameter setting. Sri will check with compiler
  experts to see if they have any suggestions.
 
* There is no need for paramset sequential block - it can be removed.

* Some typos in examples - should use "=" rather than parentheses.

* It was confirmed that all parameter values will be separated by ";"
  rather than ",".
 
Section 7.3.1:
* Paramsets may need UDFs (I'm thinking of the BSIM4 geometry calculation
  of AD,AD,PD,PS from L and W, which requires a multi-return-value UDF)
  so UDF definition needs to be added to the paramset syntax.

Next meeting: August 2, 4:30 PM Pacific time.

-- 
Geoffrey J. Coram, Ph.D.    Senior CAD Engineer     
Analog Devices, Inc.        Geoffrey.Coram@analog.com 
804 Woburn St., MS-422,     Tel (781) 937-1924
Wilmington, MA 01887        Fax (781) 937-1014