== a) Catch up on Verilog-A features from Annex C in the LRM that are still missing. Some of these were completed in between the other tasks, some are incomplete, and those not used in any public models are untouched. We will complete features such as ground node declaration, hierarchical system parameters such as $mfactor. We will catch up on “ac_stim” and noise sources. We will implement frequency domain waveform filters (laplace) and discrete filters (inverse-z), will aim for “generate struct”, and will look into $discontinuity.

== b) Primitives as defined in the Verilog-HDL standard. User defined primitive logic modelling with “table”. Here we leave the analog domain and add the foundational discrete modelling features. This milestone is somewhat analogous to the implementation of partial derivatives and “analog function” in the previous project.

== c) Beginning with Clause 7, mixed-signal. We will add syntactic support for basic digital functionality. discrete disciplines, various types of wires, discrete math. “connectmodule”. This is the the modelgen side of the simulator work in 2b.

== d) We need the generic event expressions and operators such as the “always” block, timers. The missing parts of AMS in the LRM Section 5.10 “Analog event control statements”.

== e) Performance enhancements, efficiency refinements. This goes along with 2e and will mostly affect the discrete simulation.

=== Task 2. The simulator side of mixed-signal

== a) Update of NODE storage. Existing code has a 1:1 mapping, through an array with indexing. Every node has both parts. A change in storage will improve efficiency, and also lift a restriction on how connectmodules are inserted. The existing form works for cases where a node needs one connectmodule, but does not support more than one, which is sometimes needed. Referencing LRM 7.7.4, “connect_mode” can be “split” or “merged”. The existing data structure works for “merged” but not for “split”.

== b) Simulator support for generated connectmodules as plugins. Language support for “connectrules” block and “connect” statement. Currently there is the equivalent of one connectmodule as MODEL_LOGIC, with different semantics than needed. It will be updated to the standard

== c) A full “selective trace” event queue. There is an event queue, but it only queues global events. It needs to be enhanced to queue specific devices. The first step in the enhancement is to implement fanout lists. The second will be to make effective use of them.

== d) Matrix ordering based on the fanout lists, taking into account tradeoffs between speed and memory footprint. This will reduce both matrix memory requirements and improve speed.

== e) Carry over from 2023 on paramset and MODEL_CARD refactoring as well as indirect storage. We will conduct experimental work on efficiency by taking advantage of new data structures and necessary rearrangements.

=== Task 3. Interoperation with other software, demonstrate concepts

== a) Update “spice_wrapper” to support models from the current version of NGSpice. By using wrapper code, Gnucap can use C models for/from Spice as plugins. Currently, several versions of Spice are supported. It allows users to pick from a large set of different models and their variants.

== b) Development of an NGSpice back-end for modelgen. Modelgen is a modular program, so a substitute back-end (the mg_out files) could generate code for any simulator. This task is to develop a back-end that will generate code for SPICE, providing an alternative model compiler for ngSpice. It also demonstrates that modelgen can generate code for different simulators, and could become a standard.

== c) Develop a design document showing how to represent schematic and layout in a Verilog format, for data transfer between applications. First a general document will be developed, then specific documents addressing 3 schematic formats and 3 layout formats. Which ones to support has not been determined, but we will prefer projects that are supported by NLnet. This task produces documentation, not code. Once documented, it could be implemented on either side. It could be done as part of the layout or schematic program, which is preferred, or could be done as a Gnucap language plugin.

== d) Implementation of one schematic and one layout as a Gnucap language plugin, based on the documents from 3c.

== e) Finish and fold in additional analog analysis commands such as S-parameter analysis, small signal noise, sensitivity, pz. These are of interest to users from various PCB and schematic tools and will be very useful in combination with Verilog-AMS modelling capabilities.