J
Joerg
Jim said:
That doesn't explain why the other opamps work just fine.
-
Categories
-
Platforms
-
Content
LTSpice: Slow on noise sims with foreign opamps
That doesn't explain why the other opamps work just fine.
J
Joerg
Jim said:
Hmm, the OPA model is -IN +IN V- V+ Vout.
Is that customary at TI, or in the old Burr-Brown world? If so the I
should make a OpAmp2TI or something.
J
Joerg
Jim said:
Looks like pin order (the one you initially suggested as well as the one
the OPA model has), thanks for the hint.
But now SWMBO wants me to start the barbecue. Pizza over charcoal, in
the Weber, yummmm. With lots of Jalapenos on there. Those burn twice ...
J
Joerg
Jim said:
In the great state of Texas it seems to be -IN +IN V- V+ Vout. So I made
Opamp2TI with the Texan pinout and ... shazam! That was it, now it
runneth. Thanks, Jim.
Now the barbie is ready, got to head outside to cook dinner. It's a
balmy 40F or so I guess.
J
Joerg
Jim said:
Opamp2 is the one that has five pins and that works with all the opamps
I had tried, except for the Burr-Brown/TI parts. So I copied Opamp2.asy
and made another Opamp2TI.asy out of that, now it all works fine. That
way I don't have to muck with the model files because that's always a
dicey proposition.
Yup, I figured it out yesterdas, see my other reply in the thread. But
by then the barbie was ready and that's when the end of the workday is
not negotiable with my better half.
J
Joerg
Phil said:
I'd rather not touch those if possible. It feels like messing with a
datasheet. After all, a SPICE model is usually something released by a
manufacturer unless you build your own from component data.
J
Joerg
Jim said:
That's a good method, although it does add to the clutter of SPICE
directives on the sheet.
That's a lot. But as an IC guy you live SPICE, us circuit guys live CAD.
I have a ton of custom symbols for the schematic editor.
I've got to break my better half of piling things on high shelves.
Yesterday, during a "get this down for me honey" request, a dish
drainer try came loose from her pile, hit me in the head, then spun
around and cut the back of my hand open :-(
She's just exactly 5' tall, but won't listen when I tell her... just
come and get me and _I'll_ put it away for you. She just stands
"on-tippy-toe" and shoves stuff on top of the stack. The cookie sheet
pile can be hazardous to one's health
Oh yeah! The situation is quite similar here. She it petite and I am the
tall guy. But my wife keeps things lean, if it hasn't been used in x
years it has to go. At least it's not going to the trash, if in good
condition then it'll become a thrift store donation. Our kitchen doesn't
have shelves, it's all humongous cabinets but the top sections don't
carry much. Mostly things like Christmas decorations that only have to
come out once a year.
F
Fred Abse
I wish I had your faith...
J
Joerg
Jim said:
Pin ORDER doesn't change the model... it just matches up the symbol's
pin order to the subcircuit declaration.
If you were a regular Spice user you'd know all about the importance
of pin order and subcircuit declarations.
As far as "messing", you "messed" with the symbol pin order didn't you
?
I'd rather have symbol consistency. In your world some days the base
of a tranny would be a collector ??
In my world a new package and CAD symbol gets created if even one lone
pin is different from customary. But never in the datasheet, and I
usually never veer from the outline in that datasheet for pin
descriptors and such.
J
Joerg
Jim said:
If you meant "changed in the .lib file" then no, that's not what I want
to do.
[...]
J
Joerg
Jim said:In my world a new package and CAD symbol gets created if even one loneJim said:Phil Hobbs wrote:
On 1/5/2013 7:36 PM, Joerg wrote:
Jim Thompson wrote:
[...]
Looks like LTspice order, for OpAmp2 symbol is...
IN+ IN- V+ V- Vout
Hmm, the OPA model is -IN +IN V- V+ Vout.
Is that customary at TI, or in the old Burr-Brown world? If so the I
should make a OpAmp2TI or something.
It's easier to tweak the model. That way it's right the next time.
I'd rather not touch those if possible. It feels like messing with a
datasheet. After all, a SPICE model is usually something released by a
manufacturer unless you build your own from component data.
Pin ORDER doesn't change the model... it just matches up the symbol's
pin order to the subcircuit declaration.
If you were a regular Spice user you'd know all about the importance
of pin order and subcircuit declarations.
As far as "messing", you "messed" with the symbol pin order didn't you
?
I'd rather have symbol consistency. In your world some days the base
of a tranny would be a collector ??
pin is different from customary. But never in the datasheet, and I
usually never veer from the outline in that datasheet for pin
descriptors and such.
You just made my point... Why should I have more than one symbol for
all the thousands of 5-pin OpAmps?
Because else one has to muck with the text in the lib file. That's a
no-no in a controlled design environment. Just imagine I had a file
called ThompsonAmp.lib and the pin order in there is not right for my
simulator. Suppose I'd change that in the ThompsonAmp.lib file and now
it works. How should I store that file? If it's then stored as
ThompsonAmp.lib and an auditor from the FDA or another agency finds out,
oh boy. Even if I store it under another name the action of changing
something in there must be justified in writing and documented if
working on a sensitive project.
M
miso
Like I said yesterday. Something isn't hooked up right in the model.;-)
J
josephkk
Jim said:Jim Thompson wrote:
Phil Hobbs wrote:
On 1/5/2013 7:36 PM, Joerg wrote:
Jim Thompson wrote:
[...]
Looks like LTspice order, for OpAmp2 symbol is...
IN+ IN- V+ V- Vout
Hmm, the OPA model is -IN +IN V- V+ Vout.
Is that customary at TI, or in the old Burr-Brown world? If so the I
should make a OpAmp2TI or something.
It's easier to tweak the model. That way it's right the next time.
I'd rather not touch those if possible. It feels like messing with a
datasheet. After all, a SPICE model is usually something released by a
manufacturer unless you build your own from component data.
Pin ORDER doesn't change the model... it just matches up the symbol's
pin order to the subcircuit declaration.
If you were a regular Spice user you'd know all about the importance
of pin order and subcircuit declarations.
As far as "messing", you "messed" with the symbol pin order didn't you
?
I'd rather have symbol consistency. In your world some days the base
of a tranny would be a collector ??
In my world a new package and CAD symbol gets created if even one lone
pin is different from customary. But never in the datasheet, and I
usually never veer from the outline in that datasheet for pin
descriptors and such.
You just made my point... Why should I have more than one symbol for
all the thousands of 5-pin OpAmps?
Because else one has to muck with the text in the lib file. That's a
no-no in a controlled design environment. Just imagine I had a file
called ThompsonAmp.lib and the pin order in there is not right for my
simulator. Suppose I'd change that in the ThompsonAmp.lib file and now
it works. How should I store that file? If it's then stored as
ThompsonAmp.lib and an auditor from the FDA or another agency finds out,
oh boy. Even if I store it under another name the action of changing
something in there must be justified in writing and documented if
working on a sensitive project.
So wrap a schematic level subcircuit to fix the pin order.
?-)
S
SoothSayer
Writing a script to dork the library and then put it back would be
pretty simple.
Cheers
Phil Hobbs
Simply save it as an additional component. Keep that "added item"
count low and manageable. One can even create one's own 'custom'
'library' to include in a local corporate environ so the devices are
available on all machines.
J
Joerg
Jim said:Joerg has a knack for making things overly complicated. ...Jim Thompson wrote:
Jim Thompson wrote:
Phil Hobbs wrote:
On 1/5/2013 7:36 PM, Joerg wrote:
Jim Thompson wrote:
[...]
Looks like LTspice order, for OpAmp2 symbol is...
IN+ IN- V+ V- Vout
Hmm, the OPA model is -IN +IN V- V+ Vout.
Is that customary at TI, or in the old Burr-Brown world? If so the I
should make a OpAmp2TI or something.
It's easier to tweak the model. That way it's right the next time.
I'd rather not touch those if possible. It feels like messing with a
datasheet. After all, a SPICE model is usually something released by a
manufacturer unless you build your own from component data.
Pin ORDER doesn't change the model... it just matches up the symbol's
pin order to the subcircuit declaration.
If you were a regular Spice user you'd know all about the importance
of pin order and subcircuit declarations.
As far as "messing", you "messed" with the symbol pin order didn't you
?
I'd rather have symbol consistency. In your world some days the base
of a tranny would be a collector ??
In my world a new package and CAD symbol gets created if even one lone
pin is different from customary. But never in the datasheet, and I
usually never veer from the outline in that datasheet for pin
descriptors and such.
You just made my point... Why should I have more than one symbol for
all the thousands of 5-pin OpAmps?
Because else one has to muck with the text in the lib file. That's a
no-no in a controlled design environment. Just imagine I had a file
called ThompsonAmp.lib and the pin order in there is not right for my
simulator. Suppose I'd change that in the ThompsonAmp.lib file and now
it works. How should I store that file? If it's then stored as
ThompsonAmp.lib and an auditor from the FDA or another agency finds out,
oh boy. Even if I store it under another name the action of changing
something in there must be justified in writing and documented if
working on a sensitive project.
So wrap a schematic level subcircuit to fix the pin order.
?-)
No, I have a knack for sticking with the rules set forth by the
Federales and others. As a result I have so far aced all audits during
my whole career, and when one works in a heavily regulated field those
can happen frequently. Including unannounced audits.
All I did was
Sure. But one does not distribute a modified lib file under the same
name as the unmodified one from the vendor. At least in medical and
aerospace that would be a way to land in hot doo-doo, very fast. Some
people and even whole companies learn this the hard way.
Nope. Cadsoft Eagle.
J
josephkk
Now how am i supposed to figure out who or what you are replying to?
?-)
J
Joerg
Jim said:
It's a subcircuit already, so I'd have to declare a subcircuit in a
subcircuit. That would work and should be audit-proof because no trail
gets broken. Like the SW-guys with their C compilers, setting up a
pointer to a pointer to a pointer
In this case it wouldn't be the FDA but some other agency. Anyhow, I did
that sim a while ago and I now have a symbol named "opamp2TI". Woiks fine.
J
Joerg
Jim said:
Yup, saw that. This is why I said it should be legit because that way
you don't have two different devices with the same name.
In California they do this kind of stuff using "revenue anticipation"
bonds. Or in banker speak, they leverage the leverage that was already
leveraged.
It woiks poifectly.
Watched an epidode of "All in the Family" a couple days ago. The one
where Edith accepted an invitation by the Jeffersons and Archie ...
well, you know how he reacted.
J
Joerg
Jim said:
Oh yeah, definitely. I think we saw each episode at least five times. To
the point where my wife sometimes counters "Yes, Archie" when I want to
have my say about something.
When I was a kid I repaired old TV sets and while at it discovered that
with some more elaborate aerial I could pull in Dutch TV. They brought
All in the Family, original with sub-titles. That's in part how I
learned English. So I learned the not so good words first, like stifle,
Sigmund Fruit, groinecologist, gyropractor, fillit micknon, allamac and
so on.
J
Joerg
Jim said:
Now, now, I thought you claimed to be couth ... tsk, tsk, tsk.
