Re: hierarchical parameter passing in DC sweep

Geoffrey,

> > 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 believe that you do need one of {p,n} to be ground, and you also need
> the terminals "a" and "b" to be connected somehow to ground in your
> simulator netlist.  Else there are multiple solutions to the circuit,
> which is the same as having a singular matrix.  (If you have a solution
> (V(p), V(n)), then (V(p)+5,V(n)+5) is also a solution.)
> 
You're right, but a ground statement should solve that for the p,n branch,
while the a,b branch in this case was connected to a grounded voltage 
source
and a resistor - essentially all necessary requirements for solution were
accounted for.

> > I had hoped to use this as a basis for the validation suite, but it
> > seems I need a more down-to-earth approach.
> 
> I also think you'll find your approach too limiting for a complete
> validation suite: you can't get small-signal results from inside
> the Verilog-A module.  Many problems I've seen result from bad
> derivatives.
>
It would have worked quite nicely for DC, DCsweep, and transient; the 
noise
and AC could have been handled by less independent means as these are only
small test cases. The fact that the files that contain the output values
are completely independent of the output syntax of any particular 
simulator
makes this approach - or a variation thereof - extremely suitable for
automated validation.

> > 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.
> 
> I found this statement in the SV-3.1a LRM (section 21.2 on page 327,
> or page 343 of the PDF):
> 
>   A module, interface, program or class can have parameters, which are
>   set during elaboration and are constant during simulation.
> 
> Or in 1364-2001 (section 3.11):
> 
>   Parameters are not variables, they are constants.
> 
>   Parameters represent constants; hence, it is illegal to modify their
>   value at runtime.
> 
> 
> But, as I said before, this is terribly restrictive for analog
> designers: can you imagine never being able to sweep the supply
> voltage -- after all, the dc value of the voltage source is a
> parameter, and hence "must" be constant according to 1364.
> 
> Every Spice-like simulator I know that supports Verilog-A allows V-A
> parameters to be swept in the same manner that parameters of built-in
> primitives can be swept.  I have not done much with hierarchical
> instantiation of V-A modules within other V-A modules -- my V-A modules
> usually look like primitives (V-A compact modeling).
> 
For the top-level parameters that is true: it appears much less true for
parameter passing. It was also the first time I tried to pass down a
parameter from the top-level (Spice) environment to a module instance
inside Verilog-A. I think it is at least established that this is an issue
that needs to be addressed in the Verilog-AMS LRM.

> -Geoffrey