This shows you the differences between two versions of the page.
|
gnucap:manual:tech:spice2verilog [2026/02/16 04:21] felixs prototype declarations: update spice models |
gnucap:manual:tech:spice2verilog [2026/03/03 02:51] (current) felixs hsp and uic |
||
|---|---|---|---|
| Line 14: | Line 14: | ||
| - A full transition to Verilog-AMS can be neccessary to enable an endless list of features missing in SPICE and its derivatives. If those are needed, even a manual rewrite can be more practical and less time consuming than inventing and implementing workarounds. | - A full transition to Verilog-AMS can be neccessary to enable an endless list of features missing in SPICE and its derivatives. If those are needed, even a manual rewrite can be more practical and less time consuming than inventing and implementing workarounds. | ||
| - | Gnucap offers a SPICE subsystem subject to these issues. | + | Gnucap offers a SPICE subsystem subject to these issues.z |
| ==== Netlist translation ==== | ==== Netlist translation ==== | ||
| Line 194: | Line 194: | ||
| Verilog-AMS does not explicitly require support for nested types, and they are not mentioned in the paramset specification. Moreover module and paramset declarations are supposedly at top level. | Verilog-AMS does not explicitly require support for nested types, and they are not mentioned in the paramset specification. Moreover module and paramset declarations are supposedly at top level. | ||
| There is little gain from nested types in terms of expressivity, and possibly this choice was made to just improve compatibility between implementations. However, System-Verilog supports nested types, and it would be totally natural to have them. Perhaps System-Verilog-AMS will consolidate the drift. | There is little gain from nested types in terms of expressivity, and possibly this choice was made to just improve compatibility between implementations. However, System-Verilog supports nested types, and it would be totally natural to have them. Perhaps System-Verilog-AMS will consolidate the drift. | ||
| + | |||
| + | ==== Global Options ==== | ||
| + | |||
| + | Spice simulators provide a global set of "options" that interfere with circuit behaviour and affect models. Examples are temperature, scale, method, gmin, tolerances etc. | ||
| + | Verilog-AMS offers a place for some of these options. Gnucap implements some of it, and adds features that are still missing in the standards. | ||
| + | |||
| + | Gnucap supports Spice options through the ''.option'' command. These may be accessed from Verilog code through the ''$simparam'' function, according to the standard. | ||
| + | For example, ''$simparam("scale", 1.)'' evaluates to the value managed by the ''.option'' command. Note that this is only available in behavioural models right now (early '26). | ||
| + | |||
| + | Most options are candidates for "hierarchical system parameters" (HSP). HSPs are additional device parameters with a name starting with a dollar (''$'') character. Such parameters may not be declared, but assigned and used in a module. Unrecognised HSPs are allowed for forward and backwards compatiblilty, like attributes. Example | ||
| + | |||
| + | module bad(); | ||
| + | parameter real $mfactor = 1.; // not allowed | ||
| + | endmodule; | ||
| + | module good(); | ||
| + | parameter real m = $mfactor; // OK | ||
| + | endmodule; | ||
| + | module test(); | ||
| + | good #(.$mfactor(17.)) g1(); // OK | ||
| + | good #(.$somethingelse(42.)) g2(); // allowed (in Gnucap) | ||
| + | endmodule | ||
| + | |||
| + | Gnucap implements "inofficial" HSPs ''$temperature'', ''$dtemp'', ''$method'' (early '26) following real demand. The option ''scale'' may be covered by a ''$scale'' HSP in principle. We do not wish to encourage the use of a scaling mechanism at this point, as it normally causes problems, invites funny ideas and leads to broken promises. SI units are a good choice for physical parameters. | ||
| + | |||
| + | ==== Algorithmic Peculiarities ==== | ||
| + | |||
| + | In Spice, commands and devices sometimes accept curious arguments and parameters. Often there is no need for them, once their interaction and purpose is understood. | ||
| + | |||
| + | One example is the ''ic'' parameter that supposedly sets "initial contitions" and the ''uic'' that instructs a transient simulation command to "use" initial conditions (as opposed to compute them). Both are implemented in Gnucap for backwards compatibility and to mirror Spice. Do not use them. | ||
| + | |||
| + | The ''ic'' parameter may be assigned to (say) a capacitor instance, setting an initial charge. A nonzero value puts the device into a non-converged state, as the potential across the terminals is initially zero. In theory, a computed operating point could depend on the value specified here (if there are multiple operating points). It normally does not work like this. | ||
| + | |||
| + | The purpose of ''uic'' is to circumvent non-convergence in initial dc. There are some circuits where nonconvergence is the correct result. The ''uic'' flag just sets some values and has no basis in reality. It mostly fills in zeros, where no ''ic'' has been set explicitly, assuming convergence. | ||
| + | |||
| + | In Verilog-AMS, it is possible to model initial conditions in a physically meaningful way. Behavioural models support "initial" and "analog initial" statements to initialise variables before a simulation starts. In an analog block the call ''$analysis("ic")'' tests, if the simulator is solving for an operating point (iteratively). If it does not converge, there may be something wrong with the model. The ''uic'' flag will not fix it. | ||