LT Spice noise analysis

[John Larkin]

I wonder why it requires a noiseless input source to be specified.

Any why does it only analyze the noise at one node? Given that, why do
I have to probe that one node?



--

John Larkin Highland Technology, Inc
picosecond timing precision measurement

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

[Gerhard Hoffmann]

Am 27.02.2017 um 20:21 schrieb John Larkin:
>
>
> I wonder why it requires a noiseless input source to be specified.
>
> Any why does it only analyze the noise at one node? Given that, why do
> I have to probe that one node?

When the simulator knows where the input is, it can weigh all noise
sources in how much they impair the input signal. A strong noise source
that does not make it to the output is not interesting.

You can have as many components computed as you like and you can
study their contribution to the result.

See
<
https://www.flickr.com/photos/137684711@N07/33002503592/in/dateposted-public/lightbox/
>

The signal "gain" is predefined and does the obvious job.

The next picture shows the preamp in statu nascendi, it is
still misbehaving. :-( ( 4 pairs of IF3602, they are all
individuals; I'll have to spend another few hundred €€€ to
get 4 vaguely similar pairs.)

cheers, Gerhard

[Kevin Aylward]

"Gerhard Hoffmann" wrote in message
news:ehk1t7...@mid.individual.net...

>Am 27.02.2017 um 20:21 schrieb John Larkin:
>
>
>> I wonder why it requires a noiseless input source to be specified.
>
>> Any why does it only analyze the noise at one node? Given that, why do
>> I have to probe that one node?

>When the simulator knows where the input is, it can weigh all noise
>sources in how much they impair the input signal. A strong noise source
>that does not make it to the output is not interesting.
>You can have as many components computed as you like and you can
>study their contribution to the result.

Not quite sure what you are saying here.

The point of knowing the input source is to calculate the equivalent input
noise, referred to that source. For something like a bandgap voltage
reference, there is no input source to refer it to. Only the output noise
matters.


-- Kevin Aylward
http://www.anasoft.co.uk/ - SuperSpice
http://www.kevinaylward.co.uk/ee/index.html

[Phil Hobbs]

On 02/28/2017 04:16 PM, Kevin Aylward wrote:
> "Gerhard Hoffmann" wrote in message
> news:ehk1t7...@mid.individual.net...
>
>> Am 27.02.2017 um 20:21 schrieb John Larkin:
>>
>>
>>> I wonder why it requires a noiseless input source to be specified.
>>
>>> Any why does it only analyze the noise at one node? Given that, why do
>>> I have to probe that one node?
>
>> When the simulator knows where the input is, it can weigh all noise
>> sources in how much they impair the input signal. A strong noise source
>> that does not make it to the output is not interesting.
>> You can have as many components computed as you like and you can
>> study their contribution to the result.
>
> Not quite sure what you are saying here.
>
> The point of knowing the input source is to calculate the equivalent
> input noise, referred to that source. For something like a bandgap
> voltage reference, there is no input source to refer it to. Only the
> output noise matters.
>

Seems as though on modern hardware it ought to be possible to keep N**2
partial derivatives, so that you could change inoise and onoise without
re-doing the analysis every time.

Cheers

Phil Hobbs


--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

[Jim Thompson]

On Tue, 28 Feb 2017 17:17:10 -0500, Phil Hobbs
<pcdhSpamM...@electrooptical.net> wrote:

>On 02/28/2017 04:16 PM, Kevin Aylward wrote:
>> "Gerhard Hoffmann" wrote in message
>> news:ehk1t7...@mid.individual.net...
>>
>>> Am 27.02.2017 um 20:21 schrieb John Larkin:
>>>
>>>
>>>> I wonder why it requires a noiseless input source to be specified.
>>>
>>>> Any why does it only analyze the noise at one node? Given that, why do
>>>> I have to probe that one node?
>>
>>> When the simulator knows where the input is, it can weigh all noise
>>> sources in how much they impair the input signal. A strong noise source
>>> that does not make it to the output is not interesting.
>>> You can have as many components computed as you like and you can
>>> study their contribution to the result.
>>
>> Not quite sure what you are saying here.
>>
>> The point of knowing the input source is to calculate the equivalent
>> input noise, referred to that source. For something like a bandgap
>> voltage reference, there is no input source to refer it to. Only the
>> output noise matters.
>>
>
>Seems as though on modern hardware it ought to be possible to keep N**2
>partial derivatives, so that you could change inoise and onoise without
>re-doing the analysis every time.
>
>Cheers
>
>Phil Hobbs

If you are clever with .STEP analysis you can do just that (I am
clever >:-}

Point of ease...

Doesn't matter WHERE you place the AC SOURCE... V(ONOISE), at your
chosen node, will not change

V(INOISE) location is just a simulation subterfuge to calculate
INPUT-REFERRED noise by calculating the gain from that node to the
node you've designated for measuring V(ONOISE).

For a bandgap, use VDD as an AC source with a DC component equal to
+5V or whatever... measure V(ONOISE) at the bandgap output.

...Jim Thompson
--
| James E.Thompson | mens |
| Analog Innovations | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| STV, Queen Creek, AZ 85142 Skype: skypeanalog | |
| Voice:(480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |

Thinking outside the box... producing elegant solutions.

[John Larkin]

But LT Spice doesn't calculate input referred noise.

I just modified my circuit to add a new current source, dumping into a
1 ohm resistor, off to the side, connected to nothing else. And named
that as the input reference device for the noise analysis. The gain
from my new input device to the output is exactly zero.

The output noise didn't change. The named input device does nothing.

Besides, a circuit can have multiple inputs.

[Gerhard Hoffmann]

Am 01.03.2017 um 02:30 schrieb John Larkin:

>
> But LT Spice doesn't calculate input referred noise.

Yes, it clearly does.

Compare the 680u.png and 6u8.png pictures:

Using only 6u8 for C1 (top center) does not kill the noise
contribution of Q1 and D3 (5 times 1n4148 in series) for low
frequencies. These are the gray and the white traces.
And referred to the input, that clearly costs 30 pV/rtHz below 1KHz.
It creates the bump in the top green line, which is v(onoise)/gain.

One can also see that it does not pay to use more than 680u because
of the 1/f noise of the FETs. No need to swim faster than the shark.
Faster than the neighbour is enough.


680uF:
<
https://www.flickr.com/photos/137684711@N07/33029433402/in/dateposted-public/lightbox/
>

6.8uF:
<
https://www.flickr.com/photos/137684711@N07/33058288031/in/dateposted-public/lightbox/
>




Without the active load and just a pull up, VCC noise was also
a problem. That is modelled by R1=60 Ohm which delivers 1 nV/rtHz
and this is multiplied to the desired noise density by E1.

V3, just <> 0 was needed to avoid a div by 0 or whatever. Whithout
the current source load, 2nV/rtHz on VCC was limiting performance.

> I just modified my circuit to add a new current source, dumping into a
> 1 ohm resistor, off to the side, connected to nothing else. And named
> that as the input reference device for the noise analysis. The gain
> from my new input device to the output is exactly zero.
>
> The output noise didn't change. The named input device does nothing.

That would be OK if your previously used source also had a gain of 0.

Outch, scaling to the input would require division by gain, which
is problematic for gain = 0.

>
> Besides, a circuit can have multiple inputs.

In the worst case, that would require multiple runs.
A differential input would not.


I happened to have this circuit in the simulator, it is in the
middle of experimenting, not a finished work. But it was interesting
to start with one BF862, identifying & eliminating the worst noise
source and getting better by each iteration.


Cheers, Gerhard

[pcdh...@gmail.com]

>If you are clever with .STEP analysis you can do just that (I am
>clever >:-}

So you keep telling us. ;)

But the simulator has to compute the exact same stuff over and over, which is a design wart.

Cheers

Phil Hobbs

[pcdh...@gmail.com]

>But LT Spice doesn't calculate input referred noise.

Sure it does--INOISE is just V(ONOISE)/GAIN.
LTspice has some curiosities with units in its plots, so I usually express GAIN as V(onoise)/inoise so I can plot input-referred noise due to various components.

Cheers

Phil Hobbs

[Jim Thompson]

Take it up with Berkeley... the method has never changed... all these
years.

It's not like "over and over" is a big deal... noise/AC analysis
occurs about as fast as you can blink.

[pcdh...@gmail.com]

>Take it up with Berkeley... the method has never changed... all these
>years.

And (AFAIK) all the copies and rewrites do it too. It's still a wart--numerical methods have come a long way since 1970, except in circuit design.

>It's not like "over and over" is a big deal... noise/AC analysis
>occurs about as fast as you can blink.

With discrete circuits, usually so. However, lots of IC models *cough* TI op amps *cough* have ugly convergence issues even with ".savebias internal", so waiting needlessly for that 50 times is annoying.


Cheers

Phil Hobbs

[Jim Thompson]

Take it up with TI and LTspice... LTspice had a lot of convergence
issues with analog parts that other simulators don't.

(Also, You should read up on that important tool .STEP. You should be
able to do component stepping within a single run... minimizing the
bias recalculation.)

[John Larkin]

On Wed, 1 Mar 2017 06:00:12 -0800 (PST), pcdh...@gmail.com wrote:

>>But LT Spice doesn't calculate input referred noise.
>
>Sure it does--INOISE is just V(ONOISE)/GAIN.

I can do that. How do I get Spice to do that?

And GAIN is not a number, it's a function of frequency.

My circuit is a transconductance amp, so GAIN is in ohms.

--

John Larkin Highland Technology, Inc

lunatic fringe electronics

[Phil Hobbs]

On 03/01/2017 09:58 AM, Jim Thompson wrote:
> On Wed, 1 Mar 2017 06:26:23 -0800 (PST), pcdh...@gmail.com wrote:
>
>>> Take it up with Berkeley... the method has never changed... all
>>> these years.
>>
>> And (AFAIK) all the copies and rewrites do it too. It's still a
>> wart--numerical methods have come a long way since 1970, except in
>> circuit design.
>>
>>> It's not like "over and over" is a big deal... noise/AC analysis
>>> occurs about as fast as you can blink.
>>
>> With discrete circuits, usually so. However, lots of IC models
>> *cough* TI op amps *cough* have ugly convergence issues even with
>> ".savebias internal", so waiting needlessly for that 50 times is
>> annoying.

>

> Take it up with TI and LTspice... LTspice had a lot of convergence
> issues with analog parts that other simulators don't.

Nah, ragging you is way more entertaining.

I recall your having trouble with the OPA140 in PSPICE as well. And of
course LTspice's price is right.

>
> (Also, You should read up on that important tool .STEP. You should
> be able to do component stepping within a single run... minimizing
> the bias recalculation.)

I use .step fairly often, but in LTspice it doesn't fix the bias issues.
Changing resistors or voltages makes the bias different on each run.

Using .step to flip switches (nice infinitely differentiable ones) to
connect INOISE to different places in the circuit shouldn't make the
bias move, but for some reason with models like TI's OPA140 LTspice
doesn't skip the entire bias calculation even with .savebias internal.
(Super nice op amp, super crappy model.)

[Phil Hobbs]

On 03/01/2017 10:18 AM, John Larkin wrote:
> On Wed, 1 Mar 2017 06:00:12 -0800 (PST), pcdh...@gmail.com wrote:
>
>>> But LT Spice doesn't calculate input referred noise.
>>
>> Sure it does--INOISE is just V(ONOISE)/GAIN.
>
> I can do that. How do I get Spice to do that?
>
> And GAIN is not a number, it's a function of frequency.
>
> My circuit is a transconductance amp, so GAIN is in ohms.
>
>

Select the plot window, go ctl-A and type "inoise" into the dialogue box.

[John Larkin]

On Wed, 1 Mar 2017 10:30:54 -0500, Phil Hobbs
<pcdhSpamM...@electrooptical.net> wrote:

>On 03/01/2017 10:18 AM, John Larkin wrote:
>> On Wed, 1 Mar 2017 06:00:12 -0800 (PST), pcdh...@gmail.com wrote:
>>
>>>> But LT Spice doesn't calculate input referred noise.
>>>
>>> Sure it does--INOISE is just V(ONOISE)/GAIN.
>>
>> I can do that. How do I get Spice to do that?
>>
>> And GAIN is not a number, it's a function of frequency.
>>
>> My circuit is a transconductance amp, so GAIN is in ohms.
>>
>>
>
>Select the plot window, go ctl-A and type "inoise" into the dialogue box.
>
>Cheers
>
>Phil Hobbs

OK, tried that. It shows V(inoise) as bigger than V(onoise), both in
units of volts; my named input is a current source. The circuit has a
gain of 3, 150 ohms Gm, so that makes no sense.

Hey, this is fun. I went to "edit simulation command" for noise and
entered

V(AMP) as the output and

I(Ipd) as the input.

That made the thing go bezerk and made nonsense out of the sim
parameters. Yes, it should have been V(AMP) and Ipd.

This is what it did to my setup:

https://dl.dropboxusercontent.com/u/53724080/Spice/Noise_Sim.jpg

This is the second time I managed to tie LT Spice in knots by entering
an incorrect expression. Last time, I crashed it with mismatched
parentheses, and Mike fixed it.


I can name a power supply as the input noise source, and it calculates
my output noise as usual. If I then do the ctrl/A thing, I get a very
weird input noise graph, a huge noise floor and a giant spike about 16
MHz.

I think I'll ignore the input noise thing. I have to name some source
to get it to run, but apparently I can name anything. The calculated
output noise does seem to make sense.

[John Larkin]

That is nice. TI is doing good linears lately.

My fave gumdrop is now OPA197. Cheaper than LM7301 and better.

[Phil Hobbs]

On 03/01/2017 11:47 AM, John Larkin wrote:
> On Wed, 1 Mar 2017 10:30:54 -0500, Phil Hobbs
> <pcdhSpamM...@electrooptical.net> wrote:
>
>> On 03/01/2017 10:18 AM, John Larkin wrote:
>>> On Wed, 1 Mar 2017 06:00:12 -0800 (PST), pcdh...@gmail.com wrote:
>>>
>>>>> But LT Spice doesn't calculate input referred noise.
>>>>
>>>> Sure it does--INOISE is just V(ONOISE)/GAIN.
>>>
>>> I can do that. How do I get Spice to do that?
>>>
>>> And GAIN is not a number, it's a function of frequency.
>>>
>>> My circuit is a transconductance amp, so GAIN is in ohms.
>>>
>>>
>>
>> Select the plot window, go ctl-A and type "inoise" into the dialogue box.
>>
>> Cheers
>>
>> Phil Hobbs
>
> OK, tried that. It shows V(inoise) as bigger than V(onoise), both in
> units of volts; my named input is a current source. The circuit has a
> gain of 3, 150 ohms Gm, so that makes no sense.
>
> Hey, this is fun. I went to "edit simulation command" for noise and
> entered
>
> V(AMP) as the output and
>
> I(Ipd) as the input.
>
> That made the thing go bezerk and made nonsense out of the sim
> parameters. Yes, it should have been V(AMP) and Ipd.

Sure, the parser isn't very smart--it bumps you down to the next field
when it gets confused.

>
> This is what it did to my setup:
>
> https://dl.dropboxusercontent.com/u/53724080/Spice/Noise_Sim.jpg
>
> This is the second time I managed to tie LT Spice in knots by entering
> an incorrect expression. Last time, I crashed it with mismatched
> parentheses, and Mike fixed it.
>
>
> I can name a power supply as the input noise source, and it calculates
> my output noise as usual. If I then do the ctrl/A thing, I get a very
> weird input noise graph, a huge noise floor and a giant spike about 16
> MHz.

There's probably a null in the transfer function. I nearly always have
to change the vertical scale or do something like min(inoise, 100f) in
the plot expression (that prevents the autoranging from screwing up the
display when you re-run the sim).

>
> I think I'll ignore the input noise thing. I have to name some source
> to get it to run, but apparently I can name anything. The calculated
> output noise does seem to make sense.

I usually inoise in preference to onoise, because onoise is much harder
to relate to the fundamental physics, which is what I usually care
about. Inoise works fine.

Another nice thing is that LTspice does the right thing when you add
noise contributions. For instance, in a front end with two parallelled
JFETs Q1 and Q2, you can plot V(Q1)+V(Q2) and it comes out sqrt(2) times
larger than just V(Q1) instead of doubled.

[Phil Hobbs]

Nice. 36V CMOS RRIO, reasonable noise, 70 cents. Drift fairly putrid,
but not out of line.

[Jim Thompson]

On Wed, 1 Mar 2017 10:20:09 -0500, Phil Hobbs
<pcdhSpamM...@electrooptical.net> wrote:

>On 03/01/2017 09:58 AM, Jim Thompson wrote:
>> On Wed, 1 Mar 2017 06:26:23 -0800 (PST), pcdh...@gmail.com wrote:
>>
>>>> Take it up with Berkeley... the method has never changed... all
>>>> these years.
>>>
>>> And (AFAIK) all the copies and rewrites do it too. It's still a
>>> wart--numerical methods have come a long way since 1970, except in
>>> circuit design.
>>>
>>>> It's not like "over and over" is a big deal... noise/AC analysis
>>>> occurs about as fast as you can blink.
>>>
>>> With discrete circuits, usually so. However, lots of IC models
>>> *cough* TI op amps *cough* have ugly convergence issues even with
>>> ".savebias internal", so waiting needlessly for that 50 times is
>>> annoying.
>
>>
>> Take it up with TI and LTspice... LTspice had a lot of convergence
>> issues with analog parts that other simulators don't.
>
>Nah, ragging you is way more entertaining.

I know >:-}

>
>I recall your having trouble with the OPA140 in PSPICE as well. And of
>course LTspice's price is right.

I know how to model such creatures now, but have very little time to
"play"... suddenly got busy :-)

>
>>
>> (Also, You should read up on that important tool .STEP. You should
>> be able to do component stepping within a single run... minimizing
>> the bias recalculation.)
>
>I use .step fairly often, but in LTspice it doesn't fix the bias issues.
> Changing resistors or voltages makes the bias different on each run.
>
>Using .step to flip switches (nice infinitely differentiable ones) to
>connect INOISE to different places in the circuit shouldn't make the
>bias move, but for some reason with models like TI's OPA140 LTspice
>doesn't skip the entire bias calculation even with .savebias internal.
>(Super nice op amp, super crappy model.)
>
>Cheers
>
>Phil Hobbs

Face it, LTspice is not that wonderful for lots of analog stuff. But
I'm back into painful land... having to use Cadence Virtuoso for a
customer... almost as bad a schematic entry as LTspice :-(

[pcdh...@gmail.com]

> Face it, LTspice is not that wonderful for lots of analog stuff. But
> I'm back into painful land... having to use Cadence Virtuoso for a
> customer... almost as bad a schematic entry as LTspice :-(

Spice in general isn't that wonderful if you don't have foundry models. It's good enough to be useful, at least for discrete designs and LTC switchers, and it produces pictures for customers to show to their bosses and for posting on SED. Fortunately most of the stuff I need to simulate is discrete.

Cheers

Phil Hobbs

[Jim Thompson]

And I have foundry models... this latest job is UMC, 150nm ;-)

[pcdh...@gmail.com]

>And I have foundry models... this latest job is UMC, 150nm ;-)

You can do 150 nm litho with a crayon.

Cheers

Phil Hobbs

[Jim Thompson]

150 NANO-meters ??

[Phil Hobbs]

On 03/02/2017 09:54 AM, Jim Thompson wrote:
> On Thu, 2 Mar 2017 05:10:59 -0800 (PST), pcdh...@gmail.com wrote:
>
>>> And I have foundry models... this latest job is UMC, 150nm ;-)
>>
>> You can do 150 nm litho with a crayon.
>>
>> Cheers
>>
>> Phil Hobbs
>
> 150 NANO-meters ??
>
> ...Jim Thompson
>

Last process I worked on was 22nm, and that makes me a grandpa. ;)

My nanoantennas were made on a 30-nm Leica e-beam writer, and that was
getting on for a decade ago now.

[Kevin Aylward]

"Jim Thompson" wrote in message
news:eo5fbcttk8n43vjrr...@4ax.com...

>> >
>> >I use .step fairly often, but in LTspice it doesn't fix the bias issues.
>> > Changing resistors or voltages makes the bias different on each run.
>> >
>> >Using .step to flip switches (nice infinitely differentiable ones) to
>> >connect INOISE to different places in the circuit shouldn't make the
>> >bias move, but for some reason with models like TI's OPA140 LTspice
>> >doesn't skip the entire bias calculation even with .savebias internal.
>> >(Super nice op amp, super crappy model.)
>
>>
>> Face it, LTspice is not that wonderful for lots of analog stuff. But
>> I'm back into painful land... having to use Cadence Virtuoso for a
>> customer... almost as bad a schematic entry as LTspice :-(

Actually, I really like the Cadence schematic capture. LTSpice is not even
in the same universe :-)

>
>>Spice in general isn't that wonderful if you don't have foundry models.
>>It's good enough to be useful, at least for discrete designs and LTC
>>switchers, and it produces pictures for customers to >show to their bosses
>>and for posting on SED. Fortunately most of the stuff I need to simulate
>>is discrete.

>And I have foundry models... this latest job is UMC, 150nm ;-)

Yeah, it is a real problem without good foundry models.

I have collected quite a few sets now for all the processes I have used in
my day job. Not something I can pass out with SS though.


-- Kevin Aylward
http://www.anasoft.co.uk - SuperSpice
http://www.kevinaylward.co.uk/ee/index.html

[John Larkin]

On Thu, 2 Mar 2017 05:10:59 -0800 (PST), pcdh...@gmail.com wrote:

That's not so. You need rubylith and x-acto knives at 150 nm.

--

John Larkin Highland Technology, Inc

[Jim Thompson]

On Thu, 2 Mar 2017 16:26:52 -0500, Phil Hobbs
<pcdhSpamM...@electrooptical.net> wrote:

>On 03/02/2017 09:54 AM, Jim Thompson wrote:
>> On Thu, 2 Mar 2017 05:10:59 -0800 (PST), pcdh...@gmail.com wrote:
>>
>>>> And I have foundry models... this latest job is UMC, 150nm ;-)
>>>
>>> You can do 150 nm litho with a crayon.
>>>
>>> Cheers
>>>
>>> Phil Hobbs
>>
>> 150 NANO-meters ??
>>
>> ...Jim Thompson
>>
>Last process I worked on was 22nm, and that makes me a grandpa. ;)
>
>My nanoantennas were made on a 30-nm Leica e-beam writer, and that was
>getting on for a decade ago now.
>
>Cheers
>
>Phil Hobbs

Small feature size is useless for precision Analog... VOS =
12/sqrt(W*L) (for my current process), so it goes down when area goes
up.

[Jim Thompson]

On Thu, 2 Mar 2017 21:45:04 -0000, "Kevin Aylward"
<kevinR...@kevinaylward.co.uk> wrote:

>"Jim Thompson" wrote in message
>news:eo5fbcttk8n43vjrr...@4ax.com...
>
>
>>> >
>>> >I use .step fairly often, but in LTspice it doesn't fix the bias issues.
>>> > Changing resistors or voltages makes the bias different on each run.
>>> >
>>> >Using .step to flip switches (nice infinitely differentiable ones) to
>>> >connect INOISE to different places in the circuit shouldn't make the
>>> >bias move, but for some reason with models like TI's OPA140 LTspice
>>> >doesn't skip the entire bias calculation even with .savebias internal.
>>> >(Super nice op amp, super crappy model.)
>>
>>>
>>> Face it, LTspice is not that wonderful for lots of analog stuff. But
>>> I'm back into painful land... having to use Cadence Virtuoso for a
>>> customer... almost as bad a schematic entry as LTspice :-(
>
>Actually, I really like the Cadence schematic capture. LTSpice is not even
>in the same universe :-)

I'll have to check the version number tomorrow, but not nearly as bad
as what I had to use 2 years ago.

>
>>
>>>Spice in general isn't that wonderful if you don't have foundry models.
>>>It's good enough to be useful, at least for discrete designs and LTC
>>>switchers, and it produces pictures for customers to >show to their bosses
>>>and for posting on SED. Fortunately most of the stuff I need to simulate
>>>is discrete.
>
>>And I have foundry models... this latest job is UMC, 150nm ;-)
>
>Yeah, it is a real problem without good foundry models.
>
>I have collected quite a few sets now for all the processes I have used in
>my day job. Not something I can pass out with SS though.

Same here. I have literally libraries for at least 60 process
variations.

>
>
>-- Kevin Aylward
>http://www.anasoft.co.uk - SuperSpice
>http://www.kevinaylward.co.uk/ee/index.html

[Jim Thompson]

On Thu, 02 Mar 2017 18:41:03 -0700, Jim Thompson
<To-Email-Use-Th...@On-My-Web-Site.com> wrote:

>On Thu, 2 Mar 2017 16:26:52 -0500, Phil Hobbs
><pcdhSpamM...@electrooptical.net> wrote:
>
>>On 03/02/2017 09:54 AM, Jim Thompson wrote:
>>> On Thu, 2 Mar 2017 05:10:59 -0800 (PST), pcdh...@gmail.com wrote:
>>>
>>>>> And I have foundry models... this latest job is UMC, 150nm ;-)
>>>>
>>>> You can do 150 nm litho with a crayon.
>>>>
>>>> Cheers
>>>>
>>>> Phil Hobbs
>>>
>>> 150 NANO-meters ??
>>>
>>> ...Jim Thompson
>>>
>>Last process I worked on was 22nm, and that makes me a grandpa. ;)
>>
>>My nanoantennas were made on a 30-nm Leica e-beam writer, and that was
>>getting on for a decade ago now.
>>
>>Cheers
>>
>>Phil Hobbs
>
>Small feature size is useless for precision Analog... VOS =
>12/sqrt(W*L) (for my current process), so it goes down when area goes
>up.
>
> ...Jim Thompson

Dimensions are mv/um ;-)

[pcdh...@gmail.com]

>>> 150 NANO-meters ??

>>>                 
>>>                                        
>>Last process I worked on was 22nm, and that makes me a grandpa. ;)
>

>>My nanoantennas were made on a 30-nm Leica ebeam writer, and that was

>>getting on for a decade ago now.
>

>Small feature size is useless for precision Analog... VOS =
>12/sqrt(W*L) (for my current process), so it goes down when area goes
>up.

Transistors stopped getting better at about the 65 nm node. Now the game is to use more transistors to counteract the dopant atom statistics (which is probably what makes Vos hard to control). At 7nm, even logic levels aren't that easy to control.

;)

Cheers

Phil Hobbs

[Kevin Aylward]

"Jim Thompson" wrote in message

news:3aihbcllbvsfkm1od...@4ax.com...

On Thu, 2 Mar 2017 16:26:52 -0500, Phil Hobbs
<pcdhSpamM...@electrooptical.net> wrote:

>On 03/02/2017 09:54 AM, Jim Thompson wrote:
>> On Thu, 2 Mar 2017 05:10:59 -0800 (PST), pcdh...@gmail.com wrote:
>>
>>>> And I have foundry models... this latest job is UMC, 150nm ;-)
>>>
>>> You can do 150 nm litho with a crayon.
>>>
>>> Cheers
>>>
>>> Phil Hobbs
>>
>> 150 NANO-meters ??
>>
>> ...Jim Thompson
>>
>Last process I worked on was 22nm, and that makes me a grandpa. ;)
>
>My nanoantennas were made on a 30-nm Leica e-beam writer, and that was
>getting on for a decade ago now.
>
>Cheers
>
>Phil Hobbs

>Small feature size is useless for precision Analog... VOS =
>12/sqrt(W*L) (for my current process), so it goes down when area goes
>up.

Exactly. Also, 1/f noise does the same.

Currently using 0u18 process and I rarely use less than about 1u gate length
for the analog bits. Typically, I use 0.18u for things like the output
device of an LDO, where it don't matter, and you want it to be small as
possible.

[Kevin Aylward]

"Jim Thompson" wrote in message

news:3eihbclmf89nltv6b...@4ax.com...

>
>>
>>>Spice in general isn't that wonderful if you don't have foundry models.
>>>It's good enough to be useful, at least for discrete designs and LTC
>>>switchers, and it produces pictures for customers to >show to their
>>>bosses
>>>and for posting on SED. Fortunately most of the stuff I need to simulate
>>>is discrete.
>
>>And I have foundry models... this latest job is UMC, 150nm ;-)
>
>Yeah, it is a real problem without good foundry models.
>
>I have collected quite a few sets now for all the processes I have used in
>my day job. Not something I can pass out with SS though.

>Same here. I have literally libraries for at least 60 process
>variations.

I did notice something a bit strange with the LT user licence. It only
prohibits use by "...semiconductor manufactures..." .

This seems a bit of a cockup on their part. Surely one would expect that
they would prohibit fabless semiconductor companies or individuals using it
to design competing chips, much as what you are now at liberty to do :-)

[Jim Thompson]

On Fri, 3 Mar 2017 14:51:37 -0000, "Kevin Aylward"
<kevinR...@kevinaylward.co.uk> wrote:

[snip]

>
>I did notice something a bit strange with the LT user licence. It only
>prohibits use by "...semiconductor manufactures..." .
>
>This seems a bit of a cockup on their part. Surely one would expect that
>they would prohibit fabless semiconductor companies or individuals using it
>to design competing chips, much as what you are now at liberty to do :-)
>
>
>-- Kevin Aylward
>http://www.anasoft.co.uk - SuperSpice
>http://www.kevinaylward.co.uk/ee/index.html

Legal disclaimer... personal opinion follows...

LT management must have their heads up their ass... more and more of
their models will run ONLY on LTspice, some because of encryption,
some because of proprietary functions not found in any other Spice
variant.

I guess they figure to sell only to amateurs ?>:-}

[Kevin Aylward]

"Jim Thompson" wrote in message

news:9c3jbcpcn0mrtlumc...@4ax.com...

On Fri, 3 Mar 2017 14:51:37 -0000, "Kevin Aylward"
<kevinR...@kevinaylward.co.uk> wrote:

[snip]
>
>I did notice something a bit strange with the LT user licence. It only
>prohibits use by "...semiconductor manufactures..." .
>
>>This seems a bit of a cockup on their part. Surely one would expect that
>>they would prohibit fabless semiconductor companies or individuals using
>>it
>>to design competing chips, much as what you are now at liberty to do :-)
>
>

Legal disclaimer... personal opinion follows...

>LT management must have their heads up their ass... more and more of
>their models will run ONLY on LTspice, some because of encryption,
>some because of proprietary functions not found in any other Spice
>variant.

Agreed.

[Gerhard Hoffmann]

Am 03.03.2017 um 21:28 schrieb Kevin Aylward:
> "Jim Thompson" wrote in message

>

> Legal disclaimer... personal opinion follows...
>
>> LT management must have their heads up their ass... more and more of
>> their models will run ONLY on LTspice, some because of encryption,
>> some because of proprietary functions not found in any other Spice
>> variant.
>
> Agreed.

As much as I like LTspice, and I use it a lot, methinks in the long run
we do ourselves a disservice with it.

Everybody attaches a small rucksack to the original Spice, renames it
somewhat and then sleeps on it like the dragon on his pile of gold.
And no one but LT makes any impact in user land, no one gets rich, and
no one can collect the good ideas and can concentrate them in one open
version so the next bright guy can build upon that.

LTspice leeches the blood out of any other development.

Maybe I should move on to NGspice or Xspice or QUCS, as an investment
into the future.

There is enough to do: s-parameters, large signal noise analysis,
contemporary transistor models, electromagnetics, strip lines,
harmonic balance, functional blocks, using CUDA etc. There is so
much that AWR, Genesys, ADS & friends can do and that Spice cannot.

have a good night,
Gerhard

[Kevin Aylward]

"Gerhard Hoffmann" wrote in message
news:ehukgk...@mid.individual.net...

Am 03.03.2017 um 21:28 schrieb Kevin Aylward:
> "Jim Thompson" wrote in message

>
> Legal disclaimer... personal opinion follows...
>
>>> LT management must have their heads up their ass... more and more of
>>> their models will run ONLY on LTspice, some because of encryption,
>>> some because of proprietary functions not found in any other Spice
>>> variant.
>
>> Agreed.

>As much as I like LTspice, and I use it a lot, methinks in the long run
>we do ourselves a disservice with it.

>Everybody attaches a small rucksack to the original Spice, renames it
>somewhat and then sleeps on it like the dragon on his pile of gold.
>And no one but LT makes any impact in user land, no one gets rich, and
>no one can collect the good ideas and can concentrate them in one open
>version so the next bright guy can build upon that.

>LTspice leeches the blood out of any other development.

I agree. There is next to no incentive for any company to develop a spice
for non ic design applications.

>Maybe I should move on to NGspice or Xspice or QUCS, as an investment
>into the future.

NGSpice is a very good choice. It includes XSpice anyway. Its got quite a
lot of good new stuff. There are even smutterings of adding PSS.

I wrote SS to give me personally, in part, affordable ic design features.
Worst Case corner support on its own, for me, is justification to never use
LTSpice. Nothing I do has any meaning without ensuring it will work over all
process corners.

As far as development in XSpice, if anyone wants my MS VC++ full code of my
XSpice version for free, just ask. I consider my value added is my GUI.

[John Devereux]

I believe KiCad now integrates NGSpice.

> I wrote SS to give me personally, in part, affordable ic design
> features. Worst Case corner support on its own, for me, is
> justification to never use LTSpice. Nothing I do has any meaning
> without ensuring it will work over all process corners.
>
> As far as development in XSpice, if anyone wants my MS VC++ full code
> of my XSpice version for free, just ask. I consider my value added is
> my GUI.
>
> -- Kevin Aylward
> http://www.anasoft.co.uk - SuperSpice
> http://www.kevinaylward.co.uk/ee/index.html
>

--

John Devereux

[Cursitor Doom]

On Sat, 04 Mar 2017 09:23:27 +0000, Kevin Aylward wrote:

> As far as development in XSpice, if anyone wants my MS VC++ full code of
> my XSpice version for free, just ask. I consider my value added is my
> GUI.

That's my main bitch about LTSpice: the GUI. The circuits look butt-ugly
IMO. I did test a lot of other flavours of Spice out back in the day and
they nearly ALL had much nicer user interfaces than LT; some really
pretty. Still, you can't complain too much about something that works
pretty damn well and costs nothing!