Parameterized subcircuits provide a method of reducing the number of similar cells that must be created to provide enough functionality within your library. Star-Hspice allows you to pass circuit parameters into hierarchical designs, allowing you to configure a cell at runtime.
For example, if you parameterize the initial state of a latch in its subcircuit definition, then you can override this initial default in the instance call. Only one cell needs to be created to handle both initial state versions of the latch.
You also can parameterize a cell to reflect its layout. Parameterize a MOS inverter to simulate a range of inverter sizes with only one cell definition. In addition, you can perform Monte Carlo analysis or optimization on a parameterized cell.
The way you choose to handle hierarchical parameters depends on how you construct and analyze your cells. You can choose to construct a design in which information flows from the top of the design down into the lowest hierarchical levels. Centralizing the control at the top of the design hierarchy involves setting global parameters. You can also choose to construct a library of small cells that are individually controlled from within by setting local parameters, and build upwards to the block level.
This section describes the scope of Star-Hspice parameter names, and how Star-Hspice resolves naming conflicts between levels of hierarchy.
Integrity is a fundamental requirement for any symbol library. Library integrity can be as simple as a consistent, intuitive name scheme, or as complex as libraries with built-in range checking.
You can risk poor library integrity when using libraries from different vendors in a single design. Because there is no standardization between vendors on what circuit parameters are named, it is possible that two components can include the same parameter name with different functions. Suppose that the first vendor builds a library that uses the name Tau as a parameter to control one or more subcircuits in their library. Now suppose that the second vendor uses Tau to control a different aspect of their library. Setting a global parameter named Tau to control one library also modifies the behavior of the second library, which might not be the intent.
When the scope of a higher level parameter is global to all subcircuits at lower levels of the design hierarchy, lower level parameter values are overridden by the values from higher level definitions if the names are the same. The scope of a lower level parameter is local to the subcircuit in which the parameter is defined (but global to all subcircuits that are even lower in the design hierarchy). The local scoping rules in Star-Hspice solve the problem of lower level parameters being overridden by higher level parameters of the same name when that is not desired.
Problems with parameter names also occur when different groups collaborate on a design. Because Star-Hspice global parameters prevail over local parameters, all designers are required to know the names of all parameters, even those used in sections of the design for which they are not responsible. This can lead to a large investment in standardized libraries. You can avoid this situation by using local parameter scoping that encapsulates all information about a section of a design within that section.
To ensure that critical, user-supplied parameters are present in a Star-Hspice netlist at simulation time, Star-Hspice allows the use of "illegal defaults"--that is, defaults that cause the simulator to abort if there are no overrides for the defaults.
Library cells that include illegal defaults require that the user provide a value for each and every instance of those cells. Failure to do so causes the Star-Hspice simulation to abort.
An example is the use of a default MOSFET width of 0.0. This causes Star-Hspice to abort because this parameter is required by the Star-Hspice MOSFET models.
Consider the following examples:
...
* Subcircuit default definition
.SUBCKT Inv A Y Wid = 0 $ Inherit illegal values by default
mp1 <NodeList> <Model> L = 1u W = 'Wid*2'
mn1 <NodeList> <Model> L = 1u W = Wid
.ENDS
* Invocation of symbols in a design
x1 A Y1 Inv $ Bad! No widths specified
x2 A Y2 Inv Wid = 1u $ Overrides illegal value for Wid
This simulation would abort on subcircuit instance x1 because the required parameter Wid is never set on the subcircuit instance line. Subcircuit x2 would simulate correctly. Additionally, the instances of the Inv cell are subject to accidental interference because the global parameter Wid is exposed outside the domain of the library. Anyone could have specified an alternative value for the parameter in another section of the library or the design, which could have prevented the simulation from catching the condition present on x1.
Now consider the effect of a global parameter whose name conflicts with the library internal parameter Wid. Such a global parameter could be specified by the user or in a different library. In this example, the user of the library has specified a different meaning for the parameter Wid to be used in the definition of an independent source.
.Param Wid = 5u $ Default Pulse Width for source
v1 Pulsed 0 Pulse ( 0v 5v 0u 0.1u 0.1u Wid 10u )
...
* Subcircuit default definition
.SubCkt Inv A Y Wid = 0 $ Inherit illegals by default
mp1 <NodeList> <Model> L = 1u W = 'Wid*2'
mn1 <NodeList> <Model> L = 1u W = Wid
.Ends
* Invocation of symbols in a design
x1 A Y1 Inv $ Incorrect width!
x2 A Y2 Inv Wid = 1u $ Incorrect! Both x1 and x2 $ simulate with mp1 = 10u and $ mn1 = 5u instead of 2u and 1u.
Under global parameter scoping rules, the simulation succeeds, although incorrectly. There is no warning message that the inverter x1 has no widths assigned, because the global parameter definition for Wid overrides the subcircuit default.
In global scoping, the highest level name prevails in name conflict resolution. In local scoping, the lowest level name is used.
The parameter inheritance method allows you to specify that local scoping rules be used. This feature can cause different results than you have obtained with Star-Hspice releases prior to 95.1 on existing circuits.
With local scoping rules, the Example 2 netlist correctly aborts in x1 for W = 0 (default Wid = 0 in the .SUBCKT definition has higher precedence than the .PARAM statement), and results in the correct device sizes for x2. This change might affect your simulation results if a circuit like the second one shown above is created intentionally or accidentally.
As an alternative to width testing in the Example 2 netlist, it is also possible to achieve a limited version of library integrity with the .OPTION DEFW. This option specifies the default width for all MOS devices during a simulation. Because part of the definition is still in the domain of the top-level circuit, this method still suffers from the possibility of making unwanted changes to library values without notification by the simulator.
Methods for Configuring Libraries outlines and compares the three primary methods for configuring libraries to achieve required parameter checking in the case of default MOS transistor widths.
Use the .OPTION parameter PARHIER to specify scoping rules.
.OPTION PARHIER = < GLOBAL | LOCAL >
The default setting is GLOBAL, which gives the same scoping rules that Star-Hspice used prior to Release 95.1.
Hierarchical Parameter Passing Problem shows a flat representation of a hierarchical circuit that contains three resistors.
Each of the three resistors gets its simulation time resistance from the parameter named Val. The Val parameter is defined in four places in the netlist, with three different values.
There are two possible solutions for the total resistance of the chain: 0.3333 
and 0.5455 
.
The PARHIER option allows you to specify which parameter value prevails when parameters with the same name are defined at different levels of the design hierarchy.
Under global scoping rules, in the case of name conflicts, the top-level assignment .PARAM Val = 1 overrides the subcircuit defaults, and the total is 0.3333 
Under local scoping rules, the lower level assignments prevail, and the total is 0.5455 
(one, two and three ohms in parallel).
The example shown in Hierarchical Parameter Passing Problem produces the results in PARHIER = LOCAL vs. PARHIER = GLOBAL Results, based on the setting of the local/global PARHIER option:
Changes in scoping rules can cause different simulation results for designs created prior to Star-Hspice Release 95.1 from designs created after that release. Use the following checklist to determine if you will see simulation differences with the new default scoping rules. These checks are especially important if your netlists contain devices from multiple vendors' libraries.