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

Link to this comparison view

gnucap:projects:nlnet:verilogamscontd [2024/05/13 09:57] (current)
felixs created
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
 +== 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.
gnucap/projects/nlnet/verilogamscontd.txt · Last modified: 2024/05/13 09:57 by felixs
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Run by Debian Driven by DokuWiki