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

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

Hmmmmm,

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

Hmmmmm,

DNA

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

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" schrieb im Newsbeitrag news:%R8Ze.3707$ snipped-for-privacy@newssvr27.news.prodigy.net...

misery.

lay-out a

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.

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

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

They have a demo version, free, which has these files. Try . I haven't been there for quite a while, so this may have changed.

Regards, BruceR

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,

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.

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

I wrote,

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

Paul,

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

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.

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

Kevin Aylward snipped-for-privacy@anasoft.co.uk

SuperSpice, a very affordable Mixed-Mode Windows Simulator with Schematic Capture, Waveform Display, FFT's and Filter Design.

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.

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 snipped-for-privacy@anasoft.co.uk

SuperSpice, a very affordable Mixed-Mode Windows Simulator with Schematic Capture, Waveform Display, FFT's and Filter Design.

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

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

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 snipped-for-privacy@anasoft.co.uk

SuperSpice, a very affordable Mixed-Mode Windows Simulator with Schematic Capture, Waveform Display, FFT's and Filter Design.

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:

[snip]

"Mr.", I only have a MSEE.

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

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

Indeed.

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

[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            Voice:(480)460-2350  |             |
|  E-mail Address at Website     Fax:(480)460-2142  |  Brass Rat  |
|       http://www.analog-innovations.com           |    1962     |
             
I love to cook with wine.      Sometimes I even put it in the food.

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

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

Paul

Mike Engelhardt wrote:

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.

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

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=/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

[snip] [snip]

I don't understand your comment. As much as I despise Capture, as the worst GUI creation ever known to man, it does interface to PSpice just fine.

...Jim Thompson

--
|  James E.Thompson, P.E.                           |    mens     |
|  Analog Innovations, Inc.                         |     et      |
|  Analog/Mixed-Signal ASIC\'s and Discrete Systems  |    manus    |
|  Phoenix, Arizona            Voice:(480)460-2350  |             |
|  E-mail Address at Website     Fax:(480)460-2142  |  Brass Rat  |
|       http://www.analog-innovations.com           |    1962     |
             
I love to cook with wine.      Sometimes I even put it in the food.