LTspice Loafing?

Just crank down the time step?

I want a Spice with continuous waveform updates and component value sliders. And 1000x the compute power that I have now.

It's impressive how fast one can converge two or three variables when it's trimpots and oscilloscopes, when it might never be possible with Spice.

XOs are best analyzed in frequency/phase; startup delay seldom matters. But I design triggered oscillators that need to be analyzed in time domain. Spice is terrible, in transient mode, for displaying the frequency of a waveform to PPMs. Useless, actually.

I bet I can breadboard and test some oscillators faster than I could simulate them! And save most of that $100K.

--
John Larkin         Highland Technology, Inc 

lunatic fringe electronics
 Click to see the full signature
Reply to
John Larkin
Loading thread data ...

My wait state is in time, so you have easier control over how fast the sim goes. Also it avoids generating huge files, which would happen by cranking down the time step.

I never use this feature myself. Just never, ever. Added it for completeness. Adding Monte Carlo gave me the ability to stuff the matrix directly, so it was a minor detail to add real time change of the values.

Yep.

Sure, but running De-qued and dividing by the de-qued facter does give you a really good estimate of what it does at full Q. I have checked this extensively over the years by running PSS and TRAN.

Sort of strange really. Don't matter if the series c1 of the xtal is 0.1ff or 10p, the loop gain peak stays the same value.

When your dealing with board level stuff, the idea of still getting a net low impedance through a 0.1ff cap is notable.

Sure, for just the oscillator, but the whole chip I design uses 10,000s of transistors, so the cost has to be for paid anyway.

An oscillator chip, is quite a bunch of stuff. A TCXO has chebychev function generators to compensate the frequency v temperature response. An OCXO has heater control feedback loops. Several regulators, output rf buffers, which are non trivial to get -165 dBc noise. VCXO linearizing circuits. Its a bit of a meal to get 50ppb on a TCXO and 1ppb on a TCOCXO. Every chip individually compensated.

-- Kevin Aylward

formatting link
- SuperSpice
formatting link

Reply to
Kevin Aylward

Frequency-domain analysis is faster than transient, but it ignores nonlinearities, and nonlinearities are what ultimately matters. Which is one reason that I buy XOs nowadays and don't design them. You can do that for me.

There are some stunning 1x1" OCXOs around lately, incredible phase noise specs for ca $80. Maybe people have figured out how to slice SC-cut crystals cheap. Just a good bare SC-cut rock used to cost $250.

--
John Larkin         Highland Technology, Inc 

lunatic fringe electronics
 Click to see the full signature
Reply to
John Larkin

Whoops, I made an error. Turns out my laptop was throttling the CPU while charging when the battery was at very low charge when I ran the test...

With a fully-charged battery I'm getting about 700uS/sec simulation speed. 150uS/sec did seem sluggish for an i7...

Reply to
bitrex

Am 10.03.2017 um 23:56 schrieb Kevin Aylward:

Freud at work?

Yeah, unless you get pipeline stalls from pivot checks or dealing with sparse matrix methods because your huge matrix contains mostly zeroes. The existence of hand-optimized packets for that is proof enough that there _are_ performance problems.

In our first CAD course, we had to write that stuff all ourselves before we were given the Spice 2G4 sources: constructing the matrix, finding the o/p, linearization around the o(p, plugging transistors into the matrix, time discretization of Caps/ companion models, inversion, pivoting, integration and all that.

And I have also ported the 3F version to Interactive Unix on the 286. That was not so funny with the small segments.

regards, Gerhard

Reply to
Gerhard Hoffmann

That is really good!

  • LTspice Alternate Solver 33.129 seconds
  • LTspice normal solver 22.392 seconds
  • LTspice normal solver with .save 13.306 seconds
  • NGSPICE 9.660 seconds
  • NGSPICE with .save 9.002 seconds

OS: Windows 7 Service Pack 1 CPU: Intel(R) Core(TM) i7-4930K CPU @ 3.40GHz Logical processors: 12 Total DRAM available = 32702.8 MB. DRAM currently available = 25883.0 MB.

The big speedup caused by .save is the most remarkable for me. My PC has an SSD and ReadyBoost turns itself off (its says: no gain possible).

-marcel

Reply to
mhx

This don't make any sense to me. LTSpice should be running several times faster than NGSpice.

Are you running default settings in LTSpice, or say, setting a minimum step time?

It is possible to override stuff in LTSpice, such that it aint running anything like as fast as it should. Its also possible to speed it up a bit by changing some settings for some circuits.

I would be interested in what settings you have for reltol, trtol and min step size

The spice default Spice3 value of trtol is 7. I think LTSpice might use 1, I use 1 in SS. The 1 setting can slow it down by a factor of 3, but for some switching circuits, a value of 7 generates way too large errors.

-- Kevin Aylward

formatting link
- SuperSpice
formatting link

Reply to
Kevin Aylward

Win98 was the last OS AFAIK to default to PIO. So yes it's possible but not very likely.

NT

Reply to
tabbypurr

OK, I have now ran the example posted by John at the top of this thread. Is this the one that has been run here?

If so, the speed problem is trivial.

The tran statement is

.tran 0 20m 10n uic

This runs in about 15 secs on my laptop in LTSpice.

However.....

If you right click on the tran line in LTSpice and remove the max time step entry, to let LT does what it does, it runs in < 1/2 sec, probably even 100 ms. Its just zooms through, so difficult to tell.

As I keep mentioning, those that use Spice, should take the trouble to at least learn the most trivial, elementary basics of it.

You all need to understand that the max time step, if used, must be set with some modicum of rationality. Dah...

Like, 10ns in 20us is 2,000 points per cycle. Typically, you only need 20 or so, depending on how jaggered you want the waveform.

-- Kevin Aylward

formatting link
- SuperSpice
formatting link

Reply to
Kevin Aylward
[snip]

Yep. Virtually ALL of the questions about LTspice are from those too lazy to RTFM.

(On the other side of the tolerances are those who set such a loose timestep that their circuit converges... and they swear by it, even when I demonstrate in PSpice that it sings... I think the tune is "All Hail Larkin" >:-} ...Jim Thompson

--
| James E.Thompson                                 |    mens     | 
| Analog Innovations                               |     et      | 
 Click to see the full signature
Reply to
Jim Thompson

Yes.

It is not a problem? I only show that LTspice has been unchallenged for a long time and others are catching up.

That is cheating in the context of a benchmark, but LTspice runs it in 252 ms here (normal solver, with .save line).

In NGSPICE that becomes 262 ms, with the default (double-precision) solver.

I am sure most people know that.

-marcel

Reply to
mhx

Because?

This is a properly compiled and optimized (for AVX and open-mp) console-based NGSPICE from the latest Git branch. It has XSPICE integrated and has my custom mods for power-electronics (but these shouldn't cut in here). It has a Berkeley parallel BJT model, but that is only slowing it down here as there is only a single transistor in this circuit.

I use the PH settings, but added "nomarch". Plotwinsize is NOT used, it has no effect (here).

I think LTspice runs as fast as it can here (see also the other timings presented in this thread). NGSPICE is running faster that you seem to expect.

Default: reltol=1m, trtol=1. Min step size can't be set, but max step size is 10ns (as prescribed).

A too high value of TRTOL can also slow down some circuits.

-marcel

Reply to
mhx

Because LTSpice does compile on run to resolve memory addresses for every individual circuit.

For the lase 15 years or so it has been 3 times fast as anything else on Windows.

I don't keep track of it much, other then noting that it added multicore support.

None on this addresses the special nature of the LTSpice assembler

It's explained here:

formatting link

Snippet:

" Ideally, the addresses of the data required for a calculation would be known ahead of calculation time so that data can be efficiently fetched and the FPU doesn?t have to wait for it. LTspice eliminates the overhead in getting the data to the FPU with self-authoring assembly language source written at run time, after matrix memory has been allocated, and the addresses returned from malloc() are known. This late authored code can resolve concrete matrix element addresses in line with LTspice eliminates the overhead in getting the data to the FPU with self-authoring assembly language source written at run time, after matrix memory has been allocated, and the addresses returned from malloc() are known. This late-authored code can resolve concrete matrix element addresses in line with the code so the data can be efficiently loaded, allowing the FPU to operate with the pipeline full."

This one transistor circuit just don't cut it for me. I would need to see a much more serious design to make any conclusions as to the speed/convergence comparison of LTSpice and NGSpice.

Does the latest version of NGspice do the aforementioned just in time assemble? Has it done anything to its convergence algorithms?

If not, I would be pretty surprized if NGSpice comes anywhere near LTSpice in real designs. LTSpice is particular good in convergence.

The problem with LTSpice, is its incredibly shit GUI.

Min was basically, a typo. Meant to be max.

Maybe in some vague theory, never, ever, seen that happen though.

-- Kevin Aylward

formatting link
- SuperSpice
formatting link

Reply to
Kevin Aylward

It is a typically a problem when it takes 50 times longer, and uses 100 times more file size than it needs to.

LT Spice has only been unchallenged on Windows only. Those of us that use $100k per seat, per year pro IC design tools use Spices on Linux that multicores on both the matrix solving and device evaluation, for many years.

What is the cheat?

LTSpice uses its own algorithms to get the best speed and accuracy. Max step time should usually be left as default for most simulations.

A bench mark means letting each system run as it wants to run.

Its an interesting result, but on its own means nothing. See other post.

Apparently not. Its probably the most typical issue I get from those that use SuperSpice.

Where do you get your information from?

-- Kevin Aylward

formatting link
- SuperSpice
formatting link

Reply to
Kevin Aylward

s

n

so

That makes perfect sense, but the proof of the pudding is in the eating.

a

nce

LTspice bogs down for larger circuits, e.g. the mcnc or ISCAS benchmark sets. Do you have a netlist that would convince you?

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.

e

That is true, there was a lot of catching up to do there, and more would be welcome.

I have seen worse, even today :-)

in

1,

ome

My remark didn't make sense, as I agree that TRTOL should not be too large. A value of 1 is fine.

I offer you my experimental data. It's good that you question it, I may learn something in the process.

-marcel

Reply to
mhx
[..]

I meant that it would be cheating if I set the options for NGSPICE differently for those of LTspice, especially for those options that have a large influence on run speed.

I interpret your last statement that one should optimize the settings for each simulator such that they run as fast as they can. That makes some sense, and the advantage for the reader is that they may learn something they didn't know yet.

My colleagues.

-marcel

Reply to
mhx

LTSpice, has been proven to be the fasted, "non pro tool", on Windows for many years.

There are of course, products like FastSpice from Berkeley Design Automation, now owned by Mentor. It can reliably do millions of transistors. Its Linux/Unix though.

I have a SMPS example in SuperSpice that I compared with LTSPice maybe, 15 years ago. LTSpice was something like 3 times faster.

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 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.

This depends on the size of the circuit. Are you a pro?

I routinely run analog ASIC simulations in my day job of maybe, 20,000 to

100,000 nets. Large circuits get really bogged down in solving the matrix.

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.

I did do fair bit of experimenting on this for SMPS and Sigma-Delta Converters where it definitely all goes to pot with a value of 7. I can't say I really agree with Ken in general though.

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

-- Kevin Aylward

formatting link
- SuperSpice
formatting link

Reply to
Kevin Aylward
[..]

I disagree. Its because the options can have a large effect on speed, that its misleading to do make then the same. LTSpice does a lot of stuff automatically, such that if you set it the same as Spice3, you can cripple it. Its not a fair test. LTSpice is very good at getting fast results without any user input.

To know whether one spice is faster/accurate than another, you need to set each one to the setting that make each one as fast/accurate as possible.

How many colleagues do you have that respond to spice customer support? :-)

Well, sonny...

I have been at this some while, although not as long as old man Jim T. I do have a pretty good idea of the spice knowledge of fellow analog IC designers, and the capabilities of spice customers as well. I also have experience of receiving initial support from the Cadence Application Engineers when trying to resolve technical problems of my own, that provides ample evidence to the level of anticipated answers to questions...

I would say, that your colleagues are a rather special set.

-- Kevin Aylward

formatting link
- SuperSpice
formatting link
formatting link

Reply to
Kevin Aylward

[..]

That statement needs no proof. I meant proof for the snippet's claim that pointer chasing is the main cause of inefficiency in SPICE.

I don't doubt that.

[..]

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.

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.

Your name is still listed in the manual, but I didn't know you worked on the Chan Core model.

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).

Definitely. [..]

Which paper is that?

As far as the source code goes, TRTOL always multiplies with the normal TOL value (sum of volttol and chargetol). It does trickier stuff when the compile option NEWTRUNC is enabled, but that is not the case in NGSPICE. Actually. my tests said that NEWTRUNC is not doing any good.

I think I again have to agree with you.

I think TRTOL=1 and RELTOL = 1m is fine, but I'll remember this when using SuperSpice.

-marcel

Reply to
mhx

May I offer you guys a more complicated, but still "all cards on the table" discrete, circuit to test with, then?

Schematic screenshot:

formatting link
Netlist:
formatting link
(YMMV with other TL431 models; this is tuned for the TI one, included. Other credits: MOSFET model is Motorola, SB160 is Thomatronik GmbH, 2N3904/6 are... dunno, Fairchild maybe?)

Output, overall:

formatting link
Zoom (last 10us):
formatting link

Simulation time: it's Altium, so it's terrible. Nevermind that.

LTSpice: seems to run fine but change RSHUNT --> 1/GSHUNT. Doesn't seem to be using more than one core; perhaps a bigger circuit is necessary?

Tim

--
Seven Transistor Labs, LLC 
Electrical Engineering Consultation and Contract Design 
 Click to see the full signature
Reply to
Tim Williams

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.