Differences

This shows you the differences between two versions of the page.

@@ Line 1: / Line 1: @@
+In late '23, we have secured more [[https://nlnet.nl/project/Gnucap-MixedSignals/|funding]] from the NLnet Foundation alowing us to continue our work on Verilog-AMS support. We will work on three tasks. The first two will advance the model compiler and simulator, the third task will involve other projects with a focus on interoperability.
+Each task has 5 milestones. Here we will give details and keep track of our progress.
+=== Task 1. modelgen-verilog: Discrete and mixed-signal extensions ===
+== 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.