Re: [Gnucap-devel] A follow up to a question from a while ago.

[al davis]

On Wednesday 13 August 2008, Thaddeus Meizelis wrote:
> First I added the breakdown mode:

Thank you.  At first glance it looks good.

I will look closer and consider including it as standard.

> I tested it with a couple of simulations and it seems to
> work, so I will include this in my personal builds of Gnucap.

Can you send test files that demonstrate that it is correct?  
The test files should be complete enough to test every line of 
code.  They will become part of the regression suite.

> Now for some questions.
>
> 1. What is the proper way of attaching one of the spice3f5
> models? I tried to do an "attach ./dio.so" but it gave me a
> message and didn't seem to replace the model.

This message?
========
D: already installed, replacing
stashing as D:0
d: already installed, replacing
stashing as d:0
========
It means it was successfully attached, and the old one stashed 
so you can still access it with the name "D:0".

You get this message when a new one has the same name as one 
already loaded, stating that the new one hides the old one, and 
how to access the old one.

> I tried to 
> detach the builtin model, but it wouldn't let me detach the
> builtin.

You can't if it was compiled in, but you don't need to.

> 2. I get the impression that models are going to be replaced.
> things such as user-generated models, standard spice models,
> in short that any work done on the current builtin models
> won't be useful in the future. Is this the case?

I intend to stay out of modeling, other than to provide tools 
for developing them, and ability to use models from a variety 
of sources in a variety of formats.

You will still be able to use and make models with "modelgen", 
but the existing format will probably become less important 
when Verilog-A capability is done.  Most people prefer to use 
standard models, and to write new models in a standard 
language, such as Verilog-A.

I think you will see a gradual transition away from the existing 
forms of models to Verilog-A models in the future.

The capability to use the existing models is not going away.

> 3a. If so, I won't do any more work on the models themselves,
> and the diode model in particular, because if they are going
> to be replaced, I don't want my efforts to be in vain. I have
> been listening on this mailing list, and I understand that
> there are other areas which I can concentrate my efforts on
> other things, such as other gnucap plugins, or maybe n
> extension to Oregano, Gschem, etc, etc.

It is my feeling that if there is an existing model in a usable 
format, it doesn't make sense to rewrite it.  That is why the 
ability to use unmodified Spice C models is so important.

> 3b. If not, since i picked up a lot of knowledge on diode
> models, I could clean the "Yj" section in the diode. I could
> comment sections. I could allow the user to configure which
> model (HSpice, Spice2, Spice3, PSpice) and LEVEL he/she
> wanted to use. 

A set of models that is exactly compatible with all of those is 
VERY useful.

Probably the best way to do this is with several plugins, so the 
user can select which one to use, like with the many BSIM 
models.  Putting them all into one is likely to require lots of 
extra code (if this, else if that ....)  and be harder to 
maintain.  It is up to you.

The existing diode code was written a long time ago, and is a 
mess.

I plan to make some significant refinements to the plugin system 
that should fix some of the roughness you see now.

> I have a couple questions regarding this: Do 
> any other models depend on the diode model? It seems the MOS
> models depend on the diode model, but I am not sure. 

Yes, but don't worry about it.  If necessary, they can still 
depend on the old one.

Plugins are not dependent on each other.  What you do in one 
should not matter to any other.

> Where 
> are the diode flags used? Can I change those without breaking
> other things?

It is really a hack to provide some variants on the model.  If 
it is all in a plugin, you can change anything you want.

> 4. What's the proper way to submit a file to this list in
> case you guys want me to submit my diode? I can't just send
> my post as an attachment can I?

The list removes attachments, mostly as protection against 
malware.

For now, it is probably best to post a link to where it is.

I will set up a way to upload stuff soon.

> 5. By the way, just out of curiosity, how will the models
> work? From what I gather, The plugins will be in a directory
> with a configuration file calling out models and simulators
> in use. The models will be human readable and can be
> downloaded during run time. Is this correct?  I like the idea
> and am willing to contribute toward it.

There will be several ways.

It is possible and will remain possible to static link plugins 
that are clean.  It doesn't work with dirty ones like the spice 
models.  In the future, actual use of this method will be 
discouraged and minimized.

There will be a public directory (something 
like /usr/lib/gnucap) where plugins can be placed to be 
automatically loaded.

There will be another public directory, where plugins can be 
placed to be manually loaded, without specifying a path, like 
the C #include <file>.

You can explicitly specify a complete path.  This works now.

In addition to being able to load a precompiled plugin, as now, 
you will be able to load the source file, which will be 
compiled if needed then loaded.  A configuration file will say 
how to compile different kinds of source files.  For this 
feature to work, you will need to have the compiler and some 
development tools such as "make" installed.

Plugins will also be generated and used automatically in some 
cases.

> IMHO, I would like to see the BV and IBV parameter included
> in the default diode model in some way. I know there are ways
> around it, but without those parameters, you exclude a class
> of components.

Thank you for fixing it.