This shows you the differences between two versions of the page.
|
gnucap:manual:languages:verilog [2024/01/30 11:47] felixs lang_verilog now in mgsim |
gnucap:manual:languages:verilog [2026/05/12 06:40] (current) felixs Update, clarifications |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Language : Verilog ====== | ====== Language : Verilog ====== | ||
| + | |||
| + | |||
| + | **WARNING, TRANSITION** | ||
| + | |||
| + | In order to get the most up-to-date verilog experience, you should use the Verilog language implementation from modelgen-verilog. | ||
| + | See "Status" below. | ||
| + | |||
| + | **END WARNING** | ||
| The Verilog language plugin attempts to support the syntax of the Verilog-AMS language. | The Verilog language plugin attempts to support the syntax of the Verilog-AMS language. | ||
| Line 12: | Line 20: | ||
| The format is not line oriented. A semicolon terminates a statement. You can extend a line by ending it with \ . | The format is not line oriented. A semicolon terminates a statement. You can extend a line by ending it with \ . | ||
| - | |||
| - | In gnucap, for now, you must have one statement per line. This is non-standard. | ||
| From startup, you can set Verilog mode with the command line: | From startup, you can set Verilog mode with the command line: | ||
| Line 22: | Line 28: | ||
| verilog | verilog | ||
| - | ====== Components ====== | + | ====== Component instances ====== |
| - | All components have the same syntax: | + | All component instances have the same syntax: |
| type #(parameters) label (port list) ; | type #(parameters) label (port list) ; | ||
| Line 58: | Line 64: | ||
| (* type=wirelead, rating="1/4 watt" *) resistor #((* color=red *).r(10K)) Rload ((* up *) out, 0); | (* type=wirelead, rating="1/4 watt" *) resistor #((* color=red *).r(10K)) Rload ((* up *) out, 0); | ||
| - | ====== Top-level blocks ====== | + | ====== The top-level circuit ====== |
| - | Two top level blocks are supported: module and paramset. | + | Unlike Verilog, Gnucap allows device instances at top level, in addition to "paramset" and "model" declarations. |
| + | Right now (Feb 2026), uninstanciated modules do **not** turn into instances automatically. They need to be instanciated explicitly. | ||
| + | |||
| + | This means, a top level module like | ||
| + | |||
| + | module main(); | ||
| + | [..] | ||
| + | endmodule; | ||
| + | |||
| + | must be followed by a line similar to | ||
| + | |||
| + | main #() mymain(); | ||
| + | |||
| + | to get the full effect. As of May '26 this restriction does no longer apply to process parameter containers, such as | ||
| + | |||
| + | module myprocess(); | ||
| + | localparam real toxify=42.; | ||
| + | endmodule | ||
| + | |||
| + | eg, $root.myprocess.toxify may be accessed from a behavioural model (compiled with Modelgen-Verilog). | ||
| ===== paramset ===== | ===== paramset ===== | ||
| - | ==== new/WIP ==== | ||
| This relates to task 2a in [[gnucap:projects:nlnet:verilogams]]. The following is implemented in the modelgen-verilog package and bundled with the device plugins ("mgsim") therein. See the examples directory in gnucap-modelgen-verilog for various live applications. | This relates to task 2a in [[gnucap:projects:nlnet:verilogams]]. The following is implemented in the modelgen-verilog package and bundled with the device plugins ("mgsim") therein. See the examples directory in gnucap-modelgen-verilog for various live applications. | ||
| - | A "paramset" statement creates a new type from an existing type. It becomes a "master" that can be instantiated later. It is similar to a spice ".model". | + | A "paramset" statement creates a new type from an existing type. It becomes a prototype that can be instantiated later. It is similar to a spice ".model". |
| A paramset must be declared at top level. | A paramset must be declared at top level. | ||
| Line 124: | Line 148: | ||
| endmodule | endmodule | ||
| - | Another one is port names. If port names are used in the instantiation, a matching prototype is required. | + | Another one is port names. If a connection to a named port is made, a matching prototype providing the port is required. |
| - | Another criterion is number of parameters. If two prototypes match, the one with fewer parameters wins. This can be used to optimise out unwanted functionality and overhead. | + | |
| + | Eventually, tie break rules are applied as follows, in case multiple prototypes satisfy the necessary conditions. | ||
| + | |||
| + | The first tie break rule selects the prototype prototypes with the fewest parameter. This can be used to optimise out unwanted functionality and overhead. | ||
| module example3(1, 2) | module example3(1, 2) | ||
| Line 133: | Line 160: | ||
| resistor #(.r(1)) r2(1, 2); // avoid the overhead | resistor #(.r(1)) r2(1, 2); // avoid the overhead | ||
| endmodule | endmodule | ||
| + | |||
| + | The second rule selects the prototype with the most localparams that have a specified range.. | ||
| - | ==== current ==== | + | paramset myC capacitor; |
| + | parameter real l = 1.0; | ||
| + | parameter real w = 1.0; | ||
| + | localparam a = l*w from [1.0:10.0]; // .. like this one. | ||
| + | .c = l * w * 17.; | ||
| + | // .c(l*w*17); // warning. | ||
| + | endparamset | ||
| + | |||
| + | A third rule selects the prototype with the fewest number of ports. | ||
| + | |||
| + | According to the standard, lines are not significant. In Gnucap, for now, all must be on one line or lines extended by ending with "\". | ||
| + | |||
| + | Note that the parameter syntax in paramset is different from the parameter syntax instantiating a device. Gnucap accepts either, but will emit a warning when using the "wrong" one. | ||
| + | |||
| + | ==== built in paramset (obsolete) ==== | ||
| This description applies to the default plugin included with the Gnucap package, as of August 2023. | This description applies to the default plugin included with the Gnucap package, as of August 2023. | ||
| Line 154: | Line 197: | ||
| endparamset | endparamset | ||
| - | According to the standard, lines are not significant. In gnucap, for now, all must be on one line or lines extended by ending with "\". | ||
| - | |||
| - | Note that the parameter syntax in paramset is different from the parameter syntax instantiating a device. | ||
| ===== module ===== | ===== module ===== | ||
| - | The basic building block is called a "module". Modules are descriptions of individual components. Gnucap directly supports only the structural subset of Verilog, so a "module" here is equivalent to a Spice "subckt". | + | The basic building block is called a "module". Modules are descriptions of individual components. Gnucap directly supports only the structural subset of Verilog, so a "module" here is similar to a Spice "subckt". Use [[gnucap:manual:modelgen-verilog]] to process behavioural models. |
| Modules take the form: | Modules take the form: | ||
| Line 201: | Line 241: | ||
| (* show *) parameter rload=10K; | (* show *) parameter rload=10K; | ||
| .... | .... | ||
| + | |||
| + | ====== Behavioural models ====== | ||
| + | |||
| + | In addition to a plain netlists a 'module' may also contain behavioural modelling structures like variables, analog blocks, assignment statements. These are not directly understood by the simulator, but need to be processed/compiled and then loaded as device plugins. | ||
| + | For this purpose, we provide Modelgen-Verilog. | ||
| ====== Commands ====== | ====== Commands ====== | ||
| Line 206: | Line 251: | ||
| The Verilog language has no concept of commands. | The Verilog language has no concept of commands. | ||
| - | In gnucap, commands are executed at top level the same as the native mode. | + | In Gnucap, commands are executed at top level the same as the native mode. |
| ====== Extras ====== | ====== Extras ====== | ||
| Line 216: | Line 261: | ||
| ====== Status ====== | ====== Status ====== | ||
| - | The current implementation in gnucap is a very preliminary subset. | + | The current implementation or the Verilog language in Gnucap is a work in progress. For a better Verilog experience, use |
| + | the Verilog language plugin from modelgen-verilog. For this, ''load mgsim'' or ''load mgsim/lang_verilog.so'' **before** switching the language to Verilog. Alternatively, invoke Gnucap with | ||
| + | |||
| + | ''$ gnucap -a mgsim <nowiki>--</nowiki>verilog''. | ||
| + | |||
| + | This step will become unnecessary at some point in the future. Remaining caveats (Feb 2026) are | ||
| - | * The "master" must be defined before it is referenced. | + | * The devices and commands are whatever Gnucap has installed, not necessarily what is defined in any standard. |
| - | * The devices and commands are whatever gnucap has installed, not necessarily what is defined in any standard. | + | * The circuit must be defined before any commands using it, unless you want to simulate a partial circuit. Scripted and interactive modifications to the circuit are done the way Gnucap usually does. |
| - | * The circuit must be defined before any commands using it, unless you want to simulate a partial circuit. Scripted and interactive modifications to the circuit are done the way gnucap usually does. | + | * The main circuit can also be in Verilog syntax. The Verilog standard has no concept of components at top level. |
| - | * The main circuit can also be in Verilog syntax. The Verilog standard has no concept of components at top level. | + | |
| * To simulate, there must be a component at top level. Uninstantiated modules do nothing. | * To simulate, there must be a component at top level. Uninstantiated modules do nothing. | ||
| - | * Port direction statements like "inout" are not supported. | + | * Overloading did not fully work for top level instances before May '26. |
| - | * Discipline statements like "electrical" are not supported. | + | * Discipline statements like "electrical" are not supported and/or do nothing yet. |
| - | * Some components, and some types of arguments, are not supported in Verilog mode, but you can switch modes at any time. | + | |