Wanted: LM-709 (Spice model) National Op-Amp

[Genome]

"Paul Rako" <sp_a_mpa_u_l@yahoo.com> wrote in message
news:fxQYe.3496$Ba2.362@newssvr27.news.prodigy.net...

Can anyone really get any kind of mid-range SPICE to deal with non-linear
magnetics? Does anyone trust it to design a complex flyback converter?

Hmmmmm,

I could go further, but......

Hmmmmm,


DNA

 

[Neil]

Helmut Sennewald wrote:

"Neil" <neilwrites2@hotmail.com> schrieb im Newsbeitrag
news:1126944635.562276.150550@g44g2000cwa.googlegroups.com...
Looking for a spice model or subcircuit netlist for the LM709 from
National semiconductor. I asked intusoft, cause they have a free model
service. I bought their entry level software ICAP/4 8.3.3 from a dealer
purchased in 2000. For reasons I won't mention, I was denied the
request from their sales department.

I was going to email National, but from what I read in Bob's book
"Troubleshooting Analog circuits" he doesn't like S.P.I.C.E.
and for good reason...........

Any help on this request would be great....

Thanks
Neil


Hello Neil,

If you look with Google (uA709 spice) then you will find two
sources for a model.
One is in the library file "opamp.lib" from Microsim/Cadence.
It's a very old behavioral model and I have not tested it.
I don't have a PSPICE license and so I don't would use it.

In this "summer2000.pdf" is a netlist of a test circuit with
the LM/uA709. It's nothing else than an exact copy of the
schematic of the LM709 from National's datasheet.
http://www.spectrum-soft.com/down/summer2000.pdf

http://www.national.com/ds.cgi/LM/LM709.pdf

I used this datasheet and made my own model. I would be
interested to get some feedback about the parameters of my
"invented" transistor models. I have used the reference
designators from the the datasheet to make it easier to
modify the model if necessary.
THe model agrees very well with the performance of the datasheet.
It's a free model. Feel free to use/copy/modify.

I have also made a complete example for LTspice with
a schematic based on a nice symbol and a model file.
Additionally I have made a hierachical block design
which allows to probe down the hierarchy (in the schematic)
to every node of the LM709.

LTspice is free SPICE from www.linear.com .
http://ltspice.linear.com/software/swcadiii.exe

The LTspice user group:
http://groups.yahoo.com/group/LTspice

Download the files from here within the Yahoo group.

Files > Lib > LM709_uA709

Best regards,
Helmut




* LM709 SPICE Model
* Datasheet: http://www.national.com/ds.cgi/LM/LM709.pdf
* Helmut Sennewald
*
* Input compensation B (8) --------------------\
* Input compensation A (1) -----------------\ |
* Output compensation (5) --------------\ | |
* Output (6) -----------------------\ | | |
* Negative supply (4) ----------\ | | | |
* Positive supply (7) -------\ | | | | |
* Inverting input (2) ----\ | | | | | |
* non-inverting input(3) | | | | | | |
* | | | | | | | |
.subckt LM709 In+ In- V+ V- OUT COMP A B
Q7 v+ N001 N005 0 NPN1
R5 v+ N001 10k
Q3 N001 N006 N003 0 NPN1
Q4 N001 N003 N002 0 NPN1
R1 N005 N006 25k
R3 N003 N004 3k
Q15 N004 N004 N002 0 NPN1
R2 N005 A 25k
Q2 A in- N007 0 NPN1
Q1 N006 in+ N007 0 NPN1
Q5 B A N009 0 NPN1
R4 N009 N004 3k
Q6 B N009 N002 0 NPN1
R6 v+ B 10k
R8 N002 N011 3.6k
R10 N011 N010 10k
Q10 N010 N010 V- 0 NPN1
Q11 N007 N010 N008 0 NPN1
R11 N008 V- 2.4k
R9 N012 N011 10k
Q8 v+ B N013 0 NPN1
R7 N013 N012 1k
Q9 comp N002 N012 0 PNP1
R13 N014 V- 75
R12 comp N014 10k
Q12 N015 comp N014 0 NPN1
Q13 V- N015 out 0 PNP1
Q14 v+ N015 out 0 NPN1
R14 v+ N015 20k
R15 N012 out 30k
.MODEL NPN1 NPN (BF=100 VAF=50 RB=100 CJE=4P CJC=2P CJS=2P TF=0.5N TR=10N)
.MODEL PNP1 PNP (BF=15 VAF=50 CJC=4P CJE=8P RB=100 TF=20N TR=200N)
.ends LM709

Very nice..........I will try it this weekend!!, That's great. I tried
that approach from the datasheet, like others mentioned to me. I used a
macro option inside my SPICE program with the common transistor which I
like to use is the 2N4401 and the 2N4403. It's unrealistic, and above
par, cause it has way more gain, higher CMRR, so the I scrapped the
macro, and started over, and I did, before posting to this group.

Thanks
Neil

 

[Neil]

Damn! I don't have that spice program The schematic is on the data
sheet from national semiconductor which I been messing with, but thanks
anyway.

Neil

 

[data2docSAFE at URLfastma]

Hi Neil,

Neil wrote:

Damn! I don't have that spice program The schematic is on the data
sheet from national semiconductor which I been messing with, but thanks
anyway.

Neil

They have a demo version, free, which has these files. Try

<http://www.micro-cap.co.uk>. I haven't been there for quite a while, so
this may have changed.

Regards, BruceR

 

[Paul Rako]

analog:
Thank god, a scientist. Coherent, I suppose, with the IEEE mail domain.
I will install LTspice/SwitcherCAD III and replicate some of my Orcad misery.

People:
The one complaint I heard tonight at Bldg T was that you
can't export the LTspice/SwitcherCAD III work to something that can lay-out a
circuit board. Based on the other buncombe, some of which I may
have inadvertently spouted, I will try it first and see. I guess
the best thing to do is to load the circuit from the EDN article
and see if will converge and correlate to the results Jim Williams
got.

Hey Mike:
Tom Gross was at bldg T tonight as well as Bill so that was a bit of a harmonic
convergence. Sorry about the "somebody said something" but the somebody
was a well-known engineer at a competing company to National and LT so I did
not have his permission to quote him at 3:00 AM last night and why mention any
competitors' companies? When I get sarcastic like that I say "Doh,
pass me a donut." Like the other writer is treating me like Homer Simpson.
I could see how that might apply to my "somebody" comment. I am a little sorry
to see you dismiss the SPICE engine underneath WEBENCH. Maybe it is marketing
jargon but a new release is significant if there was some significant
code-work that has been done. I suspect you rev LTspice/SwitcherCAD III
when you feel there is a significant advantage. I do agree if there is
no sanctioning body like IEEE or W3C or anybody to validate the claim for an
improved engine, one has to be more critical. How can one judge the advance
of proprietary standards unless you guys start opening up your code so the
community can see the difference in the source? Sorry if you feel I am posting
garbage, I am trying to be positive. We are building a 15 MHz 4th-order
low-pass filter to see if WEBENCH can nail that as well as it did the
10KHz filter on the Analog by Design show. Then I will feel pretty good
about it. Hey, maybe the SPICE engine under WEBENCH touts "Stage 3" to just
keep up with you and the "3" in your release.


Also Mike:
Well, the only stories I heard about you tonight is that somebody called you
"Panama Mike". Being a Leon Redbone fan I can understand that as a complement,
it sure sounded like one when she said it.

Kevin:
I have to admit I am a long way from worrying if LTspice/SwitcherCAD III
deals with HSPICE directives. But that did get me to check out your website
and if that SPICE can inter-operate on... oh-- I don't know, EDIF 2 0 0
well that would be pretty cool since I could do work in it and then stuff it
into Orcad or when I get creamed in Orcad I could jump into your SPICE.
As a matter of fact I would pay the price if only so I did not have to
start Orcad in the evil "Mixed Signal" mode where the part properties get
all goofy because PSPICE likes to call instantians "occurances" instead of
"instances" like Orcad does. Back-annotate into that mess once and
you might understand why PSPICE is under-used. Arbitrary handles are
a wonderful thing, please tell Orcad.

And Jim:
Don't call it a cane, call it a walking stick. Or a scepter. Like that
Saran Wrap guy from Lord of the Rings. I see the WWF analog smack-down
as you, Bob and Barrie in a Thunderdome type of deal. Tina Turner is
already signed. The dynamic is all three of you have to get in the dome
and any two can gang up on the third. Then those two face off after
enough personal liability and property damage have been heaped on the
other guy. Now that would be interesting. A prisoner's dilemma au troix.
Tagline: "Three men enter. One man leaves."

I am on vacation next week so I should have time to play with
LTspice/SwitcherCAD III and Kevin's SuperSpice stuff which is at
http://www.anasoft.co.uk/
and I have PSPICE and ICAP/4

And one of you guys has to do a release called "Habanero".
Now that is some hot spice.

And Panama Mike:
Sorry about the "LTspice/SwitcherCAD III is a PSPICE knockoff" crack. I asked
the source tonight and what he intended to say or I what I did not hear was:
"LTspice/SwitcherCAD III is a variant of SPICE."

Well, duh. Shakespeare is a variant of the dictionary. I knew that.

Paul



analog wrote:

Paul Rako wrote:


Well, it was an LT guy that told me LT-SPICE was a PSPICE variant
but I don't have the need to trash people [...]


[cut thinly veiled trashing of various people]


Several years ago EDN magazine did a circuit and gave it to 6 SPICE
vendors and Jim Williams at Linear Tech. If I remember about half
of the programs failed to converge and the rest gave wrong results,
sometimes wildly wrong compared to Jim's real board. Was there a
memo I missed? Have models and SPICE engines gotten that much
better?


LTspice has improved models for inductors and capacitors that allow
realistic parasitics to be entered and computed as an integral part
of the element. This prevents the corresponding branch admittances
from going to zero or infinity for reduced time steps during a
transient analysis, greatly improving run time convergence.

I doubt you or anyone else has a legitimate circuit that would
trip up LTspice.


Can anyone really get any kind of mid-range SPICE to deal with
non-linear magnetics?


LTspice can without breaking a sweat. Download the program and
read the help file topic on L devices.

Regards -- analog

 

[Helmut Sennewald]

"Paul Rako" <sp_a_mpa_u_l@yahoo.com> schrieb im Newsbeitrag
news:%R8Ze.3707$Ba2.1132@newssvr27.news.prodigy.net...

analog:
Thank god, a scientist. Coherent, I suppose, with the IEEE mail domain.
I will install LTspice/SwitcherCAD III and replicate some of my Orcad
misery.

People:
The one complaint I heard tonight at Bldg T was that you
can't export the LTspice/SwitcherCAD III work to something that can
lay-out a
circuit board. Based on the other buncombe, some of which I may
have inadvertently spouted, I will try it first and see. I guess
the best thing to do is to load the circuit from the EDN article
and see if will converge and correlate to the results Jim Williams
got.

Hello Paul,

I am very interested in the article mentioned by EDN.
Could you provide me a link to it or send it to me via email.
I will then try on this circuit with LTspice and give my judgement.
I think we should let the professionals do it who know LTspice.
It's like if you have to judge about a Porsche car.
If you have never driven it, you shouldn't judge it.

Best regards,
Helmut

PS: I also have demo-versions of some other SPICEs to test this
circuit as well if it's not too big for them.
I am not an emplyee of LT.

 

[Mike Engelhardt]

Kevin,

And I was once told that LTSPICE does not allow import
of models from other vendors like ADI and National.

More non-sense. Users can import models and since
LTspice knows most Pspice and hspice syntax,

It don't know HSpice's "hdif" which is used to automa-
tically calculate AD, AS, PS, and PD. These are
absolutely crucial for high speed work.

The lack of hdif is deliberate. LTspice insists that
every dimension, area, and perimeter be explicitly stated
for every transistor. It's done because layout
verification tools and simulators can get confused about
this so I require that the schematic tools compute and
this for each instance so that no other tools can get
confused. When one designs against one's own fab, and
one has a schematic capture tool that can do all that
for oneself(which LTspice's schematic capture will do
but it will remain an undocumented feature), one gets to
do that: Simply once and for all resolve all the
transistor dimensions.

But if the every dimension, area, and perimeter is
instanced out for each transistor, LTspice will run most
hspice models with binning, single quote parameter
substitution and usually inline comments starting the a
'$' when it doesn't conflict this PSpice syntax.

Tell, you what though, its rather irritating that
LTSpice stops dead in its tracks when it gets a
.option it don't know.

Part of having a polyglot simulator is the need to be
more error verbose/intolerant of incorrect SPICE syntax.
Correct hspice syntax is .options numdgt=N If N is
greater than 6, the waveform data or compression
coefficients are stored as double precision, otherwise
LTspice uses single precision. See the help file
(F1 key)=>LTspice=>Dot Commands=>.OPTIONS=>numdgt.

--Mike

 

[Mike Engelhardt]

I wrote,

...Simply once and for all resolve all the
transistor dimensions.

I should mention that this is of course done according
to what the netlist extracted from the schematic targets,
layout or simulation, and with what process lot parameters
in light of how the model libraries were generated/defined.

--Mike

 

[Mike Engelhardt]

Paul,

I do agree if there is no sanctioning body like IEEE or
W3C or anybody to validate the claim for an improved
engine, one has to be more critical. How can one judge
the advance of proprietary standards unless you guys
start opening up your code so the community can see the
difference in the source? Sorry if you feel I am posting
garbage, I am trying to be positive.

Well, I'm not trying to be negative you do post garbage.
You can't evaluate a simulator's performance by looking at
the source code and you should know better. I don't know
if you're deliberately dishonest or ignorant. LTspice is
close to a half million lines of code. You have to compile
it and test the program to see its performance. I'm guessing
your comment is more dishonest than ignorant because it
appears to be an empty challenge to release the source code
of LTspice and trying to couple that challenge with a
challenge of proof of LTspice's performance, presumably
hoping one topic will drop with the other.

But it's not very hard to understand why LTspice runs faster
and is more accurate then other/earlier SPICE engines. I
occasionally give 4hr seminars that explain in some detail
what one needs to do to make a better SPICE engine. People
are surprised that I reveal all, but the trick is I tell what
one needs to do, not how to go about writing that code. There
is an arraingment with an officer of LTC that prevents loss
of any of the planet's intellectual property in the event of
my death so that how to implement this code is not lost when
I die. Anyway, in the seminar, I demonstrate the
fantastically improved accuracy of the core LTspice solvers
and the corresponding improvements in simulation speed with
live simulation runs. Anyway those with legitimate interest
in LTspice can contact your local LTC office and request
when/where the next seminars will be(please don't contact me,
I have people smarter than me that schedule them). The
seminars are worldwide.

--Mike

 

[Neil]

Well I'm not up to date with the current spice software, however I do
use the software I purchased from Beigebag Software and Intusoft
frequenctly. Another real disadvantage is that my Eng. comp doesn't
have a NIC, so I have no internet for this machine. It's strictly for
programming like C++, C and Basic, along with the Spice progarams I
mentioned.

I have to use another machine to access the net, but thanks for the
tip, I may try it.

Neil

 

[Neil]

Paul Rako wrote:
First, save any effort in contacting National.
We have better things to do then make SPICE models
for 30-year-old parts.

True, Paul I wouldn't mind having the spice model from national for
it,just the same. I very fond of the of 301,709, and others, and
because they were designed many years ago, anyone interested in op-amp
design, can learn alot from these two SUPER Op-Amps!!

I know I have............

I'm hoping maybe NATIONAL SEMICONDUCTOER will change it's mind one day
to bring out the model for the LM709
One fellow gave me a spice netlist for his model of the LM709, which
I'm going to try today.

Neil

 

[Neil]

Kevin Aylward wrote:
You are obviously a newbie on this...

Well, according to you, I'm not a expert on SPICE, never said I was,
but I think your missing the point of my POST Kev!! I'm not really
interested in Spice Programs per say, only the search for the model of
the 709 OP-Amp

cut and dry and that is it..............

How do you propose to design a 1000 transistor circuit?

Geez...... where did this come from? I'm only agreeing with bob's
quotes from his book. I'm a spice user myself. I wouldn't want to wager
on spice either, I'm almost confident that something will go wrong, if
I rely on it too much. Circuit temperature is one reason to use another
more practical approach, and this is not unrealistic, you can
understand what my reasons are for doing this. Even though this can be
done in spice, and It's a nice contribution and a big help, this where
I draw the line!! I have seen particular circuit behaviors, in which
spice is unable to predict very well. just my opinion.

A 10,000 transistor circuit?

Must be one hell of an OP-Amp!! huh?

Neil

 

[Kevin Aylward]

"Mike Engelhardt" <nospam@spam.org> wrote in message
news:tHhZe.2662$G64.165@newssvr12.news.prodigy.com...

Paul,

I do agree if there is no sanctioning body like IEEE or
W3C or anybody to validate the claim for an improved
engine, one has to be more critical. How can one judge
the advance of proprietary standards unless you guys
start opening up your code so the community can see the
difference in the source? Sorry if you feel I am posting
garbage, I am trying to be positive.

Well, I'm not trying to be negative you do post garbage.
You can't evaluate a simulator's performance by looking at
the source code and you should know better. I don't know
if you're deliberately dishonest or ignorant. LTspice is
close to a half million lines of code. You have to compile
it and test the program to see its performance. I'm guessing
your comment is more dishonest than ignorant because it

I think you may be a bit paranoid here. It seems pretty clear that that
Paul was simply mistaken. I don't see that most people lie in this way,
for the most part it is always a genuine mistaken belief.

But it's not very hard to understand why LTspice runs faster
and is more accurate then other/earlier SPICE engines. I
occasionally give 4hr seminars that explain in some detail
what one needs to do to make a better SPICE engine. People
are surprised that I reveal all, but the trick is I tell what
one needs to do, not how to go about writing that code.

Why not post/write some papers, e.g ieee.


Kevin Aylward
informationEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Kevin Aylward]

"Paul Rako" <sp_a_mpa_u_l@yahoo.com> wrote in message
news:%R8Ze.3707$Ba2.1132@newssvr27.news.prodigy.net...

analog:
Thank god, a scientist. Coherent, I suppose, with the IEEE mail
domain.
I will install LTspice/SwitcherCAD III and replicate some of my Orcad
misery.

Kevin:
I have to admit I am a long way from worrying if LTspice/SwitcherCAD
III
deals with HSPICE directives. But that did get me to check out your
website
and if that SPICE can inter-operate on... oh-- I don't know, EDIF 2 0
0
well that would be pretty cool since I could do work in it and then
stuff it
into Orcad or when I get creamed in Orcad I could jump into your
SPICE.

I am playing with the idea of EDIF.

At my current day job we use Tanner Tools, well for layout anyway. I
personally only use my SS. Tanner cant do any digital except by analogue
means, so it got me into thinking that there is a market for a cheap ic
mixed-mode spice if it can interface better with pro-tools like Cadence.

As a matter of fact I would pay the price if only so I did not have to
start Orcad in the evil "Mixed Signal" mode where the part properties
get
all goofy because PSPICE likes to call instantians "occurances"
instead of
"instances" like Orcad does. Back-annotate into that mess once and
you might understand why PSPICE is under-used. Arbitrary handles are
a wonderful thing, please tell Orcad.

I am refining bits an bobs that I use for ic design. I actually missed
direct GUI support for the URC transmission line, i.e. it had to be in a
..subckt to be used. I have now adding a proper dialog set-up for it, but
not yet posted the update. This is really useful to support resisters
with distributed capacitance to a node. This acts differently for the
conventional T lines (LTRA and T).


Kevin Aylward
informationEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Kevin Aylward]

"Mike Engelhardt" <nospam@spam.org> wrote in message
news:Z4gZe.1791$Ur.4@newssvr29.news.prodigy.net...

Kevin,

And I was once told that LTSPICE does not allow import
of models from other vendors like ADI and National.

More non-sense. Users can import models and since
LTspice knows most Pspice and hspice syntax,

It don't know HSpice's "hdif" which is used to automa-
tically calculate AD, AS, PS, and PD. These are
absolutely crucial for high speed work.

The lack of hdif is deliberate. LTspice insists that
every dimension, area, and perimeter be explicitly stated
for every transistor. It's done because layout
verification tools and simulators can get confused about
this so I require that the schematic tools compute and
this for each instance so that no other tools can get
confused. When one designs against one's own fab, and
one has a schematic capture tool that can do all that
for oneself(which LTspice's schematic capture will do
but it will remain an undocumented feature), one gets to
do that: Simply once and for all resolve all the
transistor dimensions.

This is quite a valid point. Its nice to have the actual data clearly on
the spice netline so one knows exactly what the simulator is seeing. SS
actually does this by the GUI. I only very recently added hdif to the
engine itself. It then actually introduced a minor bug that I have yet
not gotten around to fix. I have check boxes on the mos set-ups to
selectively enable Ad/As to account for butting devices. Now they don't
work as the get overridden in the engine...ahmmm...

But if the every dimension, area, and perimeter is
instanced out for each transistor, LTspice will run most
hspice models with binning, single quote parameter
substitution and usually inline comments starting the a
'$' when it doesn't conflict this PSpice syntax.

I did notice that it handled single quotes as an alternative to {}. I
had to disable this in SS recently as I had a clash with xspice model
data having single quotes for state machine file names. I need to fix
that as well...

Tell, you what though, its rather irritating that
LTSpice stops dead in its tracks when it gets a
.option it don't know.

Part of having a polyglot simulator is the need to be
more error verbose/intolerant of incorrect SPICE syntax.
Correct hspice syntax is .options numdgt=N If N is
greater than 6, the waveform data or compression
coefficients are stored as double precision, otherwise
LTspice uses single precision. See the help file
(F1 key)=>LTspice=>Dot Commands=>.OPTIONS=>numdgt.

Never noticed that. I'll see about changing SS then I would rather use a
standard syntax.


Hey, you also don't document that LTSpice supports

..dc temp 0 100 1

to sweep temperature.

It should be easy for you to add

..dc r1 10k 50k 1k

Saves me a bit more bother when I get a circuit XSpice don't converge
on.

Kevin Aylward
informationEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Paul Rako]

Well, there was one recommendation to you that you could just enter the schematic
from the data-sheet. I was told by several people that doing that would
be pretty fruitless. You don't have the process models and the schematic
leaves out sub-circuits that would affect the results. I know of no semiconductor
vendor that would publish a schematic detailed enough to let you simulate
it since that would allow others to reverse engineer the part.

Hang on, yeah, I just went to National's website. The LM709 is obsolete.
It is not being sold as of last month. It is a pretty hard sell to
management to put resources into a product they don't sell anymore.

Pease wanted to know what the heck you were designing with this old
part anyway. National's website says to substitute a LM101 or a LM108,
you can still get both in hermetic packages.

Paul

Neil wrote:

Paul Rako wrote:
First, save any effort in contacting National.
We have better things to do then make SPICE models
for 30-year-old parts.

True, Paul I wouldn't mind having the spice model from national for
it,just the same. I very fond of the of 301,709, and others, and
because they were designed many years ago, anyone interested in op-amp
design, can learn alot from these two SUPER Op-Amps!!

I know I have............

I'm hoping maybe NATIONAL SEMICONDUCTOER will change it's mind one day
to bring out the model for the LM709
One fellow gave me a spice netlist for his model of the LM709, which
I'm going to try today.

Neil

 

[Paul Rako]

Mike:
Well if you will have a garbage-posting dishonest creep
like me to your four-hour seminar I feel the least I can
do is attend. I'll talk to Gary Sapia in the local
sales office about the seminar. Thanks for the invite.
Look for the guy in the back row wearing a Nixon mask.

There are actually other people in the world competent
to evaluate well-written source code. I suspect several
read this group. And it is a well-accepted fact that
open-source projects always result in improved results.
I am not an open-source nut however. I will defend to the
death your right to maintain and sell proprietary code.

A half million lines of code. A half million lines of code.
Wow. And accepted software productivity is between 5 and
10 lines of debugged implemented code per day. 200 work days
in a year. So half a million line is what... 250 man-years
of code. Wow. I knew Swanson overworked his people and there
are all kinds of LT burnouts and walking-wounded here in the
valley but I had no idea how bad it was over there. My
software consultant buddies say that right around 600 or 700k
lines of code any program becomes un-maintainable so you still
have some room to grow if needed.

Lighten up Panama. And don't worry so much about protecting
your software and all the arcanities inside it. No one here
really cares about the indirect pointers to the linked lists
and malloc call recursive gobbledy gook. We just care if
it will give decent results on real-world circuits. Thanks
to two posters here in the group, (analog and Helmut),I think
we will soon know.

Mr. (Dr./Prof?) Thompson:
What do you use? I hope it is not some proprietary thing
like Analog Devices' internal SPICE. I hope you will serve as
judge jury and executioner in our little test. And remember
everyone-- in my opinion we are mis-applying SPICE. The
acronym stands for "Simulation Program with Integrated
Circuit Emphasis" It is not SPBLE. Spible would be
"Simulation Program with Board-Level Emphasis". This is
why there seems to be such passions aroused when us board
guys say we don't worship SPICE the way IC designers do.
BTW, Dave Tamura in the CAD department at National rolled his
eyes when I told him I said Process and Modeling departments
cost 5 or 10 million dollars a year for a big semiconductor
company. He hinted that tens times those numbers is not
unheard of. He also said that his CAD department is also
involved in making sure the models conform to reality.

Helmut:
I will take it upon myself to find the EDN article. Worse
comes to worse I will call Williams, he should remember it.
Then everybody can use it as a benchmark. I will also release
one of my schematics to the public domain to see how all these
packages do with it. I have to believe you guys when you say
LTspice is really good and fast. Like my brother says: "An
ounce of trial is worth a pound of opinion."

I just hope EDN didn't use an LM709 (;^o)-

And everybody: Watch the Tina-TI presentation on CMP's
EE Times webseminar to see how that SPICE did not predict
the real circuit results until they added caps to model board
strays. Of course they used a milled board and that is a
whole 'nuther thread.
It is archived and was shot on Sept 14th
http://cmpnetseminars.com/TSG/?K=On24&Q=265

And on a completely different subject:
Who wrote the Masstech layout program that Orcad bought and
incorporated into Orcad?

Paul


Mike Engelhardt wrote:

Paul,


I do agree if there is no sanctioning body like IEEE or
W3C or anybody to validate the claim for an improved
engine, one has to be more critical. How can one judge
the advance of proprietary standards unless you guys
start opening up your code so the community can see the
difference in the source? Sorry if you feel I am posting
garbage, I am trying to be positive.


Well, I'm not trying to be negative you do post garbage.
You can't evaluate a simulator's performance by looking at
the source code and you should know better. I don't know
if you're deliberately dishonest or ignorant. LTspice is
close to a half million lines of code. You have to compile
it and test the program to see its performance. I'm guessing
your comment is more dishonest than ignorant because it
appears to be an empty challenge to release the source code
of LTspice and trying to couple that challenge with a
challenge of proof of LTspice's performance, presumably
hoping one topic will drop with the other.

But it's not very hard to understand why LTspice runs faster
and is more accurate then other/earlier SPICE engines. I
occasionally give 4hr seminars that explain in some detail
what one needs to do to make a better SPICE engine. People
are surprised that I reveal all, but the trick is I tell what
one needs to do, not how to go about writing that code. There
is an arraingment with an officer of LTC that prevents loss
of any of the planet's intellectual property in the event of
my death so that how to implement this code is not lost when
I die. Anyway, in the seminar, I demonstrate the
fantastically improved accuracy of the core LTspice solvers
and the corresponding improvements in simulation speed with
live simulation runs. Anyway those with legitimate interest
in LTspice can contact your local LTC office and request
when/where the next seminars will be(please don't contact me,
I have people smarter than me that schedule them). The
seminars are worldwide.

--Mike

 

[Jim Thompson]

On Sun, 25 Sep 2005 10:17:33 GMT, Paul Rako <sp_a_mpa_u_l@yahoo.com>
wrote:

[snip]

Mr. (Dr./Prof?) Thompson:

"Mr.", I only have a MSEE.

What do you use? I hope it is not some proprietary thing
like Analog Devices' internal SPICE.

I use PSpice A/D v10.5, although I'm trying to make time to evaluate a
newcomer, TTSpiceWorks <http://www.trabucotechnologies.com/>. But it
seems, the older I get the busier I get ;-)

I hope you will serve as
judge jury and executioner in our little test.

What "little test" is it? I haven't been following this thread
closely.

And remember
everyone-- in my opinion we are mis-applying SPICE. The
acronym stands for "Simulation Program with Integrated
Circuit Emphasis" It is not SPBLE. Spible would be
"Simulation Program with Board-Level Emphasis".

Indeed.

This is
why there seems to be such passions aroused when us board
guys say we don't worship SPICE the way IC designers do.

In the IC world we "back-annotate" to add the strays that result from
layout. Do "board guys" have such a tool?

BTW, Dave Tamura in the CAD department at National rolled his
eyes when I told him I said Process and Modeling departments
cost 5 or 10 million dollars a year for a big semiconductor
company. He hinted that tens times those numbers is not
unheard of. He also said that his CAD department is also
involved in making sure the models conform to reality.

[snip]

And Win wonders why discrete MOSFET models are inadequate ;-)

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

 

[analog]

Helmut Sennewald wrote:

Paul Rako wrote:

The one complaint I heard tonight at Bldg T was that you can't
export the LTspice/SwitcherCAD III work to something that can
layout a circuit board. Based on the other buncombe, some of
which I may have inadvertently spouted, I will try it first and
see.

Usually a design's simulation is segmented by functionality rather
than by circuit board boundaries and includes many simulation
specific elements not needed or wanted on a layout oriented
schematic. On the other hand, a circuit board layout needs things
like connectors, test points, unused gates and gate associations,
mounting holes, etc. Also, component secondary parameters required
for a board layout are completely different than for a simulation.

I really don't see the point of wanting or requiring a simulation
schematic to be board layout capable.

circuit from the EDN article and see if will converge and
correlate to the results Jim Williams got [from actually
testing the circuit in the lab].

In my experience, most convergence stubborn simulations turn
out to be examples of garbage in, garbage out. I have *never*
come across a meaningful simulation that didn't converge or
couldn't be made to converge in short order (my efforts over
at the LTspice usersgroup on Yahoo Groups in soliciting such a
mythical beast have all come up empty handed).

I am very interested in the article mentioned by EDN.
Could you provide me a link to it or send it to me via email.

I turned over a lot of rocks online looking for this, but couldn't
find it. Maybe, as Paul mentioned in another post, he could go
ask Jim Williams for a copy or a link to a copy.

I will then try on this circuit with LTspice and give my
judgement. I think we should let the professionals do it who
know LTspice. It's like if you have to judge about a Porsche
car. If you have never driven it, you shouldn't judge it.

Helmut, what's a mild mannered family man like you doing driving a
Porsche!?? But your observation is well taken so I'll have to
disqualify myself from judging sports cars, at least.

Here are my "driving tips" for LTspice:

Because of the differing strategies used to handle them, convergence
issues are best sorted into those relating to finding the initial dc
operating point and those occurring during a transient run.

At the dc operating point and with ideal elements, inductors become
shorts and capacitors become opens, whereas just the opposite occurs
with step-size compression during transient troubles. In one case,
delta time goes to infinity, whereas in the other, it approaches
zero. For transient convergence, spice depends on the fact that
realistically modeled nonlinear elements should approach finite,
linear, time invariant impedances as step size gets really small.

LTspice has improved models for inductors and capacitors that allow
realistic parasitics to be entered and computed as an integral part
of the element. This prevents the corresponding branch admittances
from going to zero or infinity for reduced time steps during a
transient analysis, greatly improving run time convergence. Also,
as I understand it, inductances (and voltage source) with series
resistance are more computationally efficient, because they can
then be directly "plugged" into the admittance matrix. Another
benefit of specifying realistic parasitic resistances is that it
avoids situations where unrealistic high frequency oscillations
drive the time step to a crawl (not really a convergence issue).

Bearing this in mind, LTspice transient convergence "fixes"/
(standard good practice) in order of "goodness", im my opinion,
are:

1) Specify series and parallel resistance parameters for capacitors
and inductors.
2) Use the current source version of elements whenever possible.
Note that specifying a series resistance for voltage sources
actually changes them into current sources internally. For
example, rather than behavioral voltage sources, use current
sources in parallel with a small capacitor (1nF or less) edited
to have a 1 ohm shunt resistance.
3) Make sure that all semiconductor junctions (and other nonlinear
elements) are modeled with realistic series resistances and
junction capacitances as well. The importance and effect of
something seemingly so mundane as this cannot be overemphasized,
for this is what forces linear behavior during time step
compression.
4) Use LTspice's built-in alternate solver for three plus decades
more numerical dynamic range (at a 2x speed penalty).
5) Use the Gear integration method to numerically dampen out "noise"
that should better be taken care of by step 1).
6) Add .options Tseed=<maxtimestep>/10 (thanks Helmut)
7) Increase "reltol" above the default .001 (going higher than about
.03 may be counter productive).

Solving Operating Point Convergence Problems

In addition to most of the steps above:

Examine your simulation circuit for behavioral sources or other
devices that may go highly nonlinear as the sources are stepped up
from zero. Splitting a very nonlinear element into several pieces
across several nodes can sometimes dilute the problem behavior to
the point where the solver no longer gets hung up on one very bad
element. In such cases, adding more nodes can actually make the
simulation run much faster.

If not already available somewhere in the circuit, a unity node may
be created by setting up an isolated dc voltage source equal to one
volt. Clearly, any expression may be multiplied by the voltage on
this node as many times as needed without changing the value of the
expression during an analysis. The only effect on such an expres-
sion occurs during source stepping while seeking the operating
point. Then, as this unity node is reduced to near zero, anything
multiplied by it is also forced to approach zero.

Bear in mind that unity node multiplication can be sprinkled
throughout a simulation wherever you suspect misbehavior.
Differencing circuits with a lot of dc and gain are always good
candidates as are abrupt limiters and behavioral expressions with
node voltages in their denominators such that when the sources go
to zero, the expressions blow up (something gone small / something
gone to zero => infinity). These types of expressions can be
multiplied by the unity node raised to whatever power required to
make them behave.

Regards -- analog

 

[Helmut Sennewald]

"analog" <analog@ieee.org> schrieb im Newsbeitrag
news:4336F7DD.A26C9ADC@ieee.org...

Helmut Sennewald wrote:
Paul Rako wrote:

The one complaint I heard tonight at Bldg T was that you can't
export the LTspice/SwitcherCAD III work to something that can
layout a circuit board. Based on the other buncombe, some of
which I may have inadvertently spouted, I will try it first and
see.

Usually a design's simulation is segmented by functionality rather
than by circuit board boundaries and includes many simulation
specific elements not needed or wanted on a layout oriented
schematic. On the other hand, a circuit board layout needs things
like connectors, test points, unused gates and gate associations,
mounting holes, etc. Also, component secondary parameters required
for a board layout are completely different than for a simulation.

I really don't see the point of wanting or requiring a simulation
schematic to be board layout capable.

Hello analog,

I can really second that. The more professional layout programs
allow a lot of control from the schematic. There are so many
properties on nets and components which you never get from another
schematic entry program. And finally postprocessing beyond layout
may be completely impossible without some special properties.

Btw, PSPICE has become harder to use since Cadence switched
to the ORCAD schematic interface which is intended for PCB designs.
This is ok for PCBs but you will need more time to make a
schematic for SPICE.

...

I will then try on this circuit with LTspice and give my
judgement. I think we should let the professionals do it who
know LTspice. It's like if you have to judge about a Porsche
car. If you have never driven it, you shouldn't judge it.

Helmut, what's a mild mannered family man like you doing driving a
Porsche!?? But your observation is well taken so I'll have to
disqualify myself from judging sports cars, at least.

I have no Porsche, but when I think on LTspice I always think
LTSpice is the Porsche of the SPICE simulators.
It's very fast and precisely to control.
It requires a little bit practice and learning of course to
get this advantage.

I had posted a few days ago my tips about solving convergence
problems into the LTspice-Yahoo-group.

--- start
It's difficult to give a general help. I would try with the
following.

1. Set a useful maximum time step in the ".tran" line.
Try with some values.
Use/keep a maximum timestep regardless whether it still fails.

Most of the following settings are in the Control Panel.

Control Panel -> SPICE

If still not ok:
2. Try wth the Alternate solver

If srill not ok:
3. Back to Normal solver
Try with method: Gear

If still not ok:
4. Back to default settings.
Try with "startup" in the .TRAN setting .

If still not ok:
5. Back to default settings.
Try with Gmin, but not lower than 1e-10

Still not ok:
6. Back to default settings.
Try with Reltol=0.01

Still not ok:
7. Back to default settings.
Try with a combination of 6 and 7

Still not ok:
8. Back to default settings.
Try with .options Tseed=maxtimestep/10

Still not ok:
9. Have the components real values? Add a series resistor in the
capacitor(ESR) or inductor.

Still not ok:
10. Try with .ic and .nodeset

Still not ok:
11. Let try other people.

Don't under estimate hint 11.
--- end

"analog", I will add your tips to the FAQ in the LTspice-Yahoo group.

Best regards,
Helmut

Here are my "driving tips" for LTspice:

Because of the differing strategies used to handle them, convergence
issues are best sorted into those relating to finding the initial dc
operating point and those occurring during a transient run.

At the dc operating point and with ideal elements, inductors become
shorts and capacitors become opens, whereas just the opposite occurs
with step-size compression during transient troubles. In one case,
delta time goes to infinity, whereas in the other, it approaches
zero. For transient convergence, spice depends on the fact that
realistically modeled nonlinear elements should approach finite,
linear, time invariant impedances as step size gets really small.

LTspice has improved models for inductors and capacitors that allow
realistic parasitics to be entered and computed as an integral part
of the element. This prevents the corresponding branch admittances
from going to zero or infinity for reduced time steps during a
transient analysis, greatly improving run time convergence. Also,
as I understand it, inductances (and voltage source) with series
resistance are more computationally efficient, because they can
then be directly "plugged" into the admittance matrix. Another
benefit of specifying realistic parasitic resistances is that it
avoids situations where unrealistic high frequency oscillations
drive the time step to a crawl (not really a convergence issue).

Bearing this in mind, LTspice transient convergence "fixes"/
(standard good practice) in order of "goodness", im my opinion,
are:

1) Specify series and parallel resistance parameters for capacitors
and inductors.
2) Use the current source version of elements whenever possible.
Note that specifying a series resistance for voltage sources
actually changes them into current sources internally. For
example, rather than behavioral voltage sources, use current
sources in parallel with a small capacitor (1nF or less) edited
to have a 1 ohm shunt resistance.
3) Make sure that all semiconductor junctions (and other nonlinear
elements) are modeled with realistic series resistances and
junction capacitances as well. The importance and effect of
something seemingly so mundane as this cannot be overemphasized,
for this is what forces linear behavior during time step
compression.
4) Use LTspice's built-in alternate solver for three plus decades
more numerical dynamic range (at a 2x speed penalty).
5) Use the Gear integration method to numerically dampen out "noise"
that should better be taken care of by step 1).
6) Add .options Tseed=<maxtimestep>/10 (thanks Helmut)
7) Increase "reltol" above the default .001 (going higher than about
.03 may be counter productive).

Solving Operating Point Convergence Problems

In addition to most of the steps above:

Examine your simulation circuit for behavioral sources or other
devices that may go highly nonlinear as the sources are stepped up
from zero. Splitting a very nonlinear element into several pieces
across several nodes can sometimes dilute the problem behavior to
the point where the solver no longer gets hung up on one very bad
element. In such cases, adding more nodes can actually make the
simulation run much faster.

If not already available somewhere in the circuit, a unity node may
be created by setting up an isolated dc voltage source equal to one
volt. Clearly, any expression may be multiplied by the voltage on
this node as many times as needed without changing the value of the
expression during an analysis. The only effect on such an expres-
sion occurs during source stepping while seeking the operating
point. Then, as this unity node is reduced to near zero, anything
multiplied by it is also forced to approach zero.

Bear in mind that unity node multiplication can be sprinkled
throughout a simulation wherever you suspect misbehavior.
Differencing circuits with a lot of dc and gain are always good
candidates as are abrupt limiters and behavioral expressions with
node voltages in their denominators such that when the sources go
to zero, the expressions blow up (something gone small / something
gone to zero => infinity). These types of expressions can be
multiplied by the unity node raised to whatever power required to
make them behave.

Regards -- analog