Re: hierarchical parameter passing in DC sweep

I agree with Geoffrey: dynamicparam is a bit redundant, you can tell 
that a param/genvar needs to be sweepable if it is used in some kind of 
sweep statement, i.e. I think you would be better off using something like:

   sweep <OOMR> [<sweep range>] [ = <local alias>];

- then it doesn't matter if defparam is deprecated and you'll be able to 
use it with old code.

Not sure what the semantics/syntax of <sweep range> should be, but 
something for doing a +/- range from the elaborated value would be nice. 
The local alias is a shorthand for directly assigning the value from 
testbench code. E.g.:

  sweep fuse_block[12].fuse (10,1e8) = f12; // resistive fuse (ok or blown)

  initial_step (...) begin
    f12 = 4000; // partial blow
    ...

If you need to know a param is sweepable for pre-compilation I'd do that 
outside the language since there is no standard for compiled code 
interfaces (yet), but you can always add attributes in the source.

Kev.

Geoffrey.Coram wrote:

>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.
>
>
>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?
>
>
>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?
>
>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.)
>
>
>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.
>
>-Geoffrey
>
>  
>