This shows you the differences between two versions of the page.
|
gnucap:manual:tech:spice2verilog [2025/09/02 06:52] felixs add reference to inverse |
gnucap:manual:tech:spice2verilog [2025/11/24 02:18] (current) felixs binning: reusability remark |
||
|---|---|---|---|
| Line 129: | Line 129: | ||
| .ends | .ends | ||
| In Gnucap, such a wrapper may refer to the model code originally used by the SPICE netlist author. | In Gnucap, such a wrapper may refer to the model code originally used by the SPICE netlist author. | ||
| + | |||
| + | === Binning === | ||
| + | |||
| + | Spice may support binning for model cards. Given two model cards | ||
| + | |||
| + | .model mymos.1 nmos wmin=1 wmax=2 more=42 | ||
| + | .model mymos.2 nmos wmin=2 wmax=3 more=17 | ||
| + | |||
| + | a device instance of type "mynpn" will pick the suitable model based on 'w' and infer the value of the other parameters (here: more) accordingly. | ||
| + | |||
| + | M1 d g s b mymos w=1.5 | ||
| + | M2 d g s b mymos w=2.5 | ||
| + | |||
| + | M1 will have more=42, and M2 will end up with more=17. | ||
| + | |||
| + | In Verilog this may be expressed using the paramset construct referring to a wrapper similar to the one shown above. | ||
| + | |||
| + | .subckt mymos_wrap d gate s b | ||
| + | .parameter w=1u | ||
| + | .parameter l=1u | ||
| + | .parameter more=0 | ||
| + | .model mm nmos w=w, l=l | ||
| + | m1 d gate s b mm w=w l=l more=more | ||
| + | .ends | ||
| + | |||
| + | paramset mymos mymos_wrap | ||
| + | parameter real w=0 from [1.:2.]; | ||
| + | .more=42; | ||
| + | .w=w; | ||
| + | endparamset | ||
| + | paramset mymos mymos_wrap | ||
| + | parameter real w=0 from [2.:3.]; | ||
| + | .more=17; | ||
| + | .w=w; | ||
| + | endparamset | ||
| + | |||
| + | |||
| + | With these, M1 and M2 translate to | ||
| + | |||
| + | mymos #(.w(1.5)) M1(d,g,s,b); | ||
| + | mymos #(.w(2.5)) M2(.d(d),.gate(g),.s(s),.b(b)); | ||
| + | |||
| + | as expected, optionally with port names inferred from mymos_wrap. Note that these paramsets are self contained and reusable specifically when moving on from Spice "model + instance" .subckt wrappers to behavioural models implemented as Verilog "module". | ||
| + | |||
| + | === Type nesting === | ||
| + | |||
| + | 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. | ||