[[gnucap:paramset_spice]]
 
Trace:

Differences

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

Link to this comparison view

gnucap:paramset_spice [2023/01/19 11:17]
felixs approach 2c 		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 10: 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.+The declaration
  
-== issue 1b == +&lt;code&gt;.model mynpn npn (bf=150)&lt;/code&gt; 
- +    
-In Gnucap, a type name is just a name. The name in Spice &quot;model&quot; 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 &quot;nmos&quot; and "pmos", one of which must be set to an arbitrary value. +should accomplish approximately the same as the following wrapper with parameters taken from the device stub.
- +
-== 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> <code>
-paramset n nmos +.subckt mynpn c b e s 
- .level=1; + .parameter area=1 off=0 [..] 
-endparamset+ .model m npn (bf=150) 
 +  Q1 c b e s m off=off area=area [..] 
 +.ends
 </code> </code>
  
-== approach 0 (fallback) == +This means that a "mynpn" instance as in 
- +
-The current fallback. The paramset command is equivalent to .model in spice. It has little in common with Verilog.+
  
 <code> <code>
-paramset b npn +module main(); 
-  parameter area=1;         // not allowed +  mynpn #(.area(17.)) nn(.c(a), .b(b), .e(c), .s(d)); 
-  parameter default_bf=150; // not allowed +endmodule
- .area=area;                // error, not a "model parameter". +
- .bf=default_bf;            // what is default_bf? +
-endparamset+
 </code> </code>
  
-== approach 1 (sckt bundle) ==+should work regardless of which definition for mynpn is in use.
  
-A paramset like+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.
  
-<code> +Models with extended features will reflect the original intent. For example, if a Spice model supports binning, a model such as
-paramset mynpn npn +
-  parameter area=1, off=0, bf=150; +
- .bf=bf; .off=off; .area=area; +
-endparamset +
-</code>+
  
-could be interpreted close to+  .model mysmallfet some_nmos_model wmin=0 wmax=1,
  
-<code> +will have to behave as if some_nmos_device existed, with a paramset declaration as follows.
-.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> <code>
-paramset b bjt +paramset mysmallfet some_nmos 
-  parameter area=1, off=0, bf=150; + parameter [..] 
- .spice_model = "npn" + parameter w=1 from [0:1]; 
- .bf=bf; .off=off; .area=area;+ [..]
 endparamset endparamset
 </code> </code>
  
-== approach 2b (additional arguments) ==+===== summary, remarks =====
  
-Same as 2a, but use a third argument. Not a Verilog feature, hence deviate from Verilog syntax.+- This is implemented except for binning.
  
-<code> +- A Spice .model statement simply declares a type.
-paramset b bjt npn; +
-  parameter area=1, off=0, bf=150; +
- .bf=bf; .off=off; .area=area; +
-endparamset +
-</code>+
  
-== approach 2c (separator) ==+- The Spice .model directive makes little sense when using Verilog-AMS behavioural models.
  
-Same as 2b, but use a separator that is not allowed in a Verilog identifier.+- paramset could reference a .model instance as a prototype.
  
-<code> +- The spice wrapper and instantiation mechanism needs to change a little...
-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>+
gnucap/paramset_spice.1674148628.txt.gz · Last modified: 2023/01/19 11:17 by felixs
 
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Run by Debian Driven by DokuWiki