Differences

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

Link to this comparison view

gnucap:projects:nlnet:paramset_implementation [2023/01/09 09:08] (current)
felixs created
Line 1: Line 1:
 +===== paramset implementation =====
  
 +This section relates to task 1a in [[verilogams]].
 +
 +=== parsing ===
 +
 +The "paramset" command does the read-in, similar to the ".model" command in spice, but only on top level (according to the standard).
 +If a paramset instance refers to a spice model, it will create a MODEL_CARD as a fallback (this will be addressed and fixed in task2f).
 +In normal mode, paramset creates a PARAMSET object (derived from BASE_SUBCKT) that can be instanciated inside modules.
 +
 +PARAMSET::is_device() indicates whether a PARAMSET is a declaration or an instance.
 +
 +=== elaboration ===
 +
 +During precalc_first, PARAMSETs at top level resolve the type name, and a const pointer to the prototype COMPONENT is stored in _dev (is_device()==false).
 +According to the standard, the prototype name must be unique.
 +
 +Instances where is_device() is true are only reached during module expansion, *after* the toplevel has already undergone precalc_first. Here, precalc_first pulls in the instance parameters, so "is_valid" is functional. This function decides if parameter values are within the ranges specified inside the paramset declaration.
 +
 +The expand function turns the callee into a singleton subcircuit, holding a clone of _dev.
 +
 +The deflate function substitutes parameters inside the _dev instance, takes it out of the subcircuit, and returns it.
 +
 +precalc_last is not reached unless !is_device(), it does nothing.
 +
 +=== chains ===
 +
 +A chain of paramsets has to end at a device. Paramset chains are expanded into singleton subcircuits and deflated in reverse order (otherwise parameter substitution is impossible).
 +
 +=== overloading ===
 +
 +A module subdevice (such as a paramset instance) in a Verilog module is resolved in two stages. After read-in, a module subdevice is a "stub" that stores the requested device name, as well as requested parameter names and ports. Based on this (during precalc_first), a candiate CARD_LIST is compiled and stashed inside the stub. An instance of the module subdevice (this is where parameter values materialise), pulls in the candidates (in expand), and deletes the invalid ones (before deflation). This is in approximation to the standard, without the "tie braker rules".
 +
 +Overloading at top level is not possible, and not required by the standard.
gnucap/projects/nlnet/paramset_implementation.txt · Last modified: 2023/01/09 09:08 by felixs
 
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Run by Debian Driven by DokuWiki