* gnucap:manual:tech

gnucap:manual:tech:auto

After having it available for over 10 years now, and seeing lots of use of it, the use of auto is generally not a good idea in Gnucap. Working with some item, looking at its declaration, the type is most relevant. “auto” requires looking elsewhere, which normally makes the code harder to read and understand.

gnucap:manual:tech:code_coverage_testing

Code coverage testing To assist in testing the following procedure is used. This is a semi-automated procedure, intended to assist in developing a test suite that fully tests the code, and to guide the developer in a code review. This procedure uses the untested() macro as a marker to indicate what has been tested and not. It is performed on each source file.

gnucap:manual:tech:compiling

Compiling for test Gnucap has two different modes for compiling. * For regular users, only default compile options are used, for minimum clutter during compiling, so real problems will stand out. * For developers, additional warnings are enabled, to catch minor issues that may lead to errors. For code to be accepted into the main distribution (not plugins that are distributed separately) it must compile without warnings, with most compiler warnings enabled.

gnucap:manual:tech:data

Private data members. In some code they are at the top of the class. They should be on top. Gnucap code is mostly on top, but some on bottom, which probably should be moved to top. Perhaps historically they had to be on top. Single pass compiler requires to declare everything before first use. Then it was ok at bottom too... It seems to be a matter of tast, but “top” is used more widely, and should be adopted.

gnucap:manual:tech:delete_dummies

It is easier to delete unwanted defaults than implementing dummies. class C{ // explicit C(){ unreachable(); } // note: may be ill formed. explicit C() = delete; [..] }; The use of “delete” will produce errors at compile time, much like correcly placed dummies. It's nice to have a real language feature here, to not need to resort to dummies.

gnucap:manual:tech:iftests

It may appear to some that these two forms are equivalent and interchangeable. They may generate the same code, but have different meanings to a human reader. Both have their place. Suppose we have an object X. I am not telling you what X is. It might be a number, might be a pointer, might be something that I might think of either way.

gnucap:manual:tech:modelgen-verilog

The term “modelgen” refers to the device model generator and language that has been part of the Gnucap project from early on. Modelgen reads device descriptions and emits C++ code to be compiled into plugins. Support for Verilog-AMS compact models has been implemented in a modelgen successor, “modelgen-verilog”, following the design patterns and device architecture. Major technical advantages of the latter are automatic differentiation and support for device specific numerical tolerances. Others…

gnucap:manual:tech:modelgen

The term “modelgen” refers to the device model generator and language that has been part of the Gnucap project from early on. Modelgen reads device descriptions and emits C++ code to be compiled into plugins. Support for Verilog-AMS compact models has been implemented in a modelgen successor, ”modelgen-verilog”, following the design patterns and device architecture. Major technical advantages of the latter are automatic differentiation and support for device specific numerical tolerances. Others…

gnucap:manual:tech:nodes

Node procedure On read-in A NODE_MAP belongs to a CARD_LIST, which stores a circuit. Read-in is implemented in a lang_* plugin. At this time, the NODE_MAP is populated as needed whenever a connection is made. loop(devices) { parse_ports: set_port_by_name | set_port_by_index calls node_t::new_node, NODE_MAP::new_node which enters to node_map (per scope) (n_()) (_nnn) points to a USER_NODE in scope()->nodes() (t_()) (_idx) flat, global id number (==_nnn->user_number) …

gnucap:manual:tech:override

Functions intended to override others should be marked as such. This will improve readability as well as catch typos and type mismatch immediately. It is unfortunate that its use is not required, as backwards compatibility is in the way. Note that GCC 5.1+ has added new warning suggest-override that you can pass as command line option -Wsuggest-override. Perhaps we should use it...

gnucap:manual:tech:plugins

This section describes the Gnucap plugin system, for programmers. Concepts * Files * Coding Plugin types * commands * devices * simulation languages * behavioral functions * parameter functions and measurements * matrix solver * output

gnucap:manual:tech:rangeloop

It could be good, or not. One point about it is that this form does not explicitly specify the order of the iteration. Therefore I would only use it in cases where that is the intent, and even in that case, explicitly specify the type. int main() { int numberArray[] = { 100, 200, 300, 400, 500 }; for (int number: numberArray) { cout << number << " "; } return 0; }

gnucap:manual:tech:spice

Some Spice implementation notes and roadmap Standard version There is no standard or version in Spice currently maintained in public. All known implementations (both free and non-free) use their own dialects and are mutually incompatible. History Gnucap Spice support was originally implemented during Spice2 times. More features, mainly behavioural modelling were added, with goals similar to Spice3, but using a more regular syntax. As a consequence, Gnucap is not compatible with any Spice3 de…

gnucap:manual:tech:spice2verilog

Porting/Converting Spice to Verilog(-AMS) Verilog-AMS has been designed to coexist with Spice, and to replace it as needed (among other things). Citing from Annex E of the language reference manual, Analog simulation has long been performed with SPICE and SPICE-like simulators. As such, there is a huge legacy of SPICE netlists. These are supposed to retain its use when upgrading a SPICE simulator. On the other hand, Annex E provides a list of “SPICE primitives” that facilitate the rewrite of ba…

gnucap:manual:tech:style

This section provides guidelines for programmers. Some of them are arbitrary. Please follow them for consistency. If you prefer a different way, please consider that it would be much worse to deal with a dozen different ways in the same body of code.

gnucap:manual:tech:symbol_names_and_scope

Naming conventions * Local variables are lower case, with words (if any) separated by underscores. * Class instance variables begin with a single underscore. * Formal parameters (arguments passed to functions) begin with an Upper case letter, and are otherwise lower case. * Do not use “using”. Instead, explicitly specify the scope with every use. * Constants are ALL_CAPS. * Members of an enum set begin with a lower case letter, but are otherwise ALL CAPS. That lower case prefix is…

gnucap:manual:tech:test_macros

Test Macros Gnucap supplies a set of test macros in the file gnucap/io_trace.h . This file may be included more than once, at any place in the code, to change the options. All of these macros do nothing when compiled with default settings. They exist so they can be left in the code and enabled or disabled as needed by developers without burdening end users with their clutter.

gnucap:manual:tech:testing

This section describes Gnucap test procedures, policy, and test macros. * test macros * compiling * code coverage testing

gnucap:manual:tech:verilog

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:manual:tech:verilog2spice

Using Verilog circuits in a SPICE-only simulator Some SPICE simulators do not understand Verilog syntax or semantics. A subset of the structural part of Verilog maps nicely to Spice, given a library that maps devices to a representation that works with the targeted Spice engine.

gnucap:manual:tech:white_and_black_space

Neither white nor black space has any function, but it is used to arrange characters on the screen, and/or make your code easier to read. Such characters are space, tab and newline. Do not use carriage return or other fancy stuff. On this page, we summarise the most important rules. If there are violations in the code, they should be fixed when the code is edited. Ideally this happens for some other reason.