Switch Branches

[Geoffrey]

Switch branches is the name given to Verilog-A constructs such as this

if ( condition )
V(branch) <+ vval;
else
I(branch) <+ ival;

In compact models, switch branches are often used for parasitic
resistors that may or may not be present:

if ( RS > 0 )
V(br_rs) <+ 0;
else
I(br_rs) <+ V(br_rs) / RS;

There are a few considerations:

1) Some compilers are unable to "collapse" internal nodes, and thus
adding a switch branch will increase the matrix size by 2 (one for the
extra node, and another for the branch current of the "voltage
source"). The source code for BSIM6 beta uses an `ifdef to enable
some internal nodes.

2) Some compilers are unable to collapse internal nodes unless the
condition depends only on parameters and constants. The above example
would be OK, assuming RS is a parameter.

3) Some compilers can collapse internal nodes properly, even if the
condition depends on variables, as long as the variables themselves
depend only on parameters and constants (and not on the voltages).
For example, one might have
RS_t = RS * ( 1.0 + TC1 * ($temperature - TNOM - `P_CELSIUS0) );
(where RS, TC1, and TNOM are parameters) and then the condition would
be
if ( RS_t > 0 )
The BSIM bulk models have a complicated calculation of the drain and
source resistance, depending on NRD, NRS, RDSMOD, RSH, etc.


Question for discussion: what restrictions, if any, should we place on
the use of switch branches?

[Alfredo Piazza]

What restrictions, if any, should we place on
the use of switch branches?

The condition must be voltage independent.

[Geoffrey Coram]

I agree, and I think that is the only restriction we need to place.

[rdk]

I think the condition should only depend upon parameters. My reasoning
is that parameters are by definition constant, and so the dependency
will always be valid. A constant-valued variable requires some
dependency analysis to verify, making it more difficult to place an
error message at the point of error in the input stream. Additionally,
there is no added functionality by extending the dependency to
constant-valued variables.

[Geoffrey Coram]

Perhaps it's no added functionality, but it can sure decrease the
complexity. I grabbed this from the BSIM4 source code:

/* process drain series resistance */
createNode = 0;
if ( (model->BSIM4rdsMod != 0)
|| (model->BSIM4tnoiMod != 0 &&
noiseAnalGiven))
{
createNode = 1;
} else if (model->BSIM4sheetResistance > 0)
{
if (here->BSIM4drainSquaresGiven
&& here->BSIM4drainSquares > 0)
{
createNode = 1;
} else if (!here->BSIM4drainSquaresGiven
&& (here->BSIM4rgeoMod != 0))
{
BSIM4RdseffGeo(here->BSIM4nf, here-
>BSIM4geoMod,
here->BSIM4rgeoMod, here->BSIM4min,
here->BSIM4w, model-
>BSIM4sheetResistance,
DMCGeff, DMCIeff, DMDGeff, 0,
&Rtot);
if(Rtot > 0)
createNode = 1;
}
}

What would the if condition look like if you tried to write it only in
terms of parameters? (Ignoring, for the time being, the analysis
dependence for tnoimod.)

if (RDSMOD != 0 || TNOIMOD != 0 || (RSH > 0 && (($param_given(NRD) &&
NRD > 0) || ($param_given(NRD) == 0 && RGEOMOD != 0 && ??))) )

I can't tell by quick inspection if BSIM4RdseffGeo could return 0 for
"reasonable" parameters.


If you're not doing a dependency analysis, I would think your
implementation is going to suffer in other ways.

[rdk]

On Aug 16, 2:34 pm, Geoffrey Coram <geoffrey.co...@analog.com> wrote:

> What would the if condition look like if you tried to write it only in
> terms of parameters?

It would like pretty much the same. Take a look at the localparam
keyword, defined in section 3.4.5 of the 2009 LRM. A local param is a
special subclass of constant variable, i.e. it depends only upon
parameters (and other local params).

> If you're not doing a dependency analysis, I would think your
> implementation is going to suffer in other ways.

I'm going to do a dependency analysis... But it is much cleaner to
report errors at the point where they occur in the input stream,
rather than after additional analysis. Some conditions can only be
detected in the latter fashion, but that is not a preferred situation.

[Geoffrey Coram]

EDA vendors/compiler makers: how complete are your implementations
of "localparam"?

I agree that localparam could be used to handle some conditions:

localparam do_rd = (TNOIMOD != 0 || RDSMOD != 0
|| ($param_given(NRD) && NRD > 0 && RSH > 0)
|| (!$param_given(NRD) && RGEOMOD != 0) );

(I would hope that compilers accept $param_given(nrd) in the
localparam expression.)

I don't know about the RGEOMOD equations, and whether it's
reasonable to require them to return a non-zero value when
RGEOMOD != 0.

I don't understand your concern about error reporting. I'd want the
error message to cite the line of the if() statement, and the only
difference I see between our two proposals is in the text of the message:
*ERROR*, line 999: switch branch depends on bias-dependent variable
versus
*ERROR*, line 999: switch branch depends on variable (not parameter)

[rdk]

On Aug 16, 2:48 pm, rdk <aardqu...@gmail.com> wrote:
> It would like pretty much the same. Take a look at the localparam
> keyword, defined in section 3.4.5 of the 2009 LRM. A local param is a
> special subclass of constant variable, i.e. it depends only upon
> parameters (and other local params).

To elaborate on why I am in favor of conditioning switch branching on
parameters and localparams, rather than the wider class of constant-
valued variables...

Consider the localparam feature itself. Why did the Verilog-A language
designers add this to the language? After all, a localparam cannot be
overridden from outside the module, i.e. it is not really a
"parameter", what it is is a constant-valued expression than can
depend only upon parameters. Why then did they choose to add this to
the language? Why not say "we can just use constant-valued variables
to realize this feature"? The difference is subtle, but it is there,
and the difference is important enough for them to justify adding a
new definition class to the language.

The difference is that a localparam will always satisfy the
requirement that it value is constant throughout the entire body of
the module. It is guaranteed to do so, because it can only depend upon
parameters and localparams, whose value assigns do not appear in the
body of the analog block. The same cannot be said for constant-valued
variables. A given variable may change dependency type because its
definition was changed. In fact, it may still be classed with the
constants (i.e. non time-dependent, non state-dependent), but still be
reassigned to different values at different points in the module.

The property of being a single constant value is an inherent property
of parameters and localparams. Variables are not guaranteed to have
such a property. As such, I think it is a better choice to condition
switch branches upon parameters and localparams. Having done so, I
need never go back and consider the chain of dependencies for
validity. They will always satisfy the condition that they have an
unchanging value throughout the module. No change in the value or
expression assigned to a parameter or localparam can change this
property.

[Geoffrey Coram]

rdk wrote:
>
> Consider the localparam feature itself. Why did the Verilog-A language
> designers add this to the language?

I wouldn't read too much into this -- it was actually the IEEE 1364
(digital) Verilog people who added localparam to the language.
In (digital) Verilog, parameters (and hence localparams) are constants
set at elaboration time, and there is no concept of a "dc sweep" --
parameters cannot be changed during a simulation at all!

-Geoffrey

[Geoffrey Coram]

I certainly agree that using parameters/localparams would be easier
from a compiler/simulator standpoint.

I'm not convinced that this is sufficient an argument for imposing
the burden on all model writers, that they conform their style to
using localparam.

Are all simulators able to accept the syntax below? (Note the use
of $param_given, $temperature, and $simparam in the localparam lines.)

(I found one commercial simulator that did not like $param_given
in the default expression.)

I suspect we have come to a place where we need to take a
straw poll.

I'm also interested to know if there are any other issues we
should be considering. It's not much of a "set of recommendations"
if we have only one thing to say, on switch branches.

-Geoffrey

module resform(a,b);
inout a, b;
electrical a, b;

parameter real rsh = 0 from [0:inf);
parameter real nsq = 0 from [0:inf);
parameter real value = 0 from [0:inf);
localparam real r = ($param_given(nsq) && rsh > 0) ? nsq * rsh : value;
localparam rtemp = r * (1 + 0.1 * $temperature);
localparam reff = (rtemp > $simparam("minr", 1m)) ? rtemp : 0;

analog begin
if( reff > 0) begin
I(a,b) <+ V(a,b) * reff;
I(a,b) <+ white_noise(4.0*`P_K*$temperature * reff, "thermal");
end else
V(a,b) <+ 0;
end
endmodule