Re: [ng-spice] Readline Response


To ng-spice@ieee.ing.uniroma1.it
From Michele Quarantelli <quarante@legs.ing.unibs.it>
Date Thu, 19 Aug 1999 00:21:15 +0200
Delivered-To mailing list ng-spice@ieee.ing.uniroma1.it
In-Reply-To Your message of "Wed, 18 Aug 1999 10:54:13 PDT." <37BAF345.4F0D@ix.netcom.com >
Mailing-List contact ng-spice-help@ieee.ing.uniroma1.it; run by ezmlm
Reply-To ng-spice@ieee.ing.uniroma1.it

> Paolo Nenzi wrote:
> > I gave a look at the sources of the simulator. The simulator uses an
> > object oriented strucuter for devices, as far as I know, the mos models
> > are an extensions of the diode mode (mos model, when simulated, calls the
> > diode model). This approach differs a lot with the one in spice3, and I
> I believe This Is a Good Thing. In spice, every MOS model uses some form
> of source/drain to bulk junction model; the code for it is built in the
> device model evaluation.
> 
> If you support ten MOS models this means nine redundant junction related
> code sections (same thing with e.g. the gate charge code).
> 
> This approach has at least two more problems. Usually the real diode
> model is much better than the s/d junction model in MOS devices. I would
> like to have breakdown in the MOS device but it doesn't support it (it's
> not hard to do it, but you'll have to). Furthermore, if you want to
> upgrade the juction code in the MOS devices, you have to go to all ten
> code instances. This makes hard to maintain the code uniformity.
> 
> On the other hand, forcing the mos code to call the real diode
> evaluation code makes everything cleaner and simpler.
> 
> Serban

ABOUT JUNCTION DIODES:

Today's trend, especially in sub-micron technologies is to develop separate
junction models from device MOS models and tha complete device is then
described as a subcircuit. Check the Philips web site: they developed the
JUNCAP model which can be used in conjuction with the MM9 MOS model.

ABOUT ACS:

Going back to ACS I think the idea is pretty neat, however, it is far from
being an usable simulator. I've tested it and is has poor convergence
properties compared to Berkeley Spice and I think the C++ implementation
could be improved (conversion rather that inheritance should be used).
However, since I'm not a skilled C++ programmer, may be I'm missing something
important which invalidates my position.

ABOUT NG-SPICE:

I tried ng-spice and I was surprised I didn't find applied some patches from
Mcquaire University (spectrum command via DFT, JFET level 2) which could be
very useful. I think the package is included in some release available also
at sunsite.

Another observation is about the bsim3 implementation: It could be useful to
add all the main bsim3 version in the simulator (for example via nested levels
e.g. level=8 -> bsim3.1 level=81 -> bsim3.2 etc ...) this is useful if you
are stuck with extracted models from foundries (e.g. MOSIS provides bsim3.1
models and using them with bsim3.2 gives wierd results).

Finally I would like to point out some features which as of today are of
primary concern for an IC designer:

1) Steady state analysis (Harmonic Balance, Shooting Newton, MPDE, etc ...)
2) good FFT implementation.
3) Two port parameter extraction.

I Hope this is useful.

  Michele

Partial thread listing: