This shows you the differences between two versions of the page.
gnucap:projects:nlnet:verilogams [2023/05/20 16:31] felixs task 1c |
gnucap:projects:nlnet:verilogams [2023/12/05 17:19] (current) felixs 3 b, c |
||
---|---|---|---|
Line 8: | Line 8: | ||
Branches and Contributions are explained [[gnucap:manual:tech:modelgen#Branches and contributions|here]]. | Branches and Contributions are explained [[gnucap:manual:tech:modelgen#Branches and contributions|here]]. | ||
The implementation is part of the develop branch as of [[https://git.savannah.gnu.org/cgit/gnucap/gnucap-modelgen-verilog.git/commit/?h=develop&id=59d115|March 5]]. | The implementation is part of the develop branch as of [[https://git.savannah.gnu.org/cgit/gnucap/gnucap-modelgen-verilog.git/commit/?h=develop&id=59d115|March 5]]. | ||
+ | |||
== b) Generate partial derivatives of expressions, needed by Newton's method == | == b) Generate partial derivatives of expressions, needed by Newton's method == | ||
How to [[gnucap:manual:tech:modelgen#computing partial derivatives|evaluate partial derivatives]]. An implementation is ready [[https://git.savannah.gnu.org/cgit/gnucap/gnucap-modelgen-verilog.git/log/?h=deriv|here]]. This Task is complete. | How to [[gnucap:manual:tech:modelgen#computing partial derivatives|evaluate partial derivatives]]. An implementation is ready [[https://git.savannah.gnu.org/cgit/gnucap/gnucap-modelgen-verilog.git/log/?h=deriv|here]]. This Task is complete. | ||
Line 13: | Line 14: | ||
== c) Snapshot release supporting minimalistic devices with test suite. == | == c) Snapshot release supporting minimalistic devices with test suite. == | ||
It's out and tagged [[https://git.savannah.gnu.org/cgit/gnucap/gnucap-modelgen-verilog.git/commit/?h=20230520-dev|20230520-dev]]. | It's out and tagged [[https://git.savannah.gnu.org/cgit/gnucap/gnucap-modelgen-verilog.git/commit/?h=20230520-dev|20230520-dev]]. | ||
+ | |||
== d) Support for loops, conditionals and built-ins as plugins. == | == d) Support for loops, conditionals and built-ins as plugins. == | ||
+ | The code generation for while/for loops, case/ifthenelse/ternary is ready. Since | ||
+ | [[http://git.savannah.gnu.org/cgit/gnucap/gnucap-modelgen-verilog.git/tag/?h=20230729-dev|20230729-dev]], the code generation for built-in functions, tasks and filters is based on FUNCTION plugins. | ||
+ | |||
== e) Add specific commonly used language features, ddt, idt. == | == e) Add specific commonly used language features, ddt, idt. == | ||
The ddt and idt [[gnucap:manual:tech:modelgen#Filter operators|operators]] are part of the develop branch as of [[https://git.savannah.gnu.org/cgit/gnucap/gnucap-modelgen-verilog.git/commit/?h=develop&id=e8af01ae9f1a|May 4]]. | The ddt and idt [[gnucap:manual:tech:modelgen#Filter operators|operators]] are part of the develop branch as of [[https://git.savannah.gnu.org/cgit/gnucap/gnucap-modelgen-verilog.git/commit/?h=develop&id=e8af01ae9f1a|May 4]]. | ||
+ | |||
== f) Include test cases from the LRM and the Designers Guide. == | == f) Include test cases from the LRM and the Designers Guide. == | ||
+ | LRM and Designers guide contains copyrighted material. We have our own set of unit tests, growing as we progress. Type "make check". | ||
+ | |||
== g) Write user documentation and technical notes. == | == g) Write user documentation and technical notes. == | ||
+ | |||
== h) Set up examples involving common third party compact models. == | == h) Set up examples involving common third party compact models. == | ||
Line 24: | Line 33: | ||
== a) Model overloading by name and parameter ranges according to standard. == | == a) Model overloading by name and parameter ranges according to standard. == | ||
Verilog defines "paramset" as a means to replace model cards known from spice, cf. LRM section 6.4. | Verilog defines "paramset" as a means to replace model cards known from spice, cf. LRM section 6.4. | ||
- | The standard essentially allows multiple prototypes by the same name with mutually different interfaces (see [[gnucap:manual:languages:verilog#paramset|usage]]), allowing things like [[gnucap:manual:examples:paramset_recursive|recursive models]]. This requires changes to the way device instances are read in and elaborated [[paramset_implementation|read in and elaborated]]. Preliminary code is available [[http://git.savannah.gnu.org/cgit/gnucap.git/log/?h=paramset-13|here]]. Some of it has been added to [[https://codeberg.org/gnucap/gnucsator/src/branch/develop|Gnucsator]]. | + | The standard essentially allows multiple prototypes by the same name with mutually different interfaces (see [[gnucap:manual:languages:verilog#paramset|usage]]), allowing things like [[gnucap:manual:examples:paramset_recursive|recursive models]]. This requires changes to the way device instances are [[paramset_implementation|read in and elaborated]]. Preliminary code is available [[http://git.savannah.gnu.org/cgit/gnucap.git/log/?h=paramset-13|here]]. Some of it has been added to [[https://codeberg.org/gnucap/gnucsator/src/branch/develop|Gnucsator]]. |
== b) Implement preprocessor, support backtick, macros, conditionals. == | == b) Implement preprocessor, support backtick, macros, conditionals. == | ||
Slightly deviating from the workplan, we have added [[gnucap:manual:tech:modelgen#Preprocessing]] for compiler directives directly to the model compiler. | Slightly deviating from the workplan, we have added [[gnucap:manual:tech:modelgen#Preprocessing]] for compiler directives directly to the model compiler. | ||
The code is available [[http://git.savannah.gnu.org/cgit/gnucap/gnucap-modelgen-verilog.git/commit/?h=pp&id=b264644b653495fc8bdbe1c5402ef2a06fd7e1b8|here]] and combines preprocessing with evaluating derivatives (Task 1b). | The code is available [[http://git.savannah.gnu.org/cgit/gnucap/gnucap-modelgen-verilog.git/commit/?h=pp&id=b264644b653495fc8bdbe1c5402ef2a06fd7e1b8|here]] and combines preprocessing with evaluating derivatives (Task 1b). | ||
+ | |||
== c) Add support for "attribute instance". == | == c) Add support for "attribute instance". == | ||
+ | Attributes are the little bits of info that are important in a different context, like schematics and PC boards. Verilog gives us a standard way to do this. It's now implemented in lang_verilog. It's in the snapshot, and in the "attributes-5" branch. [[https://git.savannah.gnu.org/cgit/gnucap.git/log/?h=attributes-5|here]]. There is technical documentation [[gnucap:manual:tech:plugins:languages:attributes|here]] and user documentation for its use in Verilog [[gnucap:manual:languages:verilog|here]]. | ||
+ | |||
== d) Provide logic gates as plug-ins, accessible from Verilog netlists. == | == d) Provide logic gates as plug-ins, accessible from Verilog netlists. == | ||
- | == e) Integrate "model card" hierarchy into Verilog language semantics. == | + | This is working now. It's in the snapshot [[https://git.savannah.gnu.org/cgit/gnucap.git/tag/?h=dev-20231130|here]] and in the "logic-4" branch [[https://git.savannah.gnu.org/cgit/gnucap.git/log/?h=logic-4|here]]. There is a first cut at user documentation [[gnucap:manual:devices:semi:logic|here]]. This part (2d) is complete, but it will change as task 2e is done, and again when LRM compliant connectmodule insertion (planned for early 2024) is done. |
+ | == e) Integrate "model card" hierarchy into Verilog language semantics. == | ||
To be able to use models implemented for Spice in a Verilog environment, we need to be able to reference these models from paramset statements. | To be able to use models implemented for Spice in a Verilog environment, we need to be able to reference these models from paramset statements. | ||
Spice has both component letters and model identifiers, whereas Verilog only uses type names [[gnucap::paramset_spice|etc.]]. Spice hardwires the segmentation into | Spice has both component letters and model identifiers, whereas Verilog only uses type names [[gnucap::paramset_spice|etc.]]. Spice hardwires the segmentation into | ||
shared and individual storage, while Verilog leaves it to the user. We may have to find a way to avoid performance regressions. | shared and individual storage, while Verilog leaves it to the user. We may have to find a way to avoid performance regressions. | ||
+ | |||
== f) Refactor internals; make dc sweep work with parameters. == | == f) Refactor internals; make dc sweep work with parameters. == | ||
Historically, the dc sweep command only sweeps element values, following other implementations such as Spice 1-3 and Ngspice. We have redefined the data path for parameter values in [[gnucap:manual:tech:plugins:devices:allocation_and_setup|devices]], in particular "precalc_last" and edited simple devices (elements) accordingly. With these changes, we provide parameter sweeps in [[https://codeberg.org/gnucap/gnucsator/src/branch/develop|Gnucsator]], mirroring Qucsator behaviour. We have refactored and adjusted the default [[gnucap:manual:commands:dc|dc]] command plugin and added support for parameter sweeps. Many new tests have been added in the process. This task is completed and part of the [[http://git.savannah.gnu.org/cgit/gnucap.git/tag/?h=dev-20230214|20230214 snapshot]]. | Historically, the dc sweep command only sweeps element values, following other implementations such as Spice 1-3 and Ngspice. We have redefined the data path for parameter values in [[gnucap:manual:tech:plugins:devices:allocation_and_setup|devices]], in particular "precalc_last" and edited simple devices (elements) accordingly. With these changes, we provide parameter sweeps in [[https://codeberg.org/gnucap/gnucsator/src/branch/develop|Gnucsator]], mirroring Qucsator behaviour. We have refactored and adjusted the default [[gnucap:manual:commands:dc|dc]] command plugin and added support for parameter sweeps. Many new tests have been added in the process. This task is completed and part of the [[http://git.savannah.gnu.org/cgit/gnucap.git/tag/?h=dev-20230214|20230214 snapshot]]. | ||
Line 40: | Line 55: | ||
== g) Revisit build system: Improve model compilation and loading == | == g) Revisit build system: Improve model compilation and loading == | ||
Currently, Gnucap loads precompiled binary plugins. We will automate the compilation process for a better user experience, especially because Verilog-AMS behavioural code must be compiled prior to loading. | Currently, Gnucap loads precompiled binary plugins. We will automate the compilation process for a better user experience, especially because Verilog-AMS behavioural code must be compiled prior to loading. | ||
+ | |||
== h) Release all of the above == | == h) Release all of the above == | ||
+ | |||
+ | === Task 3. Compiler optimisations === | ||
+ | |||
+ | == a) constant propagation == | ||
+ | Each continuous variable in the analog context carries a list of inputs | ||
+ | ("probe") it depends on. This is used to determine the model topology and to | ||
+ | compute the partial derivatives accordingly. We also need to keep track of | ||
+ | whether a derivative is constant. This task adds the required propagation | ||
+ | rules and bookkeeping. | ||
+ | |||
+ | These are included with the 20231031 snapshot alongside constant folding. | ||
+ | |||
+ | == b) constant sources == | ||
+ | Under the conditions identified in 3a, the evaluation and convergence checks in | ||
+ | controlled sources can be unnecessary. For example, a constant resistor does | ||
+ | not need re-evaluation, and is always converged by definition. In this task, | ||
+ | these optimisations will be implemented for resistors and other linear devices. | ||
+ | |||
+ | This task is closed to finished with the November snapshot. Paramset has taken | ||
+ | priority over this one. | ||
+ | |||
+ | == c) internal node collapse == | ||
+ | A common pattern in compact modelling are "optional internal nodes". In | ||
+ | practice, the potential across two nodes can be set to zero. With 3a and 3b, this | ||
+ | condition can be identified. In this task, the elaboration will be extended to | ||
+ | avoid additional nodes. | ||
+ | |||
+ | Since November, the optional internal nodes ("V<+0.") are collapsed into ports, and also nodes | ||
+ | in ddt/idt filters are optimised out, where they are not needed. | ||
+ | |||
+ | == d) redundant contributions == | ||
+ | Depending on instance parameters, contribution statements may be unreachable. | ||
+ | Corresponding sources and model topology are bound to be more complex than needed. | ||
+ | In this task the inferred source type will depend on the desired role, and | ||
+ | unused sources will be optimised out. Constant folding from 1a predetermines | ||
+ | reachability in conditional blocks. | ||
+ | |||
+ | Since 20231031 unreachable contributions are eliminated | ||
+ | before any code is generated. |