This shows you the differences between two versions of the page.
|
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 standard. User 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-signal. We 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 2. The 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 storage. Existing code has a 1:1 mapping, through an array | + | We have revisited the the data structures behind the connectivity graph. |
| - | with indexing. Every node has both parts. A change in storage will improve | + | The algorithm that allocates nodes is now based on a hierarchical union-find |
| - | efficiency, and also lift a restriction on how connectmodules are inserted. The | + | algorithm. It 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 types. This will be needed both to apply connectrules resolving the |
| - | not support more than one, which is sometimes needed. Referencing 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 plugins. Language | + | == 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_LOGIC, with 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" == |
| - | NGSpice. By using wrapper code, Gnucap can use C models for/from Spice as | + | The spice wraper how supports models from the current version of |
| - | plugins. Currently, several versions of Spice are supported. It allows users to | + | ngSpice. These 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 a 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 |
| - | SPICE, providing an alternative model compiler for ngSpice. It also | + | comes with Spice, since no two Spice implementations share the same input language. |
| - | demonstrates that modelgen can generate code for different simulators, and | + | In addition, we have explored a method to feed standardised circuits and schematics (from 3b) into |
| - | could become a standard. | + | a 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. |
| - | determined, but we will prefer projects that are supported by NLnet. This 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 analysis, small signal noise, sensitivity, pz. These are of | + | We have maintained, updated, and 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 Gnucap, mostly related to new Verilog-AMS |
| - | in combination with Verilog-AMS modelling capabilities. | + | features. For 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. | ||