[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: modelgen & veriloga

From: al davis
Subject: Re: modelgen & veriloga
Date: Wed, 26 Feb 2020 02:18:08 -0500

On Tue, 25 Feb 2020 00:51:46 +0100
Vincent Pinon <address@hidden> 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

> 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

A model compiler, whether ADMS or modelgen based, or something else,
generates a plugin.

> Cheers and thanks for your work!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]