[[gnucap:paramset_spice]]
 
Trace:

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

gnucap:paramset_spice [2025/05/26 06:29]
felixs paramset spice notes, roadmap 		gnucap:paramset_spice [2025/08/18 10:13] (current)
felixs turn roadmap into description, update status
Line 1: Line 1:
 +====== Spice and paramset ======
 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 11: Line 11:
 </code> </code>
  
-defines new_type from type. The former inherits the port names from the latter, but parameters, their ranges, and how they are forwarded is defined inside the paramset body (See LRM). Spice models do not work like this, but they should be accessible through paramset. Ideally a paramset encapsulates the Spice stuff and makes them look like ordinary components. Unfortunately, this hasn't been thought through in the LRM. Here are a few issues.+defines new_type from type. The former inherits the port names from the latter, but parameters, their ranges, and how they are forwarded is defined inside the paramset body (See LRM). Spice models do not work like this, but they need to be accessible from Verilog, and a Spice "model" instance must behave much like a paramset.
  
-== issue 1 == +This means that a spice ''.model'' statement must declare an instanciable prototype of a given name. Without a ''.model'' statement, a device implemented for Spice is inaccessible.
- +
-In Spice, the split of a device into shared data ("model card") and a instance data ("device") is hard wired, and both parts must be combined to make a component. So "type" could be the model card name or the device type name. As it is possible to obtain a device from a model card, the model card name seems more natural, but maybe isn't. +
- +
-== issue 1b == +
- +
-In Gnucap, a type name is just a name. The name in Spice "model" code may be hard wired in places we have no control over. For example, the type name of a builtin MOS model card (from modelgen) must be set to either nmos or pmos to set the polarity. A spice3f5 fet model has dummy parameters "nmos" and "pmos", one of which must be set to an arbitrary value. +
- +
-== issue 2 == +
- +
-The segmentation of parameters is now user defined. Some of the parameters refer to model parameters (like vto, tox in an fet, is in a diode...) some of them are instance parameters (w/l in a an fet, area in a diode). It may be sensible to reject paramsets with incompatible segmentation, but it may also be useful to allow them at the cost of efficiency. +
- +
-== issue 3 (optional ports) == +
- +
-Some Spice devices have "optional ports". E.g. a bjt has three or four ports depending on how it is instanciated. The best way to deal with this, is to pass it through, but it will draw some additional attention to detail. +
- +
-== issue 4 == +
- +
-Duplicate parameter names. Both, diode and diode model has "is", "rs", "cjo"... Where does it need to go? +
- +
-== issue 5 == +
- +
-Ambiguous model name, and what is level? It's probably best to reject things like the following. +
- +
-<code> +
-paramset n nmos +
- .level=1; +
-endparamset +
-</code> +
- +
-== approach 0 (fallback) == +
- +
-The current fallback. The paramset command is equivalent to .model in spice. It has little in common with Verilog. +
- +
-<code> +
-paramset b npn +
-  parameter area=1;         // not allowed +
-  parameter default_bf=150; // not allowed +
- .area=area;                // error, not a "model parameter". +
- .bf=default_bf;            // what is default_bf? +
-endparamset +
-</code> +
- +
-== approach 1 (sckt bundle) == +
- +
-A paramset like +
- +
-<code> +
-paramset mynpn npn +
-  parameter area=1, off=0, bf=150; +
- .bf=bf; .off=off; .area=area; +
-endparamset +
-</code> +
- +
-could be interpreted close to +
- +
-<code> +
-.subckt mynpn c b e s +
- .parameter area=1 off=0 bf=150 +
- .model m npn (bf=bf) +
-  Q1 c b e s m off=off area=area +
-.ends +
-</code> +
- +
-Q1 comes from npn, through "clone_instance". Note the issue 3 with the optional substrate port. Also, an instance of mynpn will have to carry a model card, unless all model parameters are constant. +
- +
-This approach may fail, if there are multiple models by the requested name (here: "npn"). Remember, in Verilog, a paramset inherits the port names from the type. Port names are used in overloading and ambiguous port layout will render the selection overly complicated. Cf. issue 1b. +
- +
-== approach 2a == +
- +
-In Gnucap, types are associated with strings, and both "Q" and "bjt" refer to the builtin bjt device that requires a model name to operate. It could be used in a paramset, given there was an extra string parameter such as "spice_model", or if we pretend there was. This relates to issue 1b: if there are multiple models loaded, and all need either "npn" or "pnp" as their model name, we need to disambiguate at some point. Perhaps try them all and see which one is valid for the bjt device in question. +
- +
-<code> +
-paramset b bjt +
-  parameter area=1, off=0, bf=150; +
- .spice_model = "npn" +
- .bf=bf; .off=off; .area=area; +
-endparamset +
-</code> +
- +
-== approach 2b (additional arguments) == +
- +
-Same as 2a, but use a third argument. Not a Verilog feature, hence deviate from Verilog syntax. +
- +
-<code> +
-paramset b bjt npn; +
-  parameter area=1, off=0, bf=150; +
- .bf=bf; .off=off; .area=area; +
-endparamset +
-</code> +
- +
-== approach 2c (separator) == +
- +
-Same as 2b, but use a separator that is not allowed in a Verilog identifier. +
- +
-<code> +
-paramset b bjt/npn; +
-[..] +
-</code> +
- +
-== paramset plugin selection == +
- +
-The paramset parser is a command, that instanciates a paramset object. The paramset instance is defined in a plugin, and so we can simply use different plugins in different situations. +
- +
-<code> +
-paramset a b c; // choose approach 2c +
-paramset a b;   // choose fallback or sckt bundle if b is in model_dispatcher +
-paramset a b;   // normal mode, otherwise. +
-</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 The declaration
Line 154: Line 39:
 should work regardless of which definition for mynpn is in use. 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.+Note that the letter 'Q' has lost it's meaning and purpose, consistent with use in Spice. In Spice, assignments of letters to devices are implementation defined and partly random. ''X'' should work whenever a (sub)type name is provided.
  
 Models with extended features will reflect the original intent. For example, if a Spice model supports binning, a model such as Models with extended features will reflect the original intent. For example, if a Spice model supports binning, a model such as
Line 170: Line 55:
 </code> </code>
  
-== remarks ==+===== summary, remarks ===== 
 + 
 +- This is implemented except for binning.
  
 - A Spice .model statement simply declares a type. - A Spice .model statement simply declares a type.
Line 176: Line 63:
 - The Spice .model directive makes little sense when using Verilog-AMS behavioural models. - 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+- paramset could reference a .model instance as a prototype.
  
 - The spice wrapper and instantiation mechanism needs to change a little... - The spice wrapper and instantiation mechanism needs to change a little...
gnucap/paramset_spice.txt · Last modified: 2025/08/18 10:13 by felixs
 
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Run by Debian Driven by DokuWiki