>wrote in message
>news:179a7510-159e-4454-bf05-89d86da7cdb7@googlegroups.com...
> >LTspice bogs down for larger circuits, e.g. the mcnc or ISCAS
> >benchmark sets. Do you have a netlist that would convince you?
>
> I have a SMPS example in SuperSpice that I compared with LTSPice maybe, 15
> years ago. LTSpice was something like 3 times faster.
>Is that CurrentModeController.sss? It indeed runs in 6.964s. However,
>when I try it, it gives suspicious results (false gate triggers) in
>SuperSpice (as is), LTspice and NGSPICE. In NGSPICE it runs very
>slowly, around 2.527 seconds, because I didn't want to tune the
>options yet.
Yes. However, I could have another go and do another model from scratch,
could probably speed it up a fair chunk. Overtime, I have his habit of
breaking stuff that worked, so its possible its now now strange things.
Recently, I noticed that I have inadvertently removed the sweep of
resistance in dc sweep setup list box. Now fixed.
Note, a lot of the SS examples, are where I just wanted to create demos that
worked, rather than a viable real "design". They are meant to demonstrate
all the features, and the sort of problems you can solve in SS. I think they
are way more extensive than any other simulators examples. There is a lot of
behavioural, system examples.
Most haven't been updated since they were crated. That example actually has
an external gate resister to get convergence, but since then I added RG to
the mosfet core model itself. My mosfet 1 now supports an "enhanced" LTSpice
VDMOS mode.
http://www.anasoft.co.uk/MOS1Model.htm
>> In 2000, it was a real big deal to get practical SMPS sims going. Now, my
>> laptop does 90 GFlops, with 16GB of ram, and does it in about 7 secs in
>> SuperSpice, so speed for board level stuff is not so important now. For
>> analog ASIC, its never fast enough.
>I don't think 7seconds is at all satisfactory when having
>feedback control with 100ms time constants, or when doing
>a PFC with 20 Hz bandwidth.
Its all relative though. Using my aforementioned expensive $100k per seat,
per year, Cadence suite, I often run simulations that last 1/2 or 1 hour.
Main top levels can take a day, some several days. PSNoise is the main
killer.
I started with a HP85 in around 1982 for AC analyses, moving up to DOS
PSpice in 1985 on an XT, so I am sure you can appreciate, that today, 7 secs
for a SMPS, is sheer Luxury. I used to dreeeeeem of such a life when I was
knee high.
On that HP, I wrote my first complex number Gaussian elimination with
partial pivoting routine. I also learned how to move graphic objects on
screen by getting the prior background and XORing stuff. However, all this
software stuff is pissing about really. After 150k lines of SS C++ code, I
am still just a hack. My expertise is really only in analog design.
>> I have a working ngspice-26 so I might give it go. I actually passed on
>> my
>> xspice code model code for the John Chan et la. Hysteresis core model to
>> Paolo Nenzi many moons ago.
>Your name is still listed in the manual, but I didn't know you
>worked on the Chan Core model.
I wrote it from scratch after Mike was lording it over everyone with his LT
implementation. I actually paid £30 to get the paper!
Anyone that wants my full source code to my xspice version is welcome to it.
Just email me.
It would be worth copying in my ASK routines for BSIm3 and BSim4 to
ngspice. I added the code so that all transient terminal currents (d, g,
b,s) are available. The original only has drain. Its an indispensible
feature.
> >No it does not, unfortunately. However, my VTune sessions show
> >that, in NGSPICE at least, most time is spent in the system
> >matrix load phase, not in solving this matrix.
> This depends on the size of the circuit. Are you a pro?
>These were small matrices, and then load time dominates. I have
>the numbers when you are interested. For 1000's of transistors
>(ISCAS and MCNC) solving becomes dominant, but then NGSPICE
>uses KLU (which LTspice doesn't have).
I have considered setting up the latest ngspice to work better with SS. Like
having it as an alternative, engine.
[..]
> >My remark didn't make sense, as I agree that TRTOL should not
> >be too large. A value of 1 is fine.
>
> I consider the setting of TRTOL to be somewhat controversial.
>
>> Ken Kundert (Spectre author) wrote a paper with the view that TRTOL
>> should
>> be set higher, nearer to the spice3 default 7 value and tighten up the
>> accuracy settings, say to 100u or 10u.
>Which paper is that?
I will see if I can dig it out.
> I manually set the best TRTOL and RETOL in my SuperSpice examples to get
> an
> optimum speed/accuracy trade-off. Typically I might use values of 2-4, and
> accuracy 10u-100u
>I think TRTOL=1 and RELTOL = 1m is fine, but I'll remember this when using
>SuperSpice.
TRTOL=1 is a safe option.
For things like Sigma-Dalta, much more risky to increase, especially the
tolerance. Its the bit about chaos that does it :-)
My SS 1st order S-D is ok with retol=1m and trtol=5, but the 2nd order S-D
has something like trtol=1 and relto=100u. It can really mess-up with looser
values.
-- Kevin Aylward
http://www.anasoft.co.uk - SuperSpice
http://www.kevinaylward.co.uk/ee/index.html