This shows you the differences between two versions of the page.
|
gnucap:projects:nlnet:verilogams [2023/01/09 09:11] felixs 2a update |
gnucap:projects:nlnet:verilogams [2023/09/07 10:12] (current) felixs task 3 |
||
|---|---|---|---|
| Line 6: | Line 6: | ||
| == a) Implement Verilog-AMS style branches and contributions == | == a) Implement Verilog-AMS style branches and contributions == | ||
| + | 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]]. | ||
| == 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. | ||
| + | |||
| == 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]]. | ||
| == 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]]. | ||
| == 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 18: | Line 27: | ||
| == 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. | ||
| + | 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". == | ||
| == d) Provide logic gates as plug-ins, accessible from Verilog netlists. == | == d) Provide logic gates as plug-ins, accessible from Verilog netlists. == | ||
| - | == e) Refactor internals; make dc sweep work with parameters. == | + | == e) Integrate "model card" hierarchy into Verilog language semantics. == |
| - | Historically the dc sweep command only sweeps elements. Currently, in Gnucap sweeping parameters is more tedious than in other simulators. We will adjust and redefine the data path for parameter values [[precalc_last|TODO_IMPL]], and extend the dc command plugin to make use of it. | + | |
| - | == f) 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. == | ||
| + | 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]]. | ||
| + | |||
| == 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 will add the required propagation | ||
| + | rules and bookkeeping. | ||
| + | |||
| + | == 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. | ||
| + | |||
| + | == 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 | ||
| + | |||
| + | == 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. | ||