Figure 6-1: Comparator and integrator modules

6.3 Overriding module parameter values

When one module instantiates another module, it can alter the values of any parameters declared within the instantiated module, as well as the values of various system parameters that are implicitly declared for all modules. There are three ways to alter parameter values: the defparam statement, which allows assignment to parameters using their hierarchical names, the module instance parameter value assignment, which allows values to be assigned inline during module instantiation, and the paramset, which is described in 6.4. If a defparam assignment conflicts with a module instance parameter, the parameter in the module shall take the value specified by the defparam. If a defparam assignment conflicts with a paramset instance parameter, the paramset selection will occur with the parameter value specified by the defparam.

The module instance parameter value assignment comes in two forms, by ordered list or by name. The first form is module instance parameter value assignment by order, which allows values to be assigned in-line during module instantiation in the order of their declaration. The second form is module instance parameter value assignment by name, which allows values to be assigned in-line during module instantiation by explicitly associating parameter names with the overriding values.

6.3.1 Defparam statement

Using the defparam statement, parameter values can be changed in any module instance throughout the design using the hierarchical name of the parameter. See 6.7 for details about hierarchical names.

However, a defparam statement in a hierarchy in or under a generate block instance (see 6.6) or an array of instances (see 6.2.2) shall not change a parameter value outside that hierarchy. Additionally, a defparam statement is not allowed in a hierarchy in or under a paramset instance (see 6.4).

Each instantiation of a generate block is considered to be a separate hierarchy scope. Therefore, this rule implies that a defparam statement in a generate block may not target a parameter in another instantiation of the same generate block, even when the other instantiation is created by the same loop generate construct.

For example, the following code is not allowed:

genvar i;

generate

for (i = 0; i < 8; i = i + 1) begin : somename flop my_flop(in[i], in1[i], out1[i]); defparam somename[i+1].my_flop.xyz = i ;

end endgenerate

Similarly, a defparam statement in one instance of an array of instances may not target a parameter in another instance of the array.

The expression on the right-hand side of a defparam assignments shall be a constant expression involving only constant numbers and references to parameters. The referenced parameters (on the right-hand side of a defparam) shall be declared in the same module as the defparam statement.

The defparam statement is particularly useful for grouping all of the parameter value override assignments together in one module. Its syntax is shown in Syntax 6-3.

defparam_assignment ::= hierarchical_parameter_identifier = constant_mintypmax_expression // from A.2.4

Syntax 6-3—Syntax for defparam

Examples:

module tgate ();

electrical io1,io2,control,control_bar; mosn m1 (io1, io2, control);

mosp m2 (io1, io2, control_bar); endmodule

module mosp (drain,gate,source); inout drain, gate, source; electrical drain, gate, source; parameter gate_length = 0.3e-6,

gate_width = 4.0e-6;

spice_pmos #(.l(gate_length),.w(gate_width)) p (drain, gate, source); endmodule

module mosn (drain,gate,source); inout drain, gate, source; electrical drain, gate, source; parameter gate_length = 0.3e-6,

gate_width = 4.0e-6;

spice_nmos #(.l(gate_length),.w(gate_width)) n (drain, gate, source); endmodule

module annotate (); defparam

tgate.m1.gate_width = 5e-6, tgate.m2.gate_width = 10e-6;

endmodule

6.3.2 Module instance parameter value assignment by order

The order of the assignments in module instance parameter value assignment shall follow the order of declaration of the parameters within the module. Local parameter declarations are not considered when assigning by order; parameter alias declarations are also skipped. It is not necessary to assign values to all of the parameters within a module when using this method. However, the left-most parameter assignment(s) can not be skipped. Therefore, to assign values to a subset of the parameters declared within a module, the decla-

rations of the parameters which make up this subset shall precede the declarations of the remaining (optional) parameters. An alternative is to assign values to all of the parameters, but use the default value (the same value assigned in the declaration of the parameter within the module definition) for those parameters which do not need new values.

Consider the following example, where the parameters within module instance weakp are changed during instantiation.

module m (); electrical clk;

electrical out_a, in_a; electrical out_b, in_b;

//create an instance and set parameters mosp #(2e-6,1e-6) weakp (out_a, in_a, clk);

//create an instance leaving default values mosp plainp (out_b, in_b, clk);

endmodule

6.3.3 Module instance parameter value assignment by name

Parameter assignment by name consists of explicitly linking the parameter name and its value. The name of the parameter shall be the name specified in the instantiated module. It is not necessary to assign values to all the parameters within a module when using this method. Only those parameters which are assigned new values need to be specified.

The parameter expression is optional so the instantiating module can document the existence of a parameter without assigning anything to it. The parentheses are required and in this case the parameter retains its default value. Once a parameter is assigned a value, there shall not be another assignment to this parameter name.

In the following example of instantiating a voltage-controlled oscillator, the parameters are specified on a named-association basis much as they are for ports.

module n (lo_out, rf_in); electrical lo_out, rf_in;

//create an instance and set parameters

vco #(.centerFreq(5000), .convGain(1000)) vco1(lo_out, rf_in); endmodule

Here, the name of the instantiated vco module is vco1. The centerFreq parameter is passed a value of 5000 and the convGain parameter is passed a value of 1000. The positional assignment mechanism for ports assigns lo_out as the first port and rf_in as the second port of vco1.

6.3.4 Parameter dependence

A parameter (for example, gate_cap) can be defined with an expression containing another parameter (for example, gate_width or gate_length). Since gate_cap depends on the value of gate_width and gate_length, a modification of gate_width or gate_length changes the value of gate_cap.

In the following parameter declaration, an update of gate_width, whether by a defparam statement or in an instantiation statement for the module which defined these parameters, automatically updates gate_cap.

6.3.5 Detecting parameter overrides

In some cases, it is important to be able to determine whether a parameter value was obtained from the default value in its declaration statement or if that value was overridden. In such a case, the $param_given() function described in 9.19 can be used.

6.3.6 Hierarchical system parameters

In addition to the parameters explicitly declared in a module’s header, there are six system parameters that are implicitly declared for every module: $mfactor, $xposition, $yposition, $angle, $hflip, and $vflip. The values of these parameters may be accessed in a module or paramset using these names, as described in 9.18. The value of these parameters may be overridden using the defparam statement, module instance parameter value assignment by name, or a paramset; in all three methods, the system parameter identifier is prefixed by a period (.), just as for explicitly-declared parameters.

If an instance of a module has a non-unity value of $mfactor, then the following rules are applied automatically by the simulator:

—All contributions to a branch flow quantity in the analog block shall be multiplied by $mfactor

—The value returned by any branch flow probe in the analog block, including those used in indirect assignments, shall be divided by $mfactor

—Contributions to a branch flow quantity using the noise functions of 4.6.4 (white_noise, flicker_noise, and noise_table) shall have the noise power multiplied by $mfactor

—Contributions to a branch potential quantity using the noise functions of 4.6.4 shall have the noise power divided by $mfactor

—The module’s value of $mfactor is also propagated to any module instantiated by the original module, according to the rules found in 9.18.

Application of these rules guarantees that the behavior of the module in the design is identical to the behavior of a quantity $mfactor of identical modules with the same connections; however, the simulator only has to evaluate the module once.

Verilog-AMS does not provide a method to disable the automatic $mfactor scaling. The simulator shall issue a warning if it detects a misuse of the $mfactor in a manner that would result in double-scaling.

The two resistor modules below show ways that the $mfactor might be used in a module. The first example, badres, misuses the $mfactor such that the contributed current would be multiplied by $mfactor twice, once by the explicit multiplication and once by the automatic scaling rule. The simulator will generate an error for this module.

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

parameter real r = 1.0 from (0:inf); analog begin

I(a,b) <+ V(a,b) / r * $mfactor; // ERROR end

endmodule

In this second example, parares, $mfactor is used only in the conditional expression and does not scale the output. No error will be generated for this module. In cases where the effective resistance r/$mfactor would be too small, the resistance is simply shorted out, and the simulator may collapse the node to reduce the size of the system of equations.

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

parameter real r = 1.0 from (0:inf); analog begin

if (r / $mfactor < 1.0e-3) V(a,b) <+ 0.0;

else

I(a,b) <+ V(a,b) / r;

end endmodule

The values of the five geometrical system parameters, $xposition, $yposition, $angle, $hflip, and $vflip, do not have any automatic effect on the simulation. The paramset or module may use these values to compute geometric layout-dependent effects, as shown in the following example.

In the next example, it is assumed that a top-level module named processinfo contains values for the properties of polysilicon resistors in the manufacturing process, including the nominal value processinfo.rho and the gradients processinfo.drho_dx and processinfo.drho_dy, in the x and y direction respectively.

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

parameter real length = 1u from (0:inf); parameter real width = 1u from (0:inf); real rho, reff;

analog begin

rho = processinfo.rho

+$xposition * processinfo.drho_dx

+$yposition * processinfo.drho_dy; reff = rho * length / width;

I(a,b) <+ V(a,b) / reff;

end endmodule

The resistor just defined could be instantiated in the following manner so as to cancel out the process gradients: