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... | ||