This relates to task 2f in [[gnucap:projects:nlnet:verilogams]]. A paramset produces a component type from an existing component type. The following statement

<code>
paramset new_type type
  parameter par [= value] [range];
  [..]
 .instance_par = {expression};
  [..]
endparamset.
</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.

== issue 1 ==

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>