Re: [ng-spice] Readline Response
Here are some additional comments on junction diodes, algorithms etc...
>
>
> On Thu, 19 Aug 1999, Michele Quarantelli wrote:
>
> > 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.
>
> I did not get the point: should we have a unified diode model (with many
> paramters for deep submicron diodes) or different models ?
>
I think we should have different diode modelcards in order to support as
many foundries as possible.
>
> > 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.
> I was not aware of these patches, I am trying to search these patches, can
> you give me an URL or an ftp site. I will download them and apply.
>
Yup, well done, Paolo.
>
> > 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).
> This is the HSPICE implementation, in the future it will be implemented,
> HSPICE is THE standard in this field.
>
> >
> > 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.
> Can you better explain 1).
Traditional transient analysis is based on a direct integration
of circuit equations using some kind of BDF. This approach definitively covers
most of the designer's need. However, when dealing with high frequency (>
100Meg) systems where signals with very different time scales exist the
analysis has to be carried out with a very fine time-step to "catch" the
fastest signal and long enough to cover the entire low frequency signal
spectrum (e.g. a mixer working at 900meg downconverting a 200k signal).
The traditional approach in this case doesn't fit very well ...
Different algorithms have been developed to solve the time domain steady state
condition of a circuit and I mentioned some of them up above ... I'm sure you
have heard of commercial simulators like Spectre, Harmonica, etc ... which
implement some of the above algorithms.
It would be nice to have some of them included ...
> 2) What about the fft package available on the net in netlib ?
I think it could be used ... I'll check it asap.
> 3) I am interesetd in this kind of analysis: I am planning to extract the
> s-paramters of a two port network (they always exists) and then convert
> them in the y,z,... paramters. this is the method used by smartspice and
> seems good. Smartspice uses a circuit (automatically applied) to perform
> this task. On my books I have find a theoretical circuit based on ideal
> tranformers, not very useful. Still in search of good references.
>
> Paolo
>
>
A final note: I'm currently comparing the last release of Berkeley Spice
(spice3f5fix) against ng-spice. During op simulation of a LNA amplifier
(including a grounded MOS device as a capacitor) I saw ng-spice converging to
the wrong solution (i.e. vds not equal to zero) !!! I was using MOSIS BSIM3v1
model so I re-compiled the bsim3v1 code (with some modification ... of course)
and ... same result !!! At this point I'm quite concerned with ng-spice
reliability ... Anyone having the same problem ?
Also how do I access the develpment release ? I tried anonymous cvs but it
didn't work ...
Michele
Partial thread listing:
- Re: [ng-spice] Readline Response, (continued)