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/11 14:35] (current) felixs hierarchy |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ===== Some Verilog implementation notes ===== | + | ===== 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 22: | Line 33: | ||
| permits overloading. In Gnucap Verilog mode a type name used in a device instance | 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. | 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. | ||
| + | |||
| + | ==== Hierarchical system parameters ==== | ||
| + | |||
| + | (The implementation lags behind a bit as of May 2025, this is the normative behaviour, to be expected with the next snapshot.) | ||
| + | |||
| + | All devices have hierarchical system parameters (HSP). HSPs are propagated to subdevices following the standard rules from LRM table 9.29. For example, an $mfactor parameter specified in a module instance consitutes a multiplicative factor in the effective mfactor values of the devices underneath. In the module scope, hierarchical system parameters can be accessed by name, with or without trailing parentheses. The value returned is the effective hierarchical value. | ||
| + | |||
| + | module c(); | ||
| + | parameter p; | ||
| + | endmodule | ||
| + | module a(); | ||
| + | b #(.$xposition(3)) myb(); | ||
| + | endmodule | ||
| + | module b(); | ||
| + | c #(.p($xposition()), .$xposition(17)) myc(); | ||
| + | endmodule | ||
| + | |||
| + | a #(.$xposition(5)) mya(); | ||
| + | |||
| + | Here, the value of ''p'' in a.b.c is ''8'', the effecive ''$xposition'' of ''a.b''. | ||
| + | |||
| + | System parameters unknown to the simulator are ignored, but stored and passed on, akin to attributes. | ||
| + | |||
| + | Beyond the standard, Gnucap supports the following hierarchical system parameters. The purpose is to | ||
| + | overrides simulator options that are usually global in traditional simulators. | ||
| + | |||
| + | === Hierarchical temperature === | ||
| + | |||
| + | The $temperature parameter sets the effective environmental temperature (in Kelvin) in a device instance. | ||
| + | The $dtemp parameter controls the temperature difference relative to the enclosing device. Examples | ||
| + | |||
| + | resistor #(.$temperature(17.)) r0(p, n); // runs at 17 Kelvin | ||
| + | resistor #(.$dtemp(17.)) r1(p, n); // runs at 17 Kelvin above environment temperature | ||
| + | module m(p, n); | ||
| + | resistor #(.$dtemp(42.)) r2(p, n); // mm.r2 runs at 45.K. | ||
| + | endmodule | ||
| + | m #(.$temperature(3.) mm(p,n); | ||
| + | |||
| + | === Integration method === | ||
| + | |||
| + | The ''$method'' HSP is string typed and selects the integration method. | ||
| + | Methods are ''trap'', ''euler'', ''gear''. | ||
| + | Conflicts are resolved as usual, more local method wins over more global, 'only' wins over non-'only'. | ||
| + | |||
| + | |||
| + | |||
| + | capacitor #(.$method("euler")) c0(p, n); // uses euler method (unless overridden) | ||
| + | module m(p, n); | ||
| + | capacitor #(.$method("euler")) c0(p, n); // mm.c0 uses trap method. | ||
| + | capacitor #(.$method("euleronly")) c1(p, n); // uses euler method. | ||
| + | endmodule | ||
| + | m #(.$method("traponly")) mm(p,n); | ||
| + | m #(.$method("trap")) mmm(p,n); // mmm.c0 uses euler method. | ||
| + | |||
| + | |||
| ==== paramset ==== | ==== paramset ==== | ||
| Line 30: | Line 96: | ||
| 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. | 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). | + | 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 system will pick the latest one, and should issue a warning. |
| === example === | === example === | ||
| Line 70: | Line 136: | ||
| endparamset | endparamset | ||
| </code> | </code> | ||
| - | |||
| - | ===== compiled paramset ===== | ||
| - | |||
| - | 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...). | ||
| - | |||
| - | ===== transition filter ===== | ||
| - | |||
| - | The LRM description for the transition function is unclear. The situation where | ||
| - | a new transition overlaps with another needs clarification. A transition filter | ||
| - | holds a waveform, similar to the delay line. It is updated whenever | ||
| - | transition is called. | ||
| - | |||
| - | In any case, the new waveform must be continuous in all arguments of the | ||
| - | new_transition call. Here's how this may be achieved. Suppose, transition is | ||
| - | called at time t0, with delay d, new start time ts=t0+d, rise or fall time rf | ||
| - | and destination l. | ||
| - | |||
| - | If the waveform has a sample at t0, future samples are deleted. | ||
| - | |||
| - | Otherwise, the future samples are deleted, excluding the first one after t0, | ||
| - | say td1. Now let s0 be the slope at t0. The case s0=0 is simple, otherwise assume | ||
| - | s0>0 w.l.o.g. | ||
| - | |||
| - | The sample at td1 has a value v1. This gives rise to a slope ps of (ts, v1), | ||
| - | (ts+rf, l). Also, let vs be the value at ts. | ||
| - | |||
| - | If ps>s0, we drop the sample at td1 and put in (ts,vs). Else if v0<l, we | ||
| - | compute (ti, vi) the intersection of (ts, v1) -- (ts+rf, l) with the rising | ||
| - | edge, and cut it short by moving (ts,vs) to (ti, vi). | ||
| - | |||
| - | Finally, put in (ts+rf, l). | ||