RE: hierarchical parameter passing in DC sweep

Geoffrey,
thanks for reading over the proposal and sending feedback.

To set expectations I don't want to characterize this proposal for a
complete solution to all parameter altered problem but as this proposal
is attempting to resolve some problems in this area and conveyed some
issues involved I would like to make it part of the discussion.

Also the proposal was largely develop in '01, '02 and is outdated in
some regards.

Further comments below.
Thanks,
--Martin

-----Original Message-----
From: geoffrey.coram@analog.com [mailto:geoffrey.coram@analog.com] 
Sent: Wednesday, August 24, 2005 6:18 AM
To: Martin O'Leary
Cc: verilog-ams@eda.org
Subject: Re: hierarchical parameter passing in DC sweep

Martin -

> FYI - I have uploaded the dynamic parameter proposal to the DB in
issue 814.

I see the following statement in the proposal:
    The dynamic parameters are set once before the start of an analysis,
and
    are then constant during the simulation of the analysis.

This seems to prohibit a dc sweep of a dynamicparam, which was a big
part of the motivation.

oleary>I agree with this point. As mentioned above the proposal as it
stands is not a solution for everything and doesn't at this point
consider dc Sweeps but is more focused on multiple transient analyses.
My intended definition is that dynamic parameters can be altered at the
points in a simulation cycle at which spice parameters can be altered in
a spice simulator.
Therefore by changing the definition that you quote in the proposal to
one that matches the spice parameter altering, I feel the dc sweep case
could be covered.


I also think it's a nuisance to have to declare dynamicparams for
compact models.  It's the sort of thing that a model writer should not
have to think about: what might the analog circuit designer / compact
model user want to vary?  L and W for sure, VTH likely, and possibly
anything else -- particularly if the user is a characterization engineer
trying to fit to data.
If the module is in a read-only location, or provided pre- compiled or
encrypted, what is the user to do?

oleary>A key part of the proposal is that the "dynamic" quality of a
parameter can be inherited from above to quote;

  * Simulators may support a mechanism to change dynamic parameters
    at the start of a simulation/analysis without having to edit
    a design.

    In this case all parameter values dependent on the dynamic parameter
    will be recalculated.

oleary> Therefore the modeller does not need to worry about declaring a
dynamic parameter.
The circuit designer would just need to ensure that the global
parameters are declared as dynamicparams when they are netlisted.

oleary> The essential reason for selectively making parameters dynamic
(or alterable) is that we don't want to slow down the simulation of
regular verilog in a Verilog-AMS simulation.

It also seems to me that all the Spice-like simulators that support
Verilog-A allow standard "parameters" to be varied.
(I haven't been able to reproduce Marq's problem with simulators I have
access to.)  Is "dynamicparam" a solution looking for a problem?

oleary>The standard could say that parameters defined in Spice are
considered as dynamic parameters from the point of view of a Verilog-A
model. Therefore the dynamic quality would be inherited.

oleary>This brings up the interesting question about whether the
standard should have anything to say about instantiating Verilog-A in
SPICE. My personal take is that there might be some need to do this but
we should be very careful that we don't get into the business of
defining Spice.

If the simulator supports dc sweeps, then the Verilog-A compiler should
be able to set up dependency trees and figure out which computations
need to be done once per sim, once per dc point, or every iteration.  If
it only supports transient, then it is free to optimize parameters as
constants just as Verilog-D simulators do now.  (Your proposal does add
one new feature, multiple transient analyses in one simulation with
different values of a dynamicparam, without re-netlisting/
re-elaborating.  But I haven't heard anyone on the Verilog-D side
requesting this feature.  Probably, if you want multiple transient
analyses, it's faster to generate two netlists and run the analyses on
two compute farm machines.)

oleary>yes Verilog-D users are not interested in this in my experience -
however more analog centric AMS users are very interested in this
capability.

Another secondary concern is that SystemVerilog has a sentence to the
effect that defparam may be deprecated in the next version, but your
proposal requires defparam to allow dynamicparams to affect other
modules through OOMRs.

oleary>I accept this - the proposal is old and this aspect should be
reworked. The reason for taking this approach was to get around a
Verilog restriction on parameter initializers (which are not allowed to
have OOMR references). This restriction mades it difficult to map a
common Spice usage (having global parameter references in parameter
defaults) into Verilog-AMS.

-Geoffrey