RE: hierarchical parameter passing in DC sweep

Kevin,
thanks for your feedback.
Comments below.
--Martin


________________________________

	From: Kevin Cameron [mailto:kevin@sonicsinc.com] 
	Sent: Wednesday, August 24, 2005 11:10 AM
	To: Geoffrey.Coram
	Cc: Martin O'Leary; verilog-ams@eda.org
	Subject: 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>];  
	 
	oleary>This might be how a simulator would implement a sweep
analysis but I see the issues not as being there but as being in the
language definition.
	 
	oleary>In terms of using analysis statements to determine which
parameters should be alterable, this does not work very well for
interactive simulators where users can add new analysis statements on
the fly. At this point, it is generally not possible to regenerate
module implementations so that some parameters are not alterable.
	 
	oleary>Furthermore, the dynamicparam proposal does address
another issue; 
	 1) references to global parameters 
	which is very important to analog designers using Verilog-AMS
netlists and may be important to modeler's as well. 
	

	- 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. 
	oleary>That could also work although it would nice to be able to
also have it in the standard for design portability. 
	
	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