Differences

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]
felixs created
gnucap:projects:nlnet:verilogamscontd [2025/05/17 15:55] (current)
felixs put some results in
Line 6: Line 6:
 === Task 1. modelgen-verilog: Discrete and mixed-signal extensions === === 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 +== a) Catch up on Verilog-A features from Annex C in the LRM that are still missing. ==
-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 standardUser defined primitive +We have implemented the ground node declaration, hierarchical system 
-logic modelling with "table". Here we leave the analog domain and add the +parameters such as $mfactor. The "ac_stim" function and noise sources are ready for use in small signal analysis. 
-foundational discrete modelling features. This milestone is somewhat analogous+Frequency domain waveform filters (laplace) and discrete 
 +filters (inverse-z) are now available for use in behavioural models. 
 +The $discontinuity function has been implemented. 
 +We have considered "generate struct" some preparations in the code generator have been made. 
 + 
 +== b) Primitives as defined in the Verilog-HDL standard == 
 +User defined primitive (UDP) sequential logic modelling with "table" is ready for use. 
 +These introduce the foundational discrete modelling features. This milestone is somewhat analogous
 to the implementation of partial derivatives and "analog function" in the to the implementation of partial derivatives and "analog function" in the
 previous project. previous project.
  
-== c) Beginning with Clause 7, mixed-signalWe will add syntactic support +== c) Beginning with Clause 7, mixed-signal == 
-for basic digital functionality. discrete disciplines, various types of wires, +We have added syntactic support for basic digital functionality. 
-discrete math. "connectmodule". This is the the modelgen side of the simulator +Made preparations for discrete disciplines, various types of wires, 
-work in 2b.+discrete math. "connectmodule". This work has been delayed by task 2b, as it relies on typed nodes and connect rules. 
 + 
 +== d) Generic event expressions and operators == 
 +We have implemented analog events. Cross event, timer event, above event are ready for use. 
 +Such events will be used in the "always" blocks and will interact with discrete digital models. We have 
 +implemented state variables required in digital models 
 + 
 +== e) Performance enhancements, efficiency refinements ==  
 +We have implemented an [[gnucap:manual:tech:plugins:solver|interface]] exposing the linear solver 
 +and developed a new sparse version of the bump and spike data structure. A new selective trace 
 +algorithm improves the performance of simulation with discrete parts.
  
-== 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 +=== Task 2The simulator side of mixed-signal ===
-and will mostly affect the discrete simulation.+
  
-=== Task 2. The simulator side of mixed-signal+== a) Update of NODE storage. ==
  
-== a) Update of NODE storageExisting code has 1:1 mapping, through an array +We have revisited the the data structures behind the connectivity graph. 
-with indexingEvery node has both parts. A change in storage will improve +The algorithm that allocates nodes is now based on hierarchical union-find 
-efficiency, and also lift a restriction on how connectmodules are inserted. The +algorithmIt allows the contraction of nets, global nodes (such as ground), and 
-existing form works for cases where a node needs one connectmodule, but does +to keep track of node typesThis will be needed both to apply connectrules resolving the 
-not support more than one, which is sometimes neededReferencing LRM 7.7.4, +final type(s) of a node to place connect modules and to allow for "split" nodes.
-"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 pluginsLanguage +== b) Simulator support for generated connectmodules as plugins ==  
-support for "connectrules" block and "connect" statement. Currently there is +Language 
-the equivalent of one connectmodule as MODEL_LOGICwith different semantics +support for "connectrules" block and "connect" statement have been delayed by the node rework
-than needed. It will be updated to the standard+There is a draft implementation making a distinction between "discrete", "continuous" and "hybrid" nodes
 +and selects what is needed in a given hierarchical circuit. 
 +Here, "hybrid" nodes are the traditional take on connect modules. They will have to be replaced by two nodes of 
 +the effective disciplines and a connect module across.
  
-== c) A full "selective trace" event queue. There is an event queue, but it +== c) A full "selective trace" event queue == 
-only queues global events. It needs to be enhanced to queue specific devices. +The event queue has been updated to queue events for specific devices 
-The first step in the enhancement is to implement fanout lists. The second will +rather than just global events
-be to make effective use of them.+Fanout fanout lists have been implemented, and a trace based recursive ''tr_advance'' routine significantly reduces 
 +the number of iterations in mixed signal simulations. See ''trace-4'' branch.
  
-== d) Matrix ordering based on the fanout lists, taking into account tradeoffs +== d) Matrix ordering based on the fanout lists == 
-between speed and memory footprint. This will reduce both matrix memory +During the work in 2c we have identified an effective method to order nodes 
-requirements and improve speed.+along the signal path. This ordering will also be applied to the continuous nodes associated with a matrix entry. 
 +It will effectively improve the LU decomposition performance by means of better exploitation of the partial updates.
  
-== e) Carry over from 2023 on paramset and MODEL_CARD refactoring as well as indirect +== e) Carry over from 2023 on paramset and MODEL_CARD refactoring as well as indirect storage. == 
-storage. We will conduct experimental work on efficiency by taking advantage of +We have designed a new hierarchical data structure for parameter sets shared across devices. 
-new data structures and necessary rearrangements.+This will allow the efficient storage of hierarchical system parameters, and the use of paramset 
 +blocks without much overhead.
  
-=== Task 3. Interoperation with other software, demonstrate concepts+=== Task 3. Interoperation with other software, demonstrate concepts ===
  
-== a) Update "spice_wrapper" to support models from the current version of +== a) Update "spice_wrapper" == 
-NGSpiceBy using wrapper codeGnucap can use C models for/from Spice as +The spice wraper how supports models from the current version of 
-pluginsCurrently, several versions of Spice are supportedIt allows users to +ngSpiceThese are now available as plugins. The new wrapper accounts for node contractions used in newer models, 
-pick from a large set of different models and their variants.+and now also exposes noise models implemented for Spice. The interface for noise modelling was added to Gnucap to enable 
 +Verilog-AMS noise functions (c.f. task 1a)
 +Users may now pick from a larger set of models from different Spice implementations and their variants.
  
-== b) Development of an NGSpice back-end for modelgen. Modelgen is a modular +== b) Development of an NGSpice back-end for modelgen == 
-program, so substitute back-end (the mg_out files) could generate code for +Instead we have explored how to [[gnucap:manual:tech:spice2verilog|convert]] circuits written for  
-any simulator. This task is to develop a back-end that will generate code for +(a) Spice into portable Verilog-AMS models. This could solve the lock-in problem that normally 
-SPICEproviding an alternative model compiler for ngSpiceIt also +comes with Spicesince no two Spice implementations share the same input language
-demonstrates that modelgen can generate code for different simulators, and +In additionwe have explored a method to feed standardised circuits and schematics (from 3b) into 
-could become standard.+Spice simulator.
  
-== c) Develop a design document showing how to represent schematic and +== c) Show how to represent schematic and layout in a Verilog format == 
-layout in a Verilog format, for data transfer between applications. First a +For data transfer between applications, a common file format is useful
-general document will be developed, then specific documents addressing 3 +We have studied formats from different applications centered at schematics 
-schematic formats and 3 layout formats. Which ones to support has not been +and propose a standard file format"Verilog-S", for storing schematics
-determinedbut we will prefer projects that are supported by NLnetThis task +We have produced documentation, and practical information about the 
-produces documentation, not code. Once documented, it could be implemented on +translation between Verilog-S and two common schematic file formats
-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 +== d) Implementation of one schematic and one layout as a Gnucap language plugin == 
-plugin, based on the documents from 3c.+In parallel to the documentation from 3c, we have developped a Gnucap extension to support 
 +gEDA/Lepton schematics and we have upgraded the schematic file format in Qucs to Verilog-S. 
 +We did not get to layout yet. It is now possible to effectively use/study/analyse/modify 
 +circuits drawn with either lepton-schematic or Qucs.
  
-== e) Finish and fold in additional analog analysis commands such as +== e) Finish and fold in additional analog analysis commands == 
-S-parameter analysissmall signal noisesensitivitypzThese are of +We have maintainedupdatedand extended various Gnucap related projects 
-interest to users from various PCB and schematic tools and will be very useful +making use of new features in Gnucapmostly related to new Verilog-AMS 
-in combination with Verilog-AMS modelling capabilities.+featuresFor example, more devices in Qucs are now backed by Verilog-AMS electrical models, 
 +including more RF devices and Qucs style small signal noise sources. The pole-zero analysis 
 +in gnucap-python has been confirmed to work with Verilog-AMS frequency domain models.
gnucap/projects/nlnet/verilogamscontd.1715612265.txt.gz · 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