Re: hierarchical parameter passing in DC sweep

Geoffrey,

The internal nodes p and n were introduced for the actual circuit. What 
I've tried to do is to create a generic test bench in Verilog-A in which I 
could then instantiate any module to be tested along with sources and 
loads. The fact that the a and b terminals are there is that a couple of 
simulators do not accept (yet) zero- or one-terminal modules: so these 
terminals are really dummies. For solving the matrix this should not be a 
problem as these separate circuits would correspong to independent 
(block-)diagonal entries. As necessary, one of p and n could be in a 
ground statement, so all nodes in the circuit would then have a defined 
path to ground.

I had hoped to use this as a basis for the validation suite, but it seems 
I need a more down-to-earth approach.

The fact that multiple simulators exhibit this problem seesm to me an 
indication that something is missing from the LRM, even though obvious as 
it may seem to some others. The same goes for my previous ranting on array 
arguments in analog functions.

I readily accept the explanation on Verilog-D - fact is that there is no 
explicit statement either allowing or disallowing it - unless there is 
something to this extent in the Verilog-D standard (and then also in 
System-Verilog?). To prevent differentiation of behaviour in the 
Verilog-AMS simulators, something about this should be added to the LRM, 
probably in chapter 9 on scheduling semantics as the parameter changes 
should only be performed at specific times in the whole simulation cycle.

Marq


Marq Kole
Competence Leader Analog Simulation, Philips ED&T


geoffrey.coram@analog.com wrote on 22-08-2005 17:11:42:

> Marq -
> Why did you introduce internal nodes p and n instead of
> using the driver_dcsweep's terminals a and b?  Aren't
> you then counting on Gmin to prevent a singular matrix,
> since V(p) and V(n) could both be shifted by an 
> arbitrary amount and still give a valid solution?
> 
> 
> Also, why do you view this as a mantis item, rather than
> an error in the implementation in the simulator(s) you're
> using?
> 
> Part of the issue is that traditional Verilog-D simulators
> treat parameters as constants that do not change during
> the (transient) analysis (which is all you can do in
> Verilog-D).  Cadence had some sort of half-baked idea about
> using "dynamicparam" to declare all parameters that were
> allowed to change during a (dc) analysis, which is a huge
> nuisance to analog designers who are used to being able to
> change whatever they want.  It seems to me that, if the
> simulator allows a parameter to change (at top level) during
> a sim, then the simulator must update all references to that
> parameter, and I would view this as an implementation problem.
> 
> -Geoffrey