This shows you the differences between two versions of the page.
— |
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 | ||
+ | $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. |