On Monday, April 17, 2017 at 6:38:13 PM UTC+2, Kevin Aylward wrote:> >"Kevin Aylward" wrote in message > >news:pbmdnWA37PxVRmnFnZ2dnUU7-afNnZ2d@giganews.com... > > >wrote in message > >news:779882df-64e0-4433-8b58-fcdce25392ac@googlegroups.com... > > On Friday, March 10, 2017 at 6:03:40 AM UTC+1, mixed nuts wrote: > > On 3/9/2017 2:33 PM, John Larkin wrote: > > > On Thu, 9 Mar 2017 09:53:26 -0500, Phil Hobbs > > > <pcdhSpamMeSenseless@electrooptical.net> wrote: > > > > > >> On 03/09/2017 05:37 AM, Johann Klammer wrote: > > >>> On 03/09/2017 09:29 AM, rickman wrote: > > >>>> I was running some simulations on LTspice and it is not even using > > >>>> 5% of my CPU. Nothing else is topping it and the entire computer > > >>>> is pretty much at idle. What could be limiting the speed? > > >>>> > > >>>> One of the main reasons I bought a laptop with an i7 processor was > > >>>> to speed simulations. Is this wasted on LTspice or am I doing > > >>>> something wrong? > > >>>> > > >>> I think it saves the waveforms to a file as it goes along > > >>> simulating. Where you the one who complained about your hdd being > > >>> slow in an earlier thread? maybe try running the sim from an ext usb > > >>> stick. if that helps it's definitely the hdd. > > >>> > > >> I'd start with a ramdisk and see then. USB sticks are glacial compared > > >> with real flash drives. > > >> > > >> Cheers > > >> > >> >> Phil Hobbs > > > > >> > Try this one. 32 seconds on my new Dell. Runs about 25% CPU. > > > >> Less than 15 sec on an HP flaptop (ZBook G3 i7...) with 12% of one cpu. > >> Slower and busier with a plot updating. > > > > -- > >> Grizzly H. > > >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 > > 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?Yes.> If so, the speed problem is trivial.It is not a problem? I only show that LTspice has been unchallenged for a long time and others are catching up.> 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.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.> 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.I am sure most people know that. -marcel
LTspice Loafing?
Started by ●March 9, 2017
Reply by ●April 17, 20172017-04-17
Reply by ●April 17, 20172017-04-17
On Monday, April 17, 2017 at 5:14:29 PM UTC+2, Kevin Aylward wrote:> wrote in message > news:779882df-64e0-4433-8b58-fcdce25392ac@googlegroups.com... > > On Friday, March 10, 2017 at 6:03:40 AM UTC+1, mixed nuts wrote: > > On 3/9/2017 2:33 PM, John Larkin wrote: > > > On Thu, 9 Mar 2017 09:53:26 -0500, Phil Hobbs > > > <pcdhSpamMeSenseless@electrooptical.net> wrote: > > > > > >> On 03/09/2017 05:37 AM, Johann Klammer wrote: > > >>> On 03/09/2017 09:29 AM, rickman wrote: > > >>>> I was running some simulations on LTspice and it is not even using > > >>>> 5% of my CPU. Nothing else is topping it and the entire computer > > >>>> is pretty much at idle. What could be limiting the speed? > > >>>> > > >>>> One of the main reasons I bought a laptop with an i7 processor was > > >>>> to speed simulations. Is this wasted on LTspice or am I doing > > >>>> something wrong? > > >>>> > > >>> I think it saves the waveforms to a file as it goes along > > >>> simulating. Where you the one who complained about your hdd being > > >>> slow in an earlier thread? maybe try running the sim from an ext usb > > >>> stick. if that helps it's definitely the hdd. > > >>> > > >> I'd start with a ramdisk and see then. USB sticks are glacial compared > > >> with real flash drives. > > >> > > >> Cheers > > >> > >> >> Phil Hobbs > > > > >> > Try this one. 32 seconds on my new Dell. Runs about 25% CPU. > > > >> Less than 15 sec on an HP flaptop (ZBook G3 i7...) with 12% of one cpu. > >> Slower and busier with a plot updating. > > > > -- > >> Grizzly H. > > >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 > > This don't make any sense to me. LTSpice should be running several times > faster than NGSpice.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.> Are you running default settings in LTSpice, or say, setting a minimum step > time?I use the PH settings, but added "nomarch". Plotwinsize is NOT used, it has no effect (here).> 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 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.> I would be interested in what settings you have for reltol, trtol and min > step sizeDefault: reltol=1m, trtol=1. Min step size can't be set, but max step size is 10ns (as prescribed).> 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.A too high value of TRTOL can also slow down some circuits. -marcel
Reply by ●April 17, 20172017-04-17
wrote in message news:605d4f15-d117-4df6-b4d9-274b745b2021@googlegroups.com...> > -- > >> Grizzly H. > > >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 > > This don't make any sense to me. LTSpice should be running several times > faster than NGSpice.>Because?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.>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.None on this addresses the special nature of the LTSpice assembler It's explained here: www.linear.com/docs/46028 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.">> Are you running default settings in LTSpice, or say, setting a minimum >> step >> time?>I use the PH settings, but added "nomarch". >Plotwinsize is NOT used, it has no effect (here).>> 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 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.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.> I would be interested in what settings you have for reltol, trtol and min > step size>Default: reltol=1m, trtol=1. Min step size can't be set, but max >step size is 10ns (as prescribed).Min was basically, a typo. Meant to be max.> 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.>A too high value of TRTOL can also slow down some circuits.Maybe in some vague theory, never, ever, seen that happen though. -- Kevin Aylward http://www.anasoft.co.uk - SuperSpice http://www.kevinaylward.co.uk/ee/index.html
Reply by ●April 17, 20172017-04-17
wrote in message news:75bb9bd2-f0ef-4dd2-9759-b07dc896c4e0@googlegroups.com...> > >> > > >> Cheers > > >> > >> >> Phil Hobbs > > > > >> > Try this one. 32 seconds on my new Dell. Runs about 25% CPU. > > > >> Less than 15 sec on an HP flaptop (ZBook G3 i7...) with 12% of one cpu. > >> Slower and busier with a plot updating. > > > > -- > >> Grizzly H. > > >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 > > 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?>Yes.>> If so, the speed problem is trivial.>It is not a problem?It is a typically a problem when it takes 50 times longer, and uses 100 times more file size than it needs to.>I only show that LTspice has been >unchallenged for a long time and others are catching up.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.> 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.>That is cheating in the context of a benchmark, but LTspice >runs it in 252 ms here (normal solver, with .save line).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.>In NGSPICE that becomes 262 ms, with the default (double-precision) >solver.Its an interesting result, but on its own means nothing. See other post.> 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.>I am sure most people know that.Apparently not. Its probably the most typical issue I get from those that use SuperSpice. Where do you get your information from? -- Kevin Aylward http://www.anasoft.co.uk - SuperSpice http://www.kevinaylward.co.uk/ee/index.html
Reply by ●April 17, 20172017-04-17
On Monday, April 17, 2017 at 10:19:38 PM UTC+2, Kevin Aylward wrote:> wrote in message > news:605d4f15-d117-4df6-b4d9-274b745b2021@googlegroups.com... > > > > > -- > > >> Grizzly H. > > > > >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 > > > > This don't make any sense to me. LTSpice should be running several times > > faster than NGSpice. > > >Because? > > 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. > > >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. > > None on this addresses the special nature of the LTSpice assembler > > It's explained here: > > www.linear.com/docs/46028 > > 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."That makes perfect sense, but the proof of the pudding is in the eating.> >> Are you running default settings in LTSpice, or say, setting a minimum > >> step > >> time? > > >I use the PH settings, but added "nomarch". > >Plotwinsize is NOT used, it has no effect (here). > > >> 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 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. > > 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.LTspice bogs down for larger circuits, e.g. the mcnc or ISCAS benchmark sets. Do you have a netlist that would convince you?> Does the latest version of NGspice do the aforementioned just in time > assemble? Has it done anything to its convergence algorithms?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.> If not, I would be pretty surprized if NGSpice comes anywhere near LTSpice > in real designs. LTSpice is particular good in convergence.That is true, there was a lot of catching up to do there, and more would be welcome.> The problem with LTSpice, is its incredibly shit GUI.I have seen worse, even today :-)> > I would be interested in what settings you have for reltol, trtol and min > > step size > > >Default: reltol=1m, trtol=1. Min step size can't be set, but max > >step size is 10ns (as prescribed). > > Min was basically, a typo. Meant to be max. > > > 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. > > >A too high value of TRTOL can also slow down some circuits. > > Maybe in some vague theory, never, ever, seen that happen though.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 by ●April 17, 20172017-04-17
On Monday, April 17, 2017 at 10:21:06 PM UTC+2, Kevin Aylward wrote:> wrote in message > news:75bb9bd2-f0ef-4dd2-9759-b07dc896c4e0@googlegroups.com...[..]> >That is cheating in the context of a benchmark, but LTspice > >runs it in 252 ms here (normal solver, with .save line). > > 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.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.> >I am sure most people know that. > > Apparently not. Its probably the most typical issue I get from those that > use SuperSpice. > > Where do you get your information from?My colleagues. -marcel
Reply by ●April 18, 20172017-04-18
wrote in message news:406c7b9d-ce9d-4458-b5f3-8ca3cd5407f6@googlegroups.com... On Monday, April 17, 2017 at 10:19:38 PM UTC+2, Kevin Aylward wrote:> wrote in message > news:605d4f15-d117-4df6-b4d9-274b745b2021@googlegroups.com... > > > > > -- > > >> Grizzly H. > > > > >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 > > > > This don't make any sense to me. LTSpice should be running several times > > faster than NGSpice. > > >Because? > > 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. > > >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. > > None on this addresses the special nature of the LTSpice assembler > > It's explained here: > > www.linear.com/docs/46028 > > 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.">That makes perfect sense, but the proof of the pudding is in the eating.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.> >> Are you running default settings in LTSpice, or say, setting a minimum > >> step > >> time? > > >I use the PH settings, but added "nomarch". > >Plotwinsize is NOT used, it has no effect (here). > > >> 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 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. > >> 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.>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. 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.> Does the latest version of NGspice do the aforementioned just in time > assemble? Has it done anything to its convergence algorithms?>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? 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.> > > 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. > > >A too high value of TRTOL can also slow down some circuits. > > Maybe in some vague theory, never, ever, seen that happen though.>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. 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 http://www.anasoft.co.uk - SuperSpice http://www.kevinaylward.co.uk/ee/index.html
Reply by ●April 18, 20172017-04-18
wrote in message news:3e3875a4-5d65-419c-a571-0fa326aa5d59@googlegroups.com... On Monday, April 17, 2017 at 10:21:06 PM UTC+2, Kevin Aylward wrote:> wrote in message > news:75bb9bd2-f0ef-4dd2-9759-b07dc896c4e0@googlegroups.com...[..]> >That is cheating in the context of a benchmark, but LTspice > >runs it in 252 ms here (normal solver, with .save line). > > 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.>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 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.> >I am sure most people know that. > >> Apparently not. Its probably the most typical issue I get from those that >> use SuperSpice. > >> Where do you get your information from?>My colleagues.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 http://www.anasoft.co.uk - SuperSpice http://www.kevinaylward.co.uk/ee/index.html www.kevinaylward.co.uk
Reply by ●April 18, 20172017-04-18
On Tuesday, April 18, 2017 at 8:15:10 PM UTC+2, Kevin Aylward wrote:> wrote in message > news:406c7b9d-ce9d-4458-b5f3-8ca3cd5407f6@googlegroups.com... > > On Monday, April 17, 2017 at 10:19:38 PM UTC+2, Kevin Aylward wrote: > > wrote in message > > news:605d4f15-d117-4df6-b4d9-274b745b2021@googlegroups.com...[..]> > www.linear.com/docs/46028 > > > > Snippet: > > > > " Ideally, the addresses of the > >> data required for a calculation would > >> data can be efficiently loaded, allowing the FPU to operate with the[..]> >> pipeline full." > > >That makes perfect sense, but the proof of the pudding is in the eating. > > LTSpice, has been proven to be the fasted, "non pro tool", on Windows for > many years.That statement needs no proof. I meant proof for the snippet's claim that pointer chasing is the main cause of inefficiency in SPICE.> 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 don't doubt that. [..]> >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.> 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.> 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.> >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 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.Definitely. [..]> >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? 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 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 think I again have to agree with you.> 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-100uI think TRTOL=1 and RELTOL = 1m is fine, but I'll remember this when using SuperSpice. -marcel
Reply by ●April 19, 20172017-04-19
"Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> wrote in message news:J8mdnd0OuafMvmjFnZ2dnUU7-K3NnZ2d@giganews.com...> 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.May I offer you guys a more complicated, but still "all cards on the table" discrete, circuit to test with, then? Schematic screenshot: https://www.seventransistorlabs.com/Images/AltiumDiscreteFlybackSch.png Netlist: https://www.seventransistorlabs.com/Images/Discrete%20Flyback.nsx (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: https://www.seventransistorlabs.com/Images/AltiumDiscreteFlybackWave1.png Zoom (last 10us): https://www.seventransistorlabs.com/Images/AltiumDiscreteFlybackWave2.png 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 Website: http://seventransistorlabs.com
