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

Link to this comparison view

gnucap:manual:tech:verilog [2024/05/05 17:53]
felixs prototype lookup
gnucap:manual:tech:verilog [2024/05/05 18:51] (current)
felixs more on paramset
Line 26: Line 26:
 A paramset is a COMPONENT with a named reference to another of an underlying 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 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> <code>
Line 68: Line 71:
 </code> </code>
-the user is responsible that only one is validThe 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 speedCompiled 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...).
gnucap/manual/tech/verilog.txt · Last modified: 2024/05/05 18:51 by felixs
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Run by Debian Driven by DokuWiki