开云体育

----- Original Message -----
From: Lewis
To: LTspice@...
Sent: Friday, September 23, 2011 12:50 AM
Subject: [LTspice] Re: New Member and Updated Help File





I think there may be a small misunderstanding here.
The question posed on the Yahoo group was:
"...if Mike would put a direct link to the Wiki page in the LTspice Help tab?" That answer was:
"I'd rather not. I don't supply the information
for the Wiki site, so it's really better if I don't
endorse it. "

I personally wrote Mike about the use of the LTspice help file on . His reply is below (of which I earlier referred.)

"Please use the file LTspiceHelp.chm. I'm trying
to phase out the .pdf. The only reason the .pdf
ever existed was because of a short-coming in
WINE for which there is now a workaround. Also,
please make it clear what part is from LTC and
what part is others. I see users trying to
"improve" help documentation only to obscure
the software operation.

--Mike "

It is not my intent to have any copyright violation on the wiki, and would gladly remove any entry that was not allowed. By using the Iframes (i.e. not allowing contributors to edit the original LTspice help file, only to comment and extend it below each page), I've lived up to his request to make it clear which part is from LTC. If Mike or LTC wants a stronger reference to the original work, I'd gladly oblige.

best regards,
Lewis
--- In LTspice@..., Howard Hansen <hrhan@...> wrote:
>
> On 9/22/2011 3:22 PM, Helmut wrote:
> >
> > --- In LTspice@..., "Lewis"<lineblp@> wrote:
> >> Good news! I've finished converting the LTspice help file
> >> for use in LTwiki<> .
> >
> > Hello Lewis,
> >
> > This action has been a bad idea and it is a copyright
> > infringement. Haven't you read the answer from Mike?
> > He hasn't allowed to put his help text into the Wiki.
> > Why have you ignored his statement?
> > I highly recommend you to remove it from this Wiki.
> >
> > Best regards,
> > Helmut
> > Moderator of the LTspice Yahoo group
> >
> Hello Helmut,
>
> I am confused as Lewis reported the following in message 49950.
>
> "- Mike graciously allowed use of the existing help as a basis for an
> expanded and annotated help in LTwiki, specifically the LTspiceHelp.chm
> not the scad3.pdf.
> - In doing so, we must make it clear what is the original versus the
> annotated."
>
> To me this implies Lewis can use the existing help file in his Wiki
>
> Howard
>

--- In LTspice@..., "Tony Casey" <tony@...> wrote:

--- In LTspice@..., "whynotme1843" <hstinson@> wrote:

I am new to LTSpice, and I am having a very hard time finding a model for the IRL630, previously available from International Rectifier, now from Vishay. Does anyone know of a SPICE model existing somewhere, or does anyone know of a similar MOSFET with an existing/easily found model? Thank you so much for your help.

I can't imagine why you're having such a hard time finding a model for this device. It took me 1m 45s on the Vishay website to find it.

Did you even think of looking there?

Regards,
Tony

--- In LTspice@..., Howard Hansen <hrhan@...> wrote:

On 9/22/2011 3:22 PM, Helmut wrote:

--- In LTspice@..., "Lewis"<lineblp@> wrote:

Good news! I've finished converting the LTspice help file
for use in LTwiki<> .

Hello Lewis,

This action has been a bad idea and it is a copyright
infringement. Haven't you read the answer from Mike?
He hasn't allowed to put his help text into the Wiki.
Why have you ignored his statement?
I highly recommend you to remove it from this Wiki.

Best regards,
Helmut
Moderator of the LTspice Yahoo group

Hello Helmut,

I am confused as Lewis reported the following in message 49950.

"- Mike graciously allowed use of the existing help as a basis for an
expanded and annotated help in LTwiki, specifically the LTspiceHelp.chm
not the scad3.pdf.
- In doing so, we must make it clear what is the original versus the
annotated."

To me this implies Lewis can use the existing help file in his Wiki

Howard

On 9/22/2011 4:08 PM, whynotme1843 wrote:

I am new to LTSpice, and I am having a very hard time finding a model
for the IRL630, previously available from International Rectifier, now
from Vishay. Does anyone know of a SPICE model existing somewhere, or
does anyone know of a similar MOSFET with an existing/easily found
model? Thank you so much for your help.

On 9/22/2011 2:57 PM, Joe Walsh wrote:

--- In LTspice@... <mailto:LTspice%40yahoogroups.com>,
Ganesan <dg1@...> wrote:

I have been in the IC design business for over 30 yrs and in the
component circuit design business for over 20 yrs. Exceeding the safe
operating limit of a device even for a few pico seconds every clock
cycle produces time dependent device failure.. My friend UN-KUN -MOON
covered this in detail in a talk on Low Voltage CMOS circuits, a few
years ago at the ISSCC.. The issue is not that you got away driving at
100mph.. the issues is that of when are you going to kill.? It is a
matter of time.. Another company which tried to release +or-15v
products (which normally require a 36V technology) in a 20-24 volts
technology by playing circuit games learned a bitter lesson in field
failures. In today's technologies , where operating limits are pushing
the technology limits, it is even more imperative that these alarms be
included in LTspice. Normally I don't like false alarms, because you

got

to search through the forest to find the needle; but in this case that
is a better option than field failures..
cheers
AG

On 9/22/2011 10:11 AM, Joe Walsh wrote:

--- In LTspice@... <mailto:LTspice%40yahoogroups.com>

<mailto:LTspice%40yahoogroups.com>,

"Helmut" <helmutsennewald@> wrote:

--- In LTspice@...

<mailto:LTspice%40yahoogroups.com> <mailto:LTspice%40yahoogroups.com>,

"ian.ballard@" <ian.ballard@> wrote:

In the ltspice diode models there are a number of variable which

can be set Vpk, Ipk, Iave etc which "allow LTspice to check if the
diode is being used beyond its rated capability". If you run a
simulation is there an easy way to tell if one of the components has
exceeded its rating without examining each component individual?

any help appreciated

Hello Ian,

LTspice checks Iave and Vpk when you run a simulation with
an SMPS-IC from LTC using the "steady" option in ".tran".
If the limit is exceeded, the diode will be marked with a
black exclamation mark in a yellow filled circular area
in the schematic.

In every other simulation you have to check it by yourself.

Best regards,
Helmut

I think I'll chime in on this one...

It appears that what you want to do is perform SOA (Safe Operating
Area) simulations? I'm an IC designer and I routinely violate the

Safe

Operating Areas on devices; my circuits only have to operate reliably
for 10-100 hours out of a full IC lifetime of 10-15 years. I know,
sounds wierd, but my circuits don't run in DC mode.

If you are simulating a small circuit, LTSpice *may* work, but it

will

take some work on your part as I have not thought out thoroughly how
this could be performed, nor have I actually tried it in LTSpice.
However, I think it can be done with .MEASURE TRAN statements. If you
are simulating a big circuit on LTSpice with 10's or 100's of
components that could exceed the voltage ratings - forget it, too

much

work and headache. The "big boy" design tools such as Cadence

Virtuoso

allow for such capability, so I will describe it first. Each
component: MOSFETs, capacitors, diodes, etc have 0-volt sources
connected between each terminal. These voltage sources have

acceptable

range limits assigned to them along with a pre-canned error message.
Once the circuit voltage exceeds the range on any of these voltage
sources, the simulator outputs a message informing the designer that
the voltage has been exceeded at time X. When the voltage comes back
into the "safe" area, the simulator outputs another message

indicating

at time Y that the component is within normal range.

The designer then has to wade through all the "errors" in the log

file

to find the real errors whose total time (Y-X) in the danger zone
(i.e. exceeding SOA limits) exceed some threshold amount - purely up
to the designer. The reason being that normal transient simulations
may exhibit very short spikes that routinely exceed the limits, but
rarely are longer than 1nsec in duration.

So, in LTSpice, a designer could create .MEASURE TRAN statements to
measure a voltage across a diode or FET for instance and capture when
the voltage RISEs past the spec limit and also a corresponding
.MEASURE TRAN statement when the voltage FALLs back within the spec
limits. The designer then needs to parse the log file to measure the
time delta between the two error messages to obtain the full time

that

the limits were exceeded. I've written such scripts (or had them
written for me) to help weed out narrow spikes that were not of
importance. I've routinely done this on large circuits and ended up
with hundreds or thousands of "errors" that had to be checked

manually

- not a fun proposition and one reason I would not endeavor to try
this on LTSpice that doesn't contain specialized tools or models to
handle such behavior (minus what was already mentioned by Helmut in
the previous post.)

Once this is done, the designer can then plot the voltages (or
currents) on the offending devices and fix his/her circuit.

Sorry for the long post,
Joe Walsh

Ganesan,

I'm not going to get into an argument over this, nor do I care who you
are supposed friends with (whose name you didn't even spell correctly.
I've met him and he's a very nice and personable fellow and quite
smart.) There were several things I didn't mention because they were
not important to the discussion and are company proprietary. I also
didn't say what kind of circuits I was designing (here again company
proprietary with respect to this discussion) and I certainly didn't
say that I was playing "circuit games"; we fully understand the rules
of the game and how to maintain our circuits within the parameters
given to us - that's why I'm paid to be an engineer. Yes, there is a
strong time dependency with regards to exceeding the limits, but you
didn't read my email very carefully to see that I mentioned this in a
round-about and admittedly obscure way. If you were mentioning it for
the sake of others on this list who might not know this information,
fine. Maybe I shouldn't have taken it personally - but I did.

I was simply trying to answer how it *could* be performed in LTSpice
and to indicate that then the log file must be parsed to extract the
time information and which devices are being stressed/blown up. What
an engineer does with the information is up to him/her and to decide
what is a needle and what is part of the haystack. It's a difficult
and long process for sure.

Two things:
1) A correction is due on my part; SOA limits are not up to the
designer to set, these are set by the technology process engineers. I
didn't say these limits always make sense or are practical.
2) SOA limits != breakdown limits. In fact, SOA limits are well within
the breakdown limits. Refer to #1.

Joe Walsh

On 9/22/2011 2:57 PM, Joe Walsh wrote:

--- In LTspice@... <mailto:LTspice%40yahoogroups.com>,
Ganesan <dg1@...> wrote:

I have been in the IC design business for over 30 yrs and in the
component circuit design business for over 20 yrs. Exceeding the safe
operating limit of a device even for a few pico seconds every clock
cycle produces time dependent device failure.. My friend UN-KUN -MOON
covered this in detail in a talk on Low Voltage CMOS circuits, a few
years ago at the ISSCC.. The issue is not that you got away driving at
100mph.. the issues is that of when are you going to kill.? It is a
matter of time.. Another company which tried to release +or-15v
products (which normally require a 36V technology) in a 20-24 volts
technology by playing circuit games learned a bitter lesson in field
failures. In today's technologies , where operating limits are pushing
the technology limits, it is even more imperative that these alarms be
included in LTspice. Normally I don't like false alarms, because you

got

to search through the forest to find the needle; but in this case that
is a better option than field failures..
cheers
AG

On 9/22/2011 10:11 AM, Joe Walsh wrote:

--- In LTspice@... <mailto:LTspice%40yahoogroups.com>

<mailto:LTspice%40yahoogroups.com>,

"Helmut" <helmutsennewald@> wrote:

--- In LTspice@...

<mailto:LTspice%40yahoogroups.com> <mailto:LTspice%40yahoogroups.com>,

"ian.ballard@" <ian.ballard@> wrote:

In the ltspice diode models there are a number of variable which

can be set Vpk, Ipk, Iave etc which "allow LTspice to check if the
diode is being used beyond its rated capability". If you run a
simulation is there an easy way to tell if one of the components has
exceeded its rating without examining each component individual?

any help appreciated

Hello Ian,

LTspice checks Iave and Vpk when you run a simulation with
an SMPS-IC from LTC using the "steady" option in ".tran".
If the limit is exceeded, the diode will be marked with a
black exclamation mark in a yellow filled circular area
in the schematic.

In every other simulation you have to check it by yourself.

Best regards,
Helmut

I think I'll chime in on this one...

It appears that what you want to do is perform SOA (Safe Operating
Area) simulations? I'm an IC designer and I routinely violate the

Safe

Operating Areas on devices; my circuits only have to operate reliably
for 10-100 hours out of a full IC lifetime of 10-15 years. I know,
sounds wierd, but my circuits don't run in DC mode.

If you are simulating a small circuit, LTSpice *may* work, but it

will

take some work on your part as I have not thought out thoroughly how
this could be performed, nor have I actually tried it in LTSpice.
However, I think it can be done with .MEASURE TRAN statements. If you
are simulating a big circuit on LTSpice with 10's or 100's of
components that could exceed the voltage ratings - forget it, too

much

work and headache. The "big boy" design tools such as Cadence

Virtuoso

allow for such capability, so I will describe it first. Each
component: MOSFETs, capacitors, diodes, etc have 0-volt sources
connected between each terminal. These voltage sources have

acceptable

range limits assigned to them along with a pre-canned error message.
Once the circuit voltage exceeds the range on any of these voltage
sources, the simulator outputs a message informing the designer that
the voltage has been exceeded at time X. When the voltage comes back
into the "safe" area, the simulator outputs another message

indicating

at time Y that the component is within normal range.

The designer then has to wade through all the "errors" in the log

file

to find the real errors whose total time (Y-X) in the danger zone
(i.e. exceeding SOA limits) exceed some threshold amount - purely up
to the designer. The reason being that normal transient simulations
may exhibit very short spikes that routinely exceed the limits, but
rarely are longer than 1nsec in duration.

So, in LTSpice, a designer could create .MEASURE TRAN statements to
measure a voltage across a diode or FET for instance and capture when
the voltage RISEs past the spec limit and also a corresponding
.MEASURE TRAN statement when the voltage FALLs back within the spec
limits. The designer then needs to parse the log file to measure the
time delta between the two error messages to obtain the full time

that

the limits were exceeded. I've written such scripts (or had them
written for me) to help weed out narrow spikes that were not of
importance. I've routinely done this on large circuits and ended up
with hundreds or thousands of "errors" that had to be checked

manually

- not a fun proposition and one reason I would not endeavor to try
this on LTSpice that doesn't contain specialized tools or models to
handle such behavior (minus what was already mentioned by Helmut in
the previous post.)

Once this is done, the designer can then plot the voltages (or
currents) on the offending devices and fix his/her circuit.

Sorry for the long post,
Joe Walsh

Ganesan,

I'm not going to get into an argument over this, nor do I care who you
are supposed friends with (whose name you didn't even spell correctly.
I've met him and he's a very nice and personable fellow and quite
smart.) There were several things I didn't mention because they were
not important to the discussion and are company proprietary. I also
didn't say what kind of circuits I was designing (here again company
proprietary with respect to this discussion) and I certainly didn't
say that I was playing "circuit games"; we fully understand the rules
of the game and how to maintain our circuits within the parameters
given to us - that's why I'm paid to be an engineer. Yes, there is a
strong time dependency with regards to exceeding the limits, but you
didn't read my email very carefully to see that I mentioned this in a
round-about and admittedly obscure way. If you were mentioning it for
the sake of others on this list who might not know this information,
fine. Maybe I shouldn't have taken it personally - but I did.

I was simply trying to answer how it *could* be performed in LTSpice
and to indicate that then the log file must be parsed to extract the
time information and which devices are being stressed/blown up. What
an engineer does with the information is up to him/her and to decide
what is a needle and what is part of the haystack. It's a difficult
and long process for sure.

Two things:
1) A correction is due on my part; SOA limits are not up to the
designer to set, these are set by the technology process engineers. I
didn't say these limits always make sense or are practical.
2) SOA limits != breakdown limits. In fact, SOA limits are well within
the breakdown limits. Refer to #1.

Joe Walsh

On 9/22/2011 11:47 AM, Helmut wrote:

--- In LTspice@... <mailto:LTspice%40yahoogroups.com>,
Ganesan <dg1@...> wrote:

Depending on how Tony did, bin 900 includes 895-905 or
900-910. I would
expect roughly 250 or 500 occurences...
Cheers
AG
You are right!... I have never won the lottery.

Hello AG,

I have uploaded the same plotted with the free DPLOT95.
It correctly shows the bins.

Files > Temp > mc1000_01.gif
Files > Temp > mc_distri.asc

RUN mc_distri
File -> Export

Start DPLOT95
Open the exported file. Choose type D.
Generate -> histogram

DPLOT95 is here:



Best regards,
Helmut

.

On 9/22/2011 11:08 AM, John Woodgate wrote:

In message <4E7B459B.9050806@...
<mailto:4E7B459B.9050806%40austin.rr.com>>, dated Thu, 22 Sep 2011,
Ganesan <dg1@... <mailto:dg1%40austin.rr.com>> writes:

In 10000 iterations the value 900 never seems to show up.. Is this a
binning issue of the histogram or is there a bias in the "MC "
function?

900 is the number of the secret winning ticket that wins 70 million
dollars. So it's not surprising that you didn't win with only 10000
tries.(;-)
--
OOO - Own Opinions Only. Try www.jmwa.demon.co.uk and www.isce.org.uk
John Woodgate, J M Woodgate and Associates, Rayleigh, Essex UK
When I point to a star, please look at the star, not my finger. The
star will
be more interesting.

Switch to: Text-Only
<mailto:LTspice-traditional@...

<mailto:LTspice-traditional%40yahoogroups.com>?subject=Change%20Delivery%20Format:%20Traditional>,

Daily Digest
<mailto:LTspice-digest@...

<mailto:LTspice-digest%40yahoogroups.com>?subject=Email%20Delivery:%20Digest>

. Unsubscribe
<mailto:LTspice-unsubscribe@...

<mailto:LTspice-unsubscribe%40yahoogroups.com>?subject=Unsubscribe> .

Terms of Use <>
.

On 9/22/2011 11:08 AM, John Woodgate wrote:

In message <4E7B459B.9050806@...
<mailto:4E7B459B.9050806%40austin.rr.com>>, dated Thu, 22 Sep 2011,
Ganesan <dg1@... <mailto:dg1%40austin.rr.com>> writes:

In 10000 iterations the value 900 never seems to show up.. Is this a
binning issue of the histogram or is there a bias in the "MC "
function?

900 is the number of the secret winning ticket that wins 70 million
dollars. So it's not surprising that you didn't win with only 10000
tries.(;-)
--
OOO - Own Opinions Only. Try www.jmwa.demon.co.uk and www.isce.org.uk
John Woodgate, J M Woodgate and Associates, Rayleigh, Essex UK
When I point to a star, please look at the star, not my finger. The
star will
be more interesting.

Switch to: Text-Only
<mailto:LTspice-traditional@...?subject=Change%20Delivery%20Format:%20Traditional>,
Daily Digest
<mailto:LTspice-digest@...?subject=Email%20Delivery:%20Digest>
. Unsubscribe
<mailto:LTspice-unsubscribe@...?subject=Unsubscribe> .
Terms of Use <>
.