This shows you the differences between two versions of the page.
gnucap:paramset_spice [2023/01/19 11:17] felixs approach 2c |
gnucap:paramset_spice [2025/05/26 06:29] (current) felixs paramset spice notes, roadmap |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | |||
This relates to task 2f in [[gnucap:projects:nlnet:verilogams]]. A paramset produces a component type from an existing component type. The following statement | This relates to task 2f in [[gnucap:projects:nlnet:verilogams]]. A paramset produces a component type from an existing component type. The following statement | ||
Line 121: | Line 122: | ||
paramset a b; // normal mode, otherwise. | paramset a b; // normal mode, otherwise. | ||
</code> | </code> | ||
+ | |||
+ | === Roadmap === | ||
+ | |||
+ | The paramset construct does not seem to make sense with Spice models. There is an infinite space for workarounds. | ||
+ | It seems more useful to streamline the instanciation of devices in the context of a well-formed language, regardless of where the component prototype came from originally. | ||
+ | |||
+ | For Spice devices, this means that the definition of a prototype must be tied to the .model statement. The name used here is the prototype name. | ||
+ | |||
+ | The declaration | ||
+ | |||
+ | <code>.model mynpn npn (bf=150)</code> | ||
+ | |||
+ | should accomplish approximately the same as the following wrapper with parameters taken from the device stub. | ||
+ | |||
+ | <code> | ||
+ | .subckt mynpn c b e s | ||
+ | .parameter area=1 off=0 [..] | ||
+ | .model m npn (bf=150) | ||
+ | Q1 c b e s m off=off area=area [..] | ||
+ | .ends | ||
+ | </code> | ||
+ | |||
+ | This means that a "mynpn" instance as in | ||
+ | |||
+ | <code> | ||
+ | module main(); | ||
+ | mynpn #(.area(17.)) nn(.c(a), .b(b), .e(c), .s(d)); | ||
+ | endmodule | ||
+ | </code> | ||
+ | |||
+ | should work regardless of which definition for mynpn is in use. | ||
+ | |||
+ | Note that the letter 'Q' has lost it's meaning and purpose, consistent with use in Spice. Here, assignments of letters to devices are implementation defined and partly random anyway. | ||
+ | |||
+ | Models with extended features will reflect the original intent. For example, if a Spice model supports binning, a model such as | ||
+ | |||
+ | .model mysmallfet some_nmos_model wmin=0 wmax=1, | ||
+ | |||
+ | will have to behave as if some_nmos_device existed, with a paramset declaration as follows. | ||
+ | |||
+ | <code> | ||
+ | paramset mysmallfet some_nmos | ||
+ | parameter [..] | ||
+ | parameter w=1 from [0:1]; | ||
+ | [..] | ||
+ | endparamset | ||
+ | </code> | ||
+ | |||
+ | == remarks == | ||
+ | |||
+ | - A Spice .model statement simply declares a type. | ||
+ | |||
+ | - The Spice .model directive makes little sense when using Verilog-AMS behavioural models. | ||
+ | |||
+ | - paramset could reference a .model instance as proto, but defying the purpose | ||
+ | |||
+ | - The spice wrapper and instantiation mechanism needs to change a little... |