Differences

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

--- gnucap:manual:tech:verilog [2023/12/21 06:16]
felixs section headings
+++ gnucap:manual:tech:verilog [2024/05/05 18:51] (current)
felixs more on paramset
@@ Line 20: / Line 20: @@
 According the the Verilog standard, only paramset, a special COMPONENT type
-permits overloading. In Gnucap any type name can refer to multiple prototypes.
+permits overloading. In Gnucap Verilog mode a type name used in a device instance
+refers to all the prototypes by that name, regardless of their origin. Possible origins are device plugins and  module or paramset statements loaded or parsed at any time before circuit expansion takes place. In spice mode, .subckt and .model commands provide a similar mechanism to create prototypes.
 ==== paramset ====
 A paramset is a COMPONENT with a named reference to another of an underlying
 type and a set of parameters, similar to a one-device subcircuit.  The type
-name is resolved during precalc_first and must be unique. Port names are
+name is resolved during precalc_first and is supposedly unique. It is currently assumed to be available when parsing the paramset. Port names are inherited from this prototype and available after precalc_first.
-inherited from this prototype and available after precalc_first.
-example
+The prototype name in a paramset declaration (used in the simulator) resolves to the first component found in its scope. Next, the device_dispatcher is queried. This is where dynamically loaded plugins may provide models. Note that the dispatcher replaces existing entries when installing the same name again, hence the last one loaded wins.
+When gnucap-modelgen reads in a paramset, a module definition must be available by the prototype name, i.e. further up within the compilation unit. The standard requires a unique name. If it is not unique, the outcome is undefined (under costruction).
+=== example ===
 <code>
@@ Line 68: / Line 71: @@
 </code>
-the user is responsible that only one is valid. The tie braking rules from the
+===== compiled paramset =====
-standard are not implemented.
+The motivation for compiled paramsets, as opposed to interpreted ones, or legacy spice .model instances is speed. Compiled paramsets can be an order of magnitude lighter due to the obvious constant pruning and structural collapse. According to the LRM, Section 6.4.2, paramset identifiers need not be unique, and offer
+a basis for overloading. We make use of this mechanism in slight deviation from the standard.
+In Gnucap, a paramset provides a device prototype, and device prototypes need not be unique. Moreover device prototypes are not distinguishable by their origin. In particular, a paramset name may be identical to the prototype module name. This offers the possibility to bundle multiple optimised paramsets alongside a generic module into a single plugin.
+When a compilation unit contains such a module and a set of (supposedly optimised, simplified) specialisations of the same one, modelgen-verilog may bundle them into a single plugin. In this situation the plugin installs a set of device prototypes, and the generic one is installed last. Subsequently declared interpreted paramsets refer to this last installed and generic prototype. This way, interpreted paramsets remain flexible, while compiled paramsets may coexist for speed.
+===== Partial specialisation =====
+Given a module declaration, the standard does not offer a way to fix a subset of its parameters, while transparently passing through the others. Paramset sort of does it, but not without changing the behaviour of the specialised device relative to the generic one. Typical use cases are devices specialised without noise, without initial conditions, without additional resistors, without temperature, or with their levels fixed (wip...).