Re: Minutes from AMS call of July 26

Geoffrey.Coram wrote:

>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.
>
What's the rationale for this stuff? - it looks unnecessary to me.

See SV "program blocks".

>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.
>
>
I still think you would be better reconsidering the paramset syntax, and
just doing it as a module definition with inheritance: if you keep
adding more stuff to it, it will end up looking like a module anyway.
This is similar to the problem of "interfaces" in SV where there is a
huge semantic overlap between interfaces and modules, but the different
syntax (and arbitrary rules) makes the language awkward to use when
doing top-down design refinement.

SV supports pass-by-reference which allows multiple returns.

Kev.

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

-- 
Altera Corp, 101 Innovation Drv, San Jose, CA 95134. T# (408) 544 7126