开云体育

--- polapart <sahawley@...> wrote:

I am trying to run a Burr Brown Op Amp, the OPA336.
The transient analysis "sort of" runs but LTSpice
notes a couple of problems, most notably
unrecognized parameters, jssw and vfb.

I couldn't find this model. Can you send it to me.

--Mike


__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!

Jon,

I'm interested in calculating iterative values for
resistors[...]

The .asc file below might get you started there.

--Mike

Version 4
SHEET 1 892 900
WIRE 320 576 320 528
WIRE 320 448 320 400
WIRE 320 304 320 240
WIRE 320 240 128 240
WIRE 128 240 128 256
WIRE 128 336 128 352
WIRE 128 560 128 576
WIRE 128 464 128 480
WIRE 256 352 128 352
WIRE 128 352 128 368
WIRE 64 416 -304 416
WIRE -304 416 -304 448
WIRE -304 528 -304 560
WIRE 464 384 464 352
WIRE 464 272 464 240
WIRE 464 240 320 240
FLAG 128 576 0
FLAG 320 576 0
FLAG -304 560 0
FLAG 464 384 0
SYMBOL npn 64 368 R0
SYMATTR InstName Q1
SYMATTR Value 2N3904
SYMBOL pnp 256 400 M180
WINDOW 0 74 72 Left 0
WINDOW 3 76 34 Left 0
SYMATTR InstName Q2
SYMATTR Value 2N3906
SYMBOL res 112 240 R0
SYMATTR InstName R1
SYMATTR Value {R1}
SYMBOL res 112 464 R0
SYMATTR InstName R2
SYMATTR Value {R2}
SYMBOL voltage -304 432 R0
SYMATTR InstName V1
SYMATTR Value pulse(0 {Vdd} 0 10u 10u .5m 1m)
SYMBOL voltage 464 256 R0
SYMATTR InstName V2
SYMATTR Value {Vcc}
SYMBOL res 304 432 R0
SYMATTR InstName R3
SYMATTR Value {Rload}
TEXT -288 672 Left 0 !.param load=10m R2=500 Vdd=2
Vbe=.7
TEXT -288 736 Left 0 !.param R1=(Vdd -
Vbe)/(load/10+Vbe/R2+Ib)
TEXT -266 604 Left 0 !.tran 3m
TEXT -288 704 Left 0 !.param Ib=10u Rload = Vcc/load
Vcc=5


__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!

I am trying to run a Burr Brown Op Amp, the OPA336. The transient
analysis "sort of" runs but LTSpice notes a couple of problems, most
notably unrecognized parameters, jssw and vfb.

The AC analysis fails to converge. The comments in the deck offer
some advice with regard to modifyng ITL and gmin via .OPTION which
doesn't seem to help. Are these more PSPICE problems?

Thanks

I'm interested in calculating iterative values for resistors.
For example, an emitter resistor's value may be based on the
emitter voltage divided by some current I need to have.
However, the emitter voltage is, of course, dependent on the
emitter/collector current which will depend on the emitter
resistor value. An iterative process could track down this
value closely, but I don't know how to write the expression.

Here's an example of what I mean:

Vcc
|
,------x
| |
&#92; |
/ R2 |
&#92; |
| |
| |/e Q2
x----| PNP
| |&#92;c
| |
| '-----> to the load
|/c Q1
>-----| NPN
control |&#92;e
signal |
at Vdd |
or 0V, &#92;
not at / R1
Vcc &#92;
|
|
gnd

In this case, R1 needs to be:

R1 = (Vdd - Vbe(Q1))/(I(load)/10+Vbe(Q2)/R2+Ib(Q1))

I want to set up I(load) to some value and have R1 computed from
that.

When I type V(N001,N003) as part of the expression, in order to
get the Vbe(Q1) for example, it's rejected with "Unable to find
definition of model v - default assumed." This isn't what I
want, naturally.

Is there any way to set up the expression for R1, appropriately?

Jon

On Tue, 18 Mar 2003 09:16:19 -0800 (PST), you wrote:

Jon,

...But is it possible to extend the dialog box
list for the NPN transistors, for example, so
that I can simply select from the list rather
than overriding the "Value" on the schematic,
directly?
...
And if there is a way, can it be secure
against the automatic update process, so that
I keep my additions in the face of regular
updates?

The selection dialogs for bipolars, jfets, diodes,
and mosfets use the .model entries in the files
./lib/cmp/standard{.bjt,.jft,.dio,.mos} You can
edit these with a text editor(or LTspice) to add
new components. If you update with the menu item
Tools=>Sync Release, your versions of these files
should be merged with the new ones so you don't loose
your models.

Wonderful! That works better than I'd hoped. Glad you added
the extra code to make that happen during updating.

However, if LT now supplies a model
with the same name as one you've added, you will
loose your version of the model and it will be
replaced with the version from LT.

Okay. So this is a good reason why you might want to keep the
count of your models low -- less likely to kill someone's
personal models that they've added. In particular, I picked up
my own copy of the 2N3391A, for example, which is also in your
standard distribution. So if I placed it there in STANDARD.BJT,
it would be replaced during updating. Luckily, your version is
identical.

I also noticed that if I have a version of 2N3391A in my own
"BJT.LIB," for example, and your STANDARD.BJT also has that
model, as well, then your dialog's list does *not* include the
2N3391A in it, at all. It recognizes that there is a definition
in my own .LIB, so it removes it from its own list. Too bad it
doesn't just give priority to my definitions and compile a
composite list from both the STANDARD.BJT as well as my BJT.LIB,
for example. Then I wouldn't need to modify STANDARD.BJT, at
all.

That's because
the merge routine isn't smart enough to know which
one's you added and which ones are just old versions
from LT.

Makes sense to me. It would be tough to solve, generally. (I
suppose you could add a special parameter which only you'd use
in your models.)

That being said, I would like to recommend that you
keep a version of your own edited standard.* files
for safety.

Will do.

Note that if you don't use the Tools=>sync Release
feature but reinstall, then the standard.* files
will simply be replaced with those in the current
distribution.

Understood.

Or if I should decide to forget about the
standard components included with LT Spice
and start building my own large library
of parts with trusted parameters, can I get
them to be popped into these selection lists?

You'd have to maintain your own versions of
the standard.* files and copy them over into
the ./lib/cmp directory after every update.

Okay.

While I'm at it, it might be nice, someday, if you'd support
user designed .ASY's placed in lib&#92;sym which could have lists of
.SUBCKT attached to them which would be automatically supported
as a selection list for that .ASY. So that I could develop a
small list, for example, for the 2N6027 and 2N6028 or for other
custom X-type circuits I might develop.

(It's still incredible to me that I'm actually using and
learning from a simulator which doesn't eat up my system memory
or crash under WIN98 or otherwise complicate my life. So I'm
glad for everything I'm already using.)

BTW, only .model statements can be put in the
standard.* files. Subcircuits can't be parsed
there.

Thanks! I wouldn't have guessed about that limitation. I'll be
careful, then. (Chances are, and I'm guessing here, that this
probably means that allowing user-created X-type list generation
would be "difficult" under the current architecture. Oh, well.)

Thanks again for the active support. I'm already feeling
guilty.

Jon

Jon,

...But is it possible to extend the dialog box
list for the NPN transistors, for example, so
that I can simply select from the list rather
than overriding the "Value" on the schematic,
directly?
...
And if there is a way, can it be secure
against the automatic update process, so that
I keep my additions in the face of regular
updates?

The selection dialogs for bipolars, jfets, diodes,
and mosfets use the .model entries in the files
./lib/cmp/standard{.bjt,.jft,.dio,.mos} You can
edit these with a text editor(or LTspice) to add
new components. If you update with the menu item
Tools=>Sync Release, your versions of these files
should be merged with the new ones so you don't loose
your models. However, if LT now supplies a model
with the same name as one you've added, you will
loose your version of the model and it will be
replaced with the version from LT. That's because
the merge routine isn't smart enough to know which
one's you added and which ones are just old versions
from LT.

That being said, I would like to recommend that you
keep a version of your own edited standard.* files
for safety.

Note that if you don't use the Tools=>sync Release
feature but reinstall, then the standard.* files
will simply be replaced with those in the current
distribution.

Or if I should decide to forget about the
standard components included with LT Spice
and start building my own large library
of parts with trusted parameters, can I get
them to be popped into these selection lists?

You'd have to maintain your own versions of
the standard.* files and copy them over into
the ./lib/cmp directory after every update.

BTW, only .model statements can be put in the
standard.* files. Subcircuits can't be parsed
there.

--Mike

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!

--- In LTspice@..., Panama Mike <panamatex@y...> wrote:

John,

I was really puzzled by the complicated G-
source _expression. That all makes sense now.

Yeah. I just put up a version, 2.00l. It lets you
duplicate the leakage of PSpice current sources in
LTspice. Go to Tools=>Control Panel=>SPICE and
check "Add GMIN across current sources" Then you
will see the input bias drop to zero on the -E
models.

There's still a couple differences between PSpice
and LTspice even after checking the box. PSpice
does not report the current's gmin leakage current,
which is just a dumb mistake that I don't
duplicate. Also, in PSpice the current sources
don't leak in the .ac analysis, just .op and .tran.
Which is a complete inconsistency and just another
error I didn't duplicate in LTspice.

There's one other thing to keep in mind when
working with high impedance circuits. You might
want to tighten abstol. That controls the
absolute(vs. relative) acceptable current
error. It defaults to 1pA.

--Mike

_

Mike,

I downloaded the new release this morning and simulated my circuit
again. Sure enough, the input bias current is now reasonable and the
simulation behaves like the actual circuit. Thanks for looking into
this and getting a fix up so quickly.

- John


_________________________________________________

Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your

desktop!

I know that I can create my own library files and use .include
to specify them. But is it possible to extend the dialog box
list for the NPN transistors, for example, so that I can simply
select from the list rather than overriding the "Value" on the
schematic, directly? It's nice to look over the parameter list,
sometimes, to look for the best of some particular parameter,
without having to print out my library file.

And if there is a way, can it be secure against the automatic
update process, so that I keep my additions in the face of
regular updates?

Or if I should decide to forget about the standard components
included with LT Spice and start building my own large library
of parts with trusted parameters, can I get them to be popped
into these selection lists?

Jon

John,

I was really puzzled by the complicated G-
source _expression. That all makes sense now.

Yeah. I just put up a version, 2.00l. It lets you
duplicate the leakage of PSpice current sources in
LTspice. Go to Tools=>Control Panel=>SPICE and
check "Add GMIN across current sources" Then you
will see the input bias drop to zero on the -E
models.

There's still a couple differences between PSpice
and LTspice even after checking the box. PSpice
does not report the current's gmin leakage current,
which is just a dumb mistake that I don't
duplicate. Also, in PSpice the current sources
don't leak in the .ac analysis, just .op and .tran.
Which is a complete inconsistency and just another
error I didn't duplicate in LTspice.

There's one other thing to keep in mind when
working with high impedance circuits. You might
want to tighten abstol. That controls the
absolute(vs. relative) acceptable current
error. It defaults to 1pA.

--Mike

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!

--- In LTspice@..., Panama Mike <panamatex@y...> wrote:

John,

Are there any special considerations with using
P-spice op-amp macro models with LTspice? I'm
trying to simulate a circuit that uses a Burr
Brown/TI electrometer op-amp (OPA128 or OPA129)
and I'm getting incorrect results...

As has been pointed out, the non-E version of
the models do leak much more than the product.
That's the model. The E versions are supposed
model input bias current and it still leaked
too much in LTspice.

I just found out why the E models have large
bias currents in LTspice. It turns out that
all current sources in PSpice are shorted out
with a very small conductivity equal to GMIN
which defaults to 1e-12.

All versions of the models have use JFETs for
the input stage. The JFET supplies GMIN
conductivity between gate-source and gate-
drain. With +/-15V supply voltage this leads
to an input bias current of 15pA. In LTspice
you can set GMIN to zero, so you an turn off
this leakage. But PSpice can't converge with
GMIN=0.

So the -E versions of the models add a current
source to cancel the JFET leakage. So far
so good. Unfortunately, all current sources
in PSpice also supply their own additional GMIN
of conductivity. That is, PSpice shorts out
all current sources with a resistivity of 1e12
Ohms. There's no reason for this, it's just
bad SPICE design as far as I can tell. So the
additional current source to cancel the JFET
leakage has to cancel it's own leakage, too.
That's what makes the expression of the G-
sources so complicated. Also, when you run
the -E version in LTspice, the bias current
doesn't go to zero where if you run it in
PSpice, it will. I will probably and an
option in the control panel of LTspice to
duplicate this leakage as an option in the
near future.

Thanks to Helmut for help in isolating the
problem.

Below is a deck that shows the PSpice vs LTspice
leakage of currents. In LTspice you will get
the correct answer, but in PSpice, you will
get an error because the current sources don't
have infinite impedance.

--Mike

*
* V(y) should be 100KV
R1 Y 0 1e11
G1 0 Y N001 0 1
Vin3 N001 0 1u

* V(x) should be -100KV
R2 X 0 1e11
G2 X 0 value = { 1u }

* V(z) should be -100KV
I1 Z 0 1u
R3 Z 0 1e11
.tran 1m 1
.options gmin=1e-10
.probe
.end

Mike,

I was really puzzled by the complicated G-source expression. That
all makes sense now.

Thanks,
John

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online

Brain,

On one hand, I'm frustrated to learn there are so many issues with
vendor supplied models. This sort of problem can send you down a rat
hole for quite some time, and leave you worrying about the soundness
of your design. On the other hand, I know that I'm going to only use
simulation to validate my initial design and analysis, and not use it
as a substitute for other analytical methods. This experience only
supports my convictions and helps keep me honest.

The golden rule in analogue design is that n simulators give n different
answers, you have to be able to hand-verify results to some extent.

I tell the engineers here, half-jokingly that simulation tools and models are
for amusement only since both the tool and device vendors don't guarantee the
accuracy of anything.

Brian

--
Brian Howie | Tel: 0131 343 5590
BAE SYSTEMS | Fax: 0131 343 5050
Sensor Systems Division | Email brian.howie@...
Silverknowes | bhowie@...
Edinburgh EH4 4AD | Web site www.baesystems.com


***
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
***

John,

Are there any special considerations with using
P-spice op-amp macro models with LTspice? I'm
trying to simulate a circuit that uses a Burr
Brown/TI electrometer op-amp (OPA128 or OPA129)
and I'm getting incorrect results...

As has been pointed out, the non-E version of
the models do leak much more than the product.
That's the model. The E versions are supposed
model input bias current and it still leaked
too much in LTspice.

I just found out why the E models have large
bias currents in LTspice. It turns out that
all current sources in PSpice are shorted out
with a very small conductivity equal to GMIN
which defaults to 1e-12.

All versions of the models have use JFETs for
the input stage. The JFET supplies GMIN
conductivity between gate-source and gate-
drain. With +/-15V supply voltage this leads
to an input bias current of 15pA. In LTspice
you can set GMIN to zero, so you an turn off
this leakage. But PSpice can't converge with
GMIN=0.

So the -E versions of the models add a current
source to cancel the JFET leakage. So far
so good. Unfortunately, all current sources
in PSpice also supply their own additional GMIN
of conductivity. That is, PSpice shorts out
all current sources with a resistivity of 1e12
Ohms. There's no reason for this, it's just
bad SPICE design as far as I can tell. So the
additional current source to cancel the JFET
leakage has to cancel it's own leakage, too.
That's what makes the expression of the G-
sources so complicated. Also, when you run
the -E version in LTspice, the bias current
doesn't go to zero where if you run it in
PSpice, it will. I will probably and an
option in the control panel of LTspice to
duplicate this leakage as an option in the
near future.

Thanks to Helmut for help in isolating the
problem.

Below is a deck that shows the PSpice vs LTspice
leakage of currents. In LTspice you will get
the correct answer, but in PSpice, you will
get an error because the current sources don't
have infinite impedance.

--Mike

*
* V(y) should be 100KV
R1 Y 0 1e11
G1 0 Y N001 0 1
Vin3 N001 0 1u

* V(x) should be -100KV
R2 X 0 1e11
G2 X 0 value = { 1u }

* V(z) should be -100KV
I1 Z 0 1u
R3 Z 0 1e11
.tran 1m 1
.options gmin=1e-10
.probe
.end


__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online

--- In LTspice@..., brian.howie@b... wrote:

Are there any special considerations with using P-spice op-amp

macro

models with LTspice? I'm trying to simulate a circuit that uses a
Burr Brown/TI electrometer op-amp (OPA128 or OPA129) and I'm

getting

incorrect results. I downloaded the models from TI's website.

The

circuit's been built and thoroughly debugged, so I'm confident in

the

design.

When I couldn't get the circuit to operate correctly, I entered a
simple test circuit to verify some of the basic op-amp
characteristics. I found that the input bias current was way to

high

(about 12nA instead of 100fA), and the gain-bandwidth of the

OPA129

was high by about a factor of 10. I suspect that the models are

just

screwed up, but since I'm new to LTspice I'm not completely

confident

with my conclusion. Any help would be greatly appreciated.

I get similar problems with the OP27A, although in my case it is

the noise that

is reported about 2 orders more than the data sheet and hand

calculations

suggest. The bias currents look right. Other vendors opamps seem to

behave.

I ran a test circuit on Accusim II (Eldo SPICE-like kernal) and

the OP27A gave

sensible answers. I ported the netlist back to LTSPICE and although

the AC

analysis ran, the noise analysis gave up . I put the Accusim OP27A

model into

LTSPICE library and it gave the same wrong noise on my test

circuit.

Brian



--
Brian Howie | Tel: 0131 343 5590
BAE SYSTEMS | Fax: 0131 343 5050
Sensor Systems Division | Email brian.howie@b...
Silverknowes | bhowie@i...
Edinburgh EH4 4AD | Web site www.baesystems.com


***
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
***

Brain,

On one hand, I'm frustrated to learn there are so many issues with
vendor supplied models. This sort of problem can send you down a rat
hole for quite some time, and leave you worrying about the soundness
of your design. On the other hand, I know that I'm going to only use
simulation to validate my initial design and analysis, and not use it
as a substitute for other analytical methods. This experience only
supports my convictions and helps keep me honest.

- John

--- In LTspice@..., "Helmut Sennewald"
<helmutsennewald@y...> wrote:

--- In LTspice@..., "john_oztek" <joconnor@o...> wrote:

--- In LTspice@..., "Helmut Sennewald"
<helmutsennewald@y...> wrote:

--- In LTspice@..., "john_oztek" <joconnor@o...>

wrote:

Are there any special considerations with using P-spice op-

amp

macro

models with LTspice? I'm trying to simulate a circuit that

uses

a

Burr Brown/TI electrometer op-amp (OPA128 or OPA129) and I'm

getting

incorrect results. I downloaded the models from TI's

website.

The

circuit's been built and thoroughly debugged, so I'm

confident

in

the

design.

When I couldn't get the circuit to operate correctly, I

entered

a

simple test circuit to verify some of the basic op-amp
characteristics. I found that the input bias current was way

to

high

(about 12nA instead of 100fA), and the gain-bandwidth of the

OPA129

was high by about a factor of 10. I suspect that the models

are

just

screwed up, but since I'm new to LTspice I'm not completely

confident

with my conclusion. Any help would be greatly appreciated.

Hello John,
I tried to verify your results and the bias currents are indeed

a

lot

higher than expected. I looked around in the LTSPICE settings

for

possible leakage currents and other precision important

parameters.

Finally I have found that we need the command line

.OPTIONS gmin=0 (or at least <1e-18)

It defines the minimum conductance added to every node.
The simulated input bias current is then 40pA for the OPA128

and

OPA129.
The AC-gain results are really by a factor of ten too high for

the

OPA129/OPA129E.

I still don't know why the enhanced models OPA128E and OPA129E

still

shows bias currents of about 30pA instead of 40fA.
I tried the OPA129E with the PSPICE 8.0 demo.
Surprise, surprise! Even with the OPA129E, the bias current has

been

40fA. Something seems to go wrong in LTSPICE with this enhanced

model

in the .OP calculation.

The .AC simulation shows exactly the same results in PSPICE as

in

LTSPICE.

Best Regards
Helmut

Helmut,

Thanks for looking into this and going to the trouble of

duplicating

my results. I've also had problems with the enhanced model for

the

INA128 instrumentation amplifier. The standard model seems to

work

OK although it does have a little trouble converging. One thing

for

sure, it's definitely worth the effort of proving the model in a
simple circuit against data sheet specs, particularly when second
order effects are critical.

Hello John,
I have to take back my statement that LTSPICE was wrong with the
OPA129E input bias current. I further investigated the enhanced(E)
model and it is obvious that it isn't modelled correctly for bias
current. Now it seems the PSPICE simulation has been wrong with the
OPA129E.

These are the two critical lines of the enhanced model.

g11 2 4 poly(4) (10,2) (11,2) (4,2) (66,0) 0 1E-12 1E-12 1E-12
100E-9

g21 1 4 poly(4) (10,1) (12,1) (4,1) (68,0) 0 1E-12 1E-12 1E-12
100E-9

Node 1 and 2 are the input pins. g11 and g21 should simulate input
currents proportional to the negative supply voltage(4), the common
source point(10) the drain(11 close to V-) and node 66 which is

close

to (0). Assuming 15V for the negative supply gives bias currents of
15V*1e-12 = 15pA.

Finally I am wondering how PSPICE can calculate 40fA bias current.

Best Regards
Helmut

Helmut,

Thanks again for looking so thoroughly into this. I'm surprised that
they use such a complicated expression for bias current, unless the
terms help implement the bias current temperature coefficient.
According to the data sheet, the bias current is relatively constant
over a wide range of common mode voltage, implying that the
difference between the inputs and the negative supply should have
little effect on this parameter. Like any JFET op-amp, bias current
increases exponentially with temperature, so temperature is by far
the dominant variable. I do find it surprising that such a critical
characteristic would be modeled incorrectly, as there is no reason to
use this op-amp other than for it's extremely low bias current.

Thanks,
John

Are there any special considerations with using P-spice op-amp macro
models with LTspice? I'm trying to simulate a circuit that uses a
Burr Brown/TI electrometer op-amp (OPA128 or OPA129) and I'm getting
incorrect results. I downloaded the models from TI's website. The
circuit's been built and thoroughly debugged, so I'm confident in the
design.

When I couldn't get the circuit to operate correctly, I entered a
simple test circuit to verify some of the basic op-amp
characteristics. I found that the input bias current was way to high
(about 12nA instead of 100fA), and the gain-bandwidth of the OPA129
was high by about a factor of 10. I suspect that the models are just
screwed up, but since I'm new to LTspice I'm not completely confident
with my conclusion. Any help would be greatly appreciated.

I get similar problems with the OP27A, although in my case it is the noise that
is reported about 2 orders more than the data sheet and hand calculations
suggest. The bias currents look right. Other vendors opamps seem to behave.

I ran a test circuit on Accusim II (Eldo SPICE-like kernal) and the OP27A gave
sensible answers. I ported the netlist back to LTSPICE and although the AC
analysis ran, the noise analysis gave up . I put the Accusim OP27A model into
LTSPICE library and it gave the same wrong noise on my test circuit.

Brian



--
Brian Howie | Tel: 0131 343 5590
BAE SYSTEMS | Fax: 0131 343 5050
Sensor Systems Division | Email brian.howie@...
Silverknowes | bhowie@...
Edinburgh EH4 4AD | Web site www.baesystems.com


***
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
***

--- In LTspice@..., "john_oztek" <joconnor@o...> wrote:

--- In LTspice@..., "Helmut Sennewald"
<helmutsennewald@y...> wrote:

--- In LTspice@..., "john_oztek" <joconnor@o...>

wrote:

Are there any special considerations with using P-spice op-amp

macro

models with LTspice? I'm trying to simulate a circuit that

uses

a

Burr Brown/TI electrometer op-amp (OPA128 or OPA129) and I'm

getting

incorrect results. I downloaded the models from TI's

website.

The

circuit's been built and thoroughly debugged, so I'm confident

in

the

design.

When I couldn't get the circuit to operate correctly, I entered

a

simple test circuit to verify some of the basic op-amp
characteristics. I found that the input bias current was way

to

high

(about 12nA instead of 100fA), and the gain-bandwidth of the

OPA129

was high by about a factor of 10. I suspect that the models

are

just

screwed up, but since I'm new to LTspice I'm not completely

confident

with my conclusion. Any help would be greatly appreciated.

Hello John,
I tried to verify your results and the bias currents are indeed a

lot

higher than expected. I looked around in the LTSPICE settings for
possible leakage currents and other precision important

parameters.

Finally I have found that we need the command line

.OPTIONS gmin=0 (or at least <1e-18)

It defines the minimum conductance added to every node.
The simulated input bias current is then 40pA for the OPA128 and
OPA129.
The AC-gain results are really by a factor of ten too high for

the

OPA129/OPA129E.

I still don't know why the enhanced models OPA128E and OPA129E

still

shows bias currents of about 30pA instead of 40fA.
I tried the OPA129E with the PSPICE 8.0 demo.
Surprise, surprise! Even with the OPA129E, the bias current has

been

40fA. Something seems to go wrong in LTSPICE with this enhanced

model

in the .OP calculation.

The .AC simulation shows exactly the same results in PSPICE as in
LTSPICE.

Best Regards
Helmut

Helmut,

Thanks for looking into this and going to the trouble of

duplicating

my results. I've also had problems with the enhanced model for the
INA128 instrumentation amplifier. The standard model seems to work
OK although it does have a little trouble converging. One thing

for

sure, it's definitely worth the effort of proving the model in a
simple circuit against data sheet specs, particularly when second
order effects are critical.

Hello John,
I have to take back my statement that LTSPICE was wrong with the
OPA129E input bias current. I further investigated the enhanced(E)
model and it is obvious that it isn't modelled correctly for bias
current. Now it seems the PSPICE simulation has been wrong with the
OPA129E.

These are the two critical lines of the enhanced model.

g11 2 4 poly(4) (10,2) (11,2) (4,2) (66,0) 0 1E-12 1E-12 1E-12
100E-9

g21 1 4 poly(4) (10,1) (12,1) (4,1) (68,0) 0 1E-12 1E-12 1E-12
100E-9

Node 1 and 2 are the input pins. g11 and g21 should simulate input
currents proportional to the negative supply voltage(4), the common
source point(10) the drain(11 close to V-) and node 66 which is close
to (0). Assuming 15V for the negative supply gives bias currents of
15V*1e-12 = 15pA.

Finally I am wondering how PSPICE can calculate 40fA bias current.

Best Regards
Helmut

--- In LTspice@..., "Helmut Sennewald"
<helmutsennewald@y...> wrote:

--- In LTspice@..., "john_oztek" <joconnor@o...> wrote:

Are there any special considerations with using P-spice op-amp

macro

models with LTspice? I'm trying to simulate a circuit that uses

a

Burr Brown/TI electrometer op-amp (OPA128 or OPA129) and I'm

getting

incorrect results. I downloaded the models from TI's website.

The

circuit's been built and thoroughly debugged, so I'm confident in

the

design.

When I couldn't get the circuit to operate correctly, I entered a
simple test circuit to verify some of the basic op-amp
characteristics. I found that the input bias current was way to

high

(about 12nA instead of 100fA), and the gain-bandwidth of the

OPA129

was high by about a factor of 10. I suspect that the models are

just

screwed up, but since I'm new to LTspice I'm not completely

confident

with my conclusion. Any help would be greatly appreciated.

Hello John,
I tried to verify your results and the bias currents are indeed a

lot

higher than expected. I looked around in the LTSPICE settings for
possible leakage currents and other precision important parameters.
Finally I have found that we need the command line

.OPTIONS gmin=0 (or at least <1e-18)

It defines the minimum conductance added to every node.
The simulated input bias current is then 40pA for the OPA128 and
OPA129.
The AC-gain results are really by a factor of ten too high for the
OPA129/OPA129E.

I still don't know why the enhanced models OPA128E and OPA129E

still

shows bias currents of about 30pA instead of 40fA.
I tried the OPA129E with the PSPICE 8.0 demo.
Surprise, surprise! Even with the OPA129E, the bias current has

been

40fA. Something seems to go wrong in LTSPICE with this enhanced

model

in the .OP calculation.

The .AC simulation shows exactly the same results in PSPICE as in
LTSPICE.

Best Regards
Helmut

Helmut,

Thanks for looking into this and going to the trouble of duplicating
my results. I've also had problems with the enhanced model for the
INA128 instrumentation amplifier. The standard model seems to work
OK although it does have a little trouble converging. One thing for
sure, it's definitely worth the effort of proving the model in a
simple circuit against data sheet specs, particularly when second
order effects are critical.

Thanks,
John

--- In LTspice@..., "john_oztek" <joconnor@o...> wrote:

Are there any special considerations with using P-spice op-amp

macro

models with LTspice? I'm trying to simulate a circuit that uses a
Burr Brown/TI electrometer op-amp (OPA128 or OPA129) and I'm

getting

incorrect results. I downloaded the models from TI's website.

The

circuit's been built and thoroughly debugged, so I'm confident in

the

design.

When I couldn't get the circuit to operate correctly, I entered a
simple test circuit to verify some of the basic op-amp
characteristics. I found that the input bias current was way to

high

(about 12nA instead of 100fA), and the gain-bandwidth of the OPA129
was high by about a factor of 10. I suspect that the models are

just

screwed up, but since I'm new to LTspice I'm not completely

confident

with my conclusion. Any help would be greatly appreciated.

Hello John,
I tried to verify your results and the bias currents are indeed a lot
higher than expected. I looked around in the LTSPICE settings for
possible leakage currents and other precision important parameters.
Finally I have found that we need the command line

.OPTIONS gmin=0 (or at least <1e-18)

It defines the minimum conductance added to every node.
The simulated input bias current is then 40pA for the OPA128 and
OPA129.
The AC-gain results are really by a factor of ten too high for the
OPA129/OPA129E.

I still don't know why the enhanced models OPA128E and OPA129E still
shows bias currents of about 30pA instead of 40fA.
I tried the OPA129E with the PSPICE 8.0 demo.
Surprise, surprise! Even with the OPA129E, the bias current has been
40fA. Something seems to go wrong in LTSPICE with this enhanced model
in the .OP calculation.

The .AC simulation shows exactly the same results in PSPICE as in
LTSPICE.

Best Regards
Helmut

Are there any special considerations with using P-spice op-amp macro
models with LTspice? I'm trying to simulate a circuit that uses a
Burr Brown/TI electrometer op-amp (OPA128 or OPA129) and I'm getting
incorrect results. I downloaded the models from TI's website. The
circuit's been built and thoroughly debugged, so I'm confident in the
design.

When I couldn't get the circuit to operate correctly, I entered a
simple test circuit to verify some of the basic op-amp
characteristics. I found that the input bias current was way to high
(about 12nA instead of 100fA), and the gain-bandwidth of the OPA129
was high by about a factor of 10. I suspect that the models are just
screwed up, but since I'm new to LTspice I'm not completely confident
with my conclusion. Any help would be greatly appreciated.

Thanks,
John

--- In LTspice@..., D Chisholm <dchishol@c...> wrote:

You may have to download the complete package and re-install from
scratch under Wine. I had this problem (sync release didn't work) when
I had LTSpice on my machine at work behind a corporate firewall.

It wasn't a really big deal on my NT station. I just downloaded the
latest release every couple of weeks, and the new version always
installed smoothly over the old version. The only glitch is that the
standard component library files get clobbered by the new installation.
(These are the files called "standard.bjt", "standard.dio", etc in
"..&#92;SwCADIII&#92;lib&#92;cmp".) If you've added any transistors, capacitors,
etc to these databases you'll lose the data. (The Sync Release tool
merges your additions to the old database, with the new database

files -

which I find rather impressive!) To work around this, I created a
parallel structure of files called "additions.bjt", "additions.dio",
etc to hold info for the the components I added then I used a text
editor to append my "additions.xxx" on the end of the "standard.xxx"
files after every re-installation. A DOS macro of about 3 lines could
probably do the same thing with the "copy <file1>+<file2>" command if I
was too lazy to open the text editor.

Maybe this summer Mike (Englehardt) will get a student intern who can
re-work the installation package so the user can specify either a
complete installation or simply update an existing installation . . .

Dale

Thank You for the advice.
I tried to re-install from scratch under Wine but I have the same
problem. I think I will follow the procedure that You use under NT.

Thank You again

Stefano