LTspice simulation speed

[ldg]

Has anyone benchmarked LTspice against any of the standard simulators
- like Hspice, Smartspice, Pspice, and so forth?

I ran the same circuit on Smartspice and LTspice. LTspice finished a
200us run in almost exactly 24 hours. Smartspice is still thinking
about it, making it to only 6us in the same time. Worse, Smartspice
is on my faster machine (3200+) and LTspice ran on my slower 2100+
machine. LTspice seems incredibly faster. Same netlist; same models;
same control statements - only LTspice saved every node and created a
23gig .raw file. Smartspice is saving a fraction of the nodes.

Of course, the LTspice results are not very useful for this
application without the .savebias command

(Had to say that

Regards,
Larry

 

[Mike Engelhardt]

Larry,

Has anyone benchmarked LTspice against any of the standard
simulators - like Hspice, Smartspice, Pspice, and so forth?

A while back I posted some LTspice vs. Pspice results.
Here's a copy of the post and same list annotated with hspice
results. The compelling performance of LTspice is what it does
on BSIM3 models used in-house here at the foundry.

--Mike

--- snip ---

Anybody here ever did benchmarks with various
SPICE's [i.e. to compare speed]?

The closest thing to a standard is something called
the MCNC benchmark suite. It's a collection of
difficult-to-solve circuits. I use it as part of
the basis for a regression test for LTspice releases
since many people have the circuits and run them.
These are IC transistor level simulations using
mostly obsolete device types(MOS2 and MOS3), so it
the benchmark suite doesn't really relate to the
way anyone uses a SPICE program these days(A more
widely relevant benchmark suite would use BSIM3
MOSFET's). If you're interested, here's a zip file
containing the files I use:

www.concentric.net/~Pmte/suite.zip

Add here are todays run times(lower times are better).
I've included another popular simulator for reference
and asterisks by the best times.

LTspice PSpice Hspice
2.05y 9.2.3 2003.09
ab_ac 4.750* 7.59 14.63
ab_integ 0.109* .23 0.17
ab_opamp 5.454* 6.44 7.72
arom 3.656* 6.94 3.34
astabl 1.046* 4.52 5.21
b330 2.172 3.16 1.90*
bias 3.234* 5.19 8.63
bjtff 2.453* 4.17 2.94
bjtinv 7.594* 13.03 14.28
counter 7.234* 15.16 7.40
cram 0.625* .91 0.74
e1480 0.250 (fails) 0.09*
g1310 3.969* 10.91 5.45
gm1 5.562* 12.39 11.14
gm17 2.703* 4.47 2.92
gm19 12.625 (fails) 9.37*
gm2 1.125* 4.91 3.21
gm3 3.453* 8.66 8.13
gm6 5.109* 13.45 11.84
hussamp 0.781* (fails) 1.42
jge 33.875 (fails) 9.08*
latch 0.969* 2.30 2.42
loc 46.687 8.86* 10.64
mike2 5.797* 37.83 21.39
mosrect 9.734* 17.22 29.14
mux8 6.531* 12.00 11.91
nagle 0.672* 1.28 1.53
nand 2.250 1.08* 2.45
opampal 5.109 1.41* 4.50
optrans 7.500 6.17 3.14*
pump 0.016* .23 0.49
rca 1.719 1.53 1.45*
reg0 4.406* 37.22 28.78
rich3 35.610 (fails) 4.67*
ring 5.562* 10.33 19.36
ring11 2.360* 3.11 4.72
schmitecl 0.015 .16 0.06*
schmitfast 8.297* 21.16 29.09
schmitslow 10.781* 23.84 37.28
slowlatch 0.156 .22 0.11*
todd3 0.156 .22 0.06*
toronto 5.031* 11.74 11.72
vreg 0.735* 2.16 2.86

WINS: 30 3 10

 

[Jim Thompson]

On Wed, 15 Oct 2003 10:36:38 -0700, ldg <lgipson@ix.netcom.com> wrote:

Has anyone benchmarked LTspice against any of the standard simulators
- like Hspice, Smartspice, Pspice, and so forth?

I ran the same circuit on Smartspice and LTspice. LTspice finished a
200us run in almost exactly 24 hours. Smartspice is still thinking
about it, making it to only 6us in the same time. Worse, Smartspice
is on my faster machine (3200+) and LTspice ran on my slower 2100+
machine. LTspice seems incredibly faster. Same netlist; same models;
same control statements - only LTspice saved every node and created a
23gig .raw file. Smartspice is saving a fraction of the nodes.

Of course, the LTspice results are not very useful for this
application without the .savebias command

(Had to say that

Regards,
Larry

Could you send me netlist and device library? I'll run it on PSpice
v10.0.0 I'll even do a .SAVEBIAS for you ;-)

[This weekend :-]

...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona Voice480)460-2350 | |
| E-mail Address at Website Fax480)460-2142 | Brass Rat |
| http://www.analog-innovations.com | 1962 |

I love to cook with wine. Sometimes I even put it in the food.

 

[Paul Burridge]

On Wed, 15 Oct 2003 10:36:38 -0700, ldg <lgipson@ix.netcom.com> wrote:

Has anyone benchmarked LTspice against any of the standard simulators
- like Hspice, Smartspice, Pspice, and so forth?

I tried at least 6 well-known simulators before I tried LT. LT pissed
all over all of them. I genuinely believed it was somehow faulty and
it wasn't carrying out the sims properly! Fortunately I know better
now and have happily stuck with it. Actually I would have given up
simulation altogether if I hadn't found LT.
--

"Windows [n.], A thirty-two bit extension and GUI shell to a sixteen bit patch
to an eight bit operating system originally coded for a four bit
microprocessor and produced by a two bit company."

 

[Charles Schuler]

"ldg" <lgipson@ix.netcom.com> wrote in message
newss0rovs6hbjpkp3su2i77rgg0mf53ose6j@4ax.com...

Has anyone benchmarked LTspice against any of the standard simulators
- like Hspice, Smartspice, Pspice, and so forth?

Don't have the "standards" but have found LTSpice rather quick as compared
to what I do have.

 

[ldg]

On Wed, 15 Oct 2003 13:29:10 -0700, Jim Thompson
<invalid@invalid.invalid> wrote:

ould you send me netlist and device library? I'll run it on PSpice
v10.0.0 I'll even do a .SAVEBIAS for you ;-)

Hi Jim,

I'd be happy to send a netlist, but first I need to define "run" I
guess using LTspice.

I took a much smaller portion of the die (mostly analog) and tried
this yesterday with the new .savebias feature - which worked great.

The file had problems with LTspice, but ran easily with smartspice.

First, there seemed to be some sort of error in the .global ground
connections. At least I think that's what happening. I have digital
gates, for instance, that have the right inputs with no outputs.
Internal nodes seemed to float, so I'm assuming it's the global
grounds since I ran +v like a signal.

My netlister doesn't add $G_ on global nets inside subcircuits, but
does add the proper .global statement at the top (hspice compatible).
When I netlist for pspice, it routes the globals in the .subcircuit
calls, still not using $G_ on any node. Somewhere in this mess is the
right syntax for LTspice, but I don't seem to have found it yet.

There's another issue as well. I created my .save command file with
smartspice since it outputs a formatted file from the .savebias
statement:

..SAVEBIAS "anatst1.TR" TRAN TIME=1U REPEAT NIC

The "repeat" keyword saves on 1us centers and the NIC does the
formatting (as I remember). This results in an easily editable file,
substituting ; for = and .save (or .probe in smartspice) for .ic (I
also run a script to get rid of lines with n_ in them):

*------------------------------------------------------------------------
*
* SmartSpice .SAVEBIAS file from:
*
* Input file: anatst1.cir
* Title: Anatst1 - typ
* Name: tran1 (Transient Analysis, 27 deg C)
* Date: Fri Oct 17 06:06:17 2003
* Time: 1.20101e-006
* Repeat: yes
*
*------------------------------------------------------------------------
..IC
+ ntime= 1.201013999427926e-006
+ new_delta= 1.8665904e-011
+ v(0) = 0.0000e+000
+ v(5p75) = 5.7500e+000
+ v(vneg) = 0.0000e+000
+ v(vss) = 0.0000e+000
+ v(clkex8i) = 0.0000e+000
+ v(_por) = 5.0000e+000
+ v(xu3.xu3.n_11) = 9.5849e-001

LT spice wouldn't take the .save file created this way. I'm thinking
it may want colons instead of periods in the subcircuit calls - just a
guess at this point. So there didn't seem to be an easy way to create
the large .save file to limit the number of saved vectors.

(The new file LTspice creates is ascii, but isn't formatted. I'm going
to have to figure out the easiest way to edit it I guess since it's
something I'll do over and over again.)

The only way I've found to view hierarchy at this point in LTspice is
to program a drop down menu before the run, asking it to save every
node. This creates a huge mess to sort through as the hierarchy has
been flattened in the vector selector. (The programming in the drop
down menu also seems to go away when a new netlist is loaded - which
gets tedious.)

One other thing. My layout guy wanted $LDD tagged on the end of the
few high voltage transistors for lvs purposes. Smartspice sees the
dollar sign as "end of line" . LTspice chokes. So I have to do some
hand editing or create special device symbols.

So I have some work to do before I can send this to you. If anyone
has an example of these syntax's for LTspice, it would help.

- Still coming up to speed with LTspice.

Regards,
Larry

 

[Mike Engelhardt]

Larry,

First, there seemed to be some sort of error in the .global
ground connections. At least I think that's what happening.
I have digital gates, for instance, that have the right inputs
with no outputs. Internal nodes seemed to float, so I'm
assuming it's the global grounds since I ran +v like a signal.

My netlister doesn't add $G_ on global nets inside subcircuits,
but does add the proper .global statement at the top (hspice
compatible). When I netlist for pspice, it routes the globals
in the .subcircuit calls, still not using $G_ on any node.
Somewhere in this mess is the right syntax for LTspice, but I
don't seem to have found it yet.

LTspice understands $G_... as global nets. In addition, you can
declare any nets you want to be global with a .global statement.

There's another issue as well. I created my .save command file
with smartspice since it outputs a formatted file from the
.savebias statement:

.SAVEBIAS "anatst1.TR" TRAN TIME=1U REPEAT NIC

The "repeat" keyword saves on 1us centers

OK, LTspice was updated to execute the "REPEAT" keyword. I think
PSpice recognizes it but I don't know that it actually works.

and the NIC does the formatting (as I remember).

My guess is that the NIC causes a .ic statement instead to be
output instead of a .nodeset statement. Anyway, it would be a
good idea to be able to do that, because otherwise you have to
edit the .nodeset statement(a recommendation to the solver) in
the .savebias file to a .ic statement which is a condition to
the solver.

.IC
+ ntime= 1.201013999427926e-006
+ new_delta= 1.8665904e-011
+ v(0) = 0.0000e+000
+ v(5p75) = 5.7500e+000
+ v(vneg) = 0.0000e+000
[...]
LT spice wouldn't take the .save file created this way.
I'm thinking it may want colons instead of periods in the
subcircuit calls[...]

Yes, LTspice uses colons instead of periods. The exact name
commputation method will have other differences. To use
a PSpice .savebias in LTspice you should use the nosubckt
keyword to suppress those nodes it won't be able to use anyway.
Also, ntime and new_delta are not recognized by LTspice.

(The new file LTspice creates is ascii, but isn't formatted.
I'm going to have to figure out the easiest way to edit it
I guess since it's something I'll do over and over again.)

It's formated to be at least 80 columns wide(There's no line
length limit in LTspice so it could put it out as a single
line and still read it in). It takes time and fragments
memory to splice all those continuation lines together, so
for bigger circuits it's cleaner to put as much on one line as
possible.

The only way I've found to view hierarchy at this point in
LTspice is to program a drop down menu before the run, asking
it to save every node. This creates a huge mess to sort
through as the hierarchy has been flattened in the vector
selector.

You can use a .save(or .probe statement) to save only some
list of nodes and currents. See Tools=>Control Panel=>Default
Saves for other options. Usually you check the top three and
maybe the last one. The other three options are for internal
diagnostics. BTW, the "Add Trace" allows you to enter a filter
so that only names following a pattern are displayed.

One other thing. My layout guy wanted $LDD tagged on the
end of the few high voltage transistors for lvs purposes.
Smartspice sees the dollar sign as "end of line".

A dollar sign introduces a comment mid-line in hspice. LTspice
may or may not see it as a mid-line comment, depending on
it's context. For example, it accepts dollor signs in any
nodename for PSpice compatability.

LTspice chokes.

Chokes? Perhaps it needs a clearer error message. You can send
me a deck to the e-mail address on the Help=>About dialog box
if you think there's a problem.

--Mike

 

[ldg]

Thanks for the help Mike.

On 17 Oct 2003 22:03:43 GMT, "Mike Engelhardt" <pmte@concentric.net>
wrote:

Chokes? Perhaps it needs a clearer error message.

What I meant to say is that LTspice said an error has occured. All
the lines had on them was $LDD at the end of the fet statement:

M11 N_48 vb1 vneg vneg NU L=3U W=20U M=2 $LDD

I think this should have been interpreted as a comment, but it came
back as an error. Unless I'm dreaming, which could be the case.

When I see a simulator say an error occured instead of showing a
warning, it usually means something bad happened. Usually the
simulator will stop the sim right there.

I'll work on this a bit more this week.

Regards,
Larry

 

[Mike Engelhardt]

Larry,

Chokes? Perhaps it needs a clearer error message.

What I meant to say is that LTspice said an error has
occured. All the lines had on them was $LDD at the
end of the fet statement:

M11 N_48 vb1 vneg vneg NU L=3U W=20U M=2 $LDD

I think this should have been interpreted as a comment,
but it came back as an error. Unless I'm dreaming,
which could be the case.

$LDD would be interpreted as a comment in hspice but
not LTspice, PSpice or Spectre. hspice uses a dollar
sign to introduce a mid-line comment whereas LTspice and
PSpice use a semicolon. Spectre uses the C++ style
double slash.

But LTspice shouldn't have a problem with the error
in your syntax -- it just issues a warning: Unknown
parameter "$ldd". To suppress this, change "$LDD"
to ";$LDD", if you must annotate your SPICE netlist
with LVS information. Alternatively, you can use
" $ LDD" A dollar sign with whitespace to either
side is interpreted as a mid-line comment to LTspice
because she's aware of the hspice convention and that
syntax can't confuse any valid LTspice syntax.

BTW, the practice that I do and see others doing is
to generate a different netlist for SPICE then for
LVS. The netlist is generated from the same schematic,
but the symbol attributes and such LVS annotations
are handled differently depending on whether the
netlist is for LVS or SPICE, just as the netlist should
handle issues specific to the target strain of SPICE.

--Mike