Re: modelgen & veriloga
al davis <[email protected]>
| Newsgroups | gmane.comp.gnu.gnucap.devel |
|---|---|
| Message-ID | <20200226021808.5e40053a@z> |
On Tue, 25 Feb 2020 00:51:46 +0100 Vincent Pinon <[email protected]> wrote: > I would like to simulate Analog(+MS) IC designs with recent compact > models (PSP103, BSIM-IMG), which are delivered as VerilogA code. On > commercial programs, I also often drive my simulations with > Verilog-A(MS) blocks. The big goal for gnucap is and has been to be a high performance multi-language AMS simulator. > > Running these in gnucap would be really cool :) > > I have read on your site that ADMS seems sort of a dead-end to load > VerilogA code, which I agree after struggling to get these models > understood by the NGspice back-end (with no success)! Felix is taking care of ADMS. I could not get into the XML approach. Also, it lacks some very important features. > I read you were > thinking of evolving your modelgen tool for this kind of task, > unfortunately the gnucap-modelgen-verilog repository on savannah is > empty. I have some unreleased code for this. In the last few years, some personal matters have gotten in the way of getting any real work done. The subcircuit based model structure and indirect stamp is actually faster when it matters than the spice style flattening of modules and direct stamp. ADMS does not support this, so the "spice-wrapper" uses copy-in-copy-out to work around it, which has a speed penalty. The gnucap matrix solver rarely solves the whole matrix. Usually, it does low-rank updates and partial solutions, while giving the illusion of doing complete solutions. There is some overhead in the subcircuit representation inside devices, but there are also opportunities for optimization that would not exist otherwise. Consider, for example, the source to substrate diode that is part of any MOSFET model. In many circuits, the source is connected to the substrate. Using a subcircuit representation, that diode can be eliminated is it is not needed. In this case, I really do mean "eliminated". You might see a similar situation (but the computer may not see it) when the source to substrate voltage is constant, even when it is not a direct connection. In this case the diode is there, but only processed once on the initial DC, then not touched again. This requires the model compiler to generate the proper structure. The subcircuit representation uses several pseudo-devices, most significantly poly_g and poly_cap, which handle convergence checking and step control. This aspect of gnucap is more robust than that of spice. > I am thinking of spending some time on this for the months to come (I > already know analog simulation & C++ quite well) Do you have any > pointer to help me to start? Code, discussions, advice, ideas... We really need the help. Where to start? Understand the architecture of gnucap from a software-engineering viewpoint, especially the plugin system and model interface. It is intended that almost all new work is done in plugins, and that you can do plugin development with a standard installation of gnucap, as might be installed by a distro's binary package. A model compiler, whether ADMS or modelgen based, or something else, generates a plugin. > > Cheers and thanks for your work!