This shows you the differences between two versions of the page.
|
gnucap:manual:tech:verilog [2024/09/17 10:33] felixs describe transition filter |
gnucap:manual:tech:verilog [2025/05/02 06:30] (current) felixs tech:verilog: restrict page to structural subset |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ===== Some Verilog implementation notes ===== | ===== Some Verilog implementation notes ===== | ||
| + | |||
| + | Traditionally, a circuit simulator consists of a program that processes and analyses circuits, | ||
| + | together with a collection of device model implementations. The various Verilog standards provide | ||
| + | a language to describe circuits, which we refer to as the "structural subset" of Verilog. The | ||
| + | "behavioural modelling" subset provides a flexible standard for device modelling. | ||
| + | |||
| + | Gnucap is organised as a simulator program, which implements parsing and interpretation of the | ||
| + | "structural subset", whereas the "behavioural subset" is covered by another tool "modelgen-verilog". | ||
| + | Using modelgen-verilog (and gcc) we turn behavioural models into device plugins for use | ||
| + | in the simulator with implementation notes [[.modelgen|here]]. The following sections relate to the structural subset, and its implementation | ||
| + | on the simulator side implementation on the simulator side. | ||
| ==== module ==== | ==== module ==== | ||
| Line 72: | Line 83: | ||
| ===== compiled paramset ===== | ===== compiled paramset ===== | ||
| + | TODO: move to tech:modelgen | ||
| 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 | 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 | ||
| Line 81: | Line 93: | ||
| ===== Partial specialisation ===== | ===== Partial specialisation ===== | ||
| + | TODO: move to tech:modelgen | ||
| - | 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...). | + | 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. |
| + | One issue shows up when $param_given is used in a model. Consider a module/paramset combo as follows. | ||
| + | |||
| + | <code> | ||
| + | module M([...]); | ||
| + | parameter real p=1; | ||
| + | [..] pg = $param given(p) [..] | ||
| + | endparamset | ||
| + | paramset M M1 | ||
| + | parameter real p=17; .p=p; | ||
| + | .something_else=42; // specialise some parameters | ||
| + | endparamset | ||
| + | </code> | ||
| + | |||
| + | In an instance of M1, ''$param given(p)'' will unconditionally evaluate to ''true', which may break the behaviour otherwise inherited from M. | ||
| + | |||
| + | The possible solution is to introduce parameters without a default value, as shown in the following example | ||
| + | |||
| + | <code> | ||
| + | paramset M M2 | ||
| + | parameter real p; .p=p; | ||
| + | .something_else=42; // specialise some parameters | ||
| + | endparamset | ||
| + | </code> | ||
| + | |||
| + | The intent is that the user takes control of $param_given(p) in instances of M2 as shown below. | ||
| + | |||
| + | <code> | ||
| + | M2 #() myexample1(..); // $param_given(p) == false | ||
| + | M2 #(.p(3.14)) myexample2(..); // $param_given(p) == true | ||
| + | </code> | ||
| + | |||
| + | With this mechanism, it ought to be possible to wrap M into a paramset that exposes behaviour identical to M. | ||
| + | |||
| + | Another issue is the lack of a portlist in a paramset declaration, allowing for re-using a prototype with its ports renamed. A singleton subcircuit (possibly combined with a paramset) may serve as a workaround, and hence this is low priority. | ||
| ===== transition filter ===== | ===== transition filter ===== | ||
| + | |||
| + | TODO: move to tech:modelgen | ||
| The LRM description for the transition function is unclear. The situation where | The LRM description for the transition function is unclear. The situation where | ||
| Line 110: | Line 159: | ||
| Finally, put in (ts+rf, l). | Finally, put in (ts+rf, l). | ||
| + | |||
| + | (The new LRM, VAMS-2023 adds more clarity. It seems to describe the behaviour of the algorithm above). | ||