LT Spice .PARAM

[John Larkin]

If I say

.PARAM RR=50 MX=20 RD=5000/(1.000001-1/MX)

it executes from left to right.

But what if I have multiple .PARAM statements, and one calculates a
value that another one uses. What order are they executed in?




--

John Larkin Highland Technology, Inc
picosecond timing precision measurement

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

[Lasse Langwadt Christensen]

Den fredag den 26. juni 2015 kl. 02.04.29 UTC+2 skrev John Larkin:
> If I say
>
> .PARAM RR=50 MX=20 RD=5000/(1.000001-1/MX)
>
> it executes from left to right.
>
> But what if I have multiple .PARAM statements, and one calculates a
> value that another one uses. What order are they executed in?
>

does it matter?, isn't everything just expanded and substituted or what
ever you want to call it?

-Lasse

[Jim Thompson]

On Thu, 25 Jun 2015 17:21:17 -0700 (PDT), Lasse Langwadt Christensen
<lang...@fonz.dk> wrote:


>> If I say
>>
>> .PARAM RR=50 MX=20 RD=5000/(1.000001-1/MX)
>>
>> it executes from left to right.
>>
>> But what if I have multiple .PARAM statements, and one calculates a
>> value that another one uses. What order are they executed in?
>>
>
>does it matter?, isn't everything just expanded and substituted or what
>ever you want to call it?
>
>-Lasse

Yes.

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

I love to cook with wine. Sometimes I even put it in the food.

[John Larkin]

On Thu, 25 Jun 2015 17:21:17 -0700 (PDT), Lasse Langwadt Christensen
<lang...@fonz.dk> wrote:

Well, I could do

.PARAM KK=4

.PARAM JJ=KK/7

.PARAM KK=14*(KK+MM)

so the order matters.

[Lasse Langwadt Christensen]

Den fredag den 26. juni 2015 kl. 02.37.32 UTC+2 skrev John Larkin:
> On Thu, 25 Jun 2015 17:21:17 -0700 (PDT), Lasse Langwadt Christensen
> <lang...@fonz.dk> wrote:
>
> >Den fredag den 26. juni 2015 kl. 02.04.29 UTC+2 skrev John Larkin:
> >> If I say
> >>
> >> .PARAM RR=50 MX=20 RD=5000/(1.000001-1/MX)
> >>
> >> it executes from left to right.
> >>
> >> But what if I have multiple .PARAM statements, and one calculates a
> >> value that another one uses. What order are they executed in?
> >>
> >
> >does it matter?, isn't everything just expanded and substituted or what
> >ever you want to call it?
> >
> >-Lasse
>
> Well, I could do
>
> .PARAM KK=4
>
> .PARAM JJ=KK/7
>
> .PARAM KK=14*(KK+MM)
>
> so the order matters.
>

I doubt that KK can be two values at the same time or depend on itself

-Lasse

[Jim Thompson]

On Thu, 25 Jun 2015 17:49:02 -0700 (PDT), Lasse Langwadt Christensen
<lang...@fonz.dk> wrote:

[snip]

>> >
>> >does it matter?, isn't everything just expanded and substituted or what
>> >ever you want to call it?
>> >
>> >-Lasse
>>
>> Well, I could do
>>
>> .PARAM KK=4
>>
>> .PARAM JJ=KK/7
>>
>> .PARAM KK=14*(KK+MM)
>>
>> so the order matters.
>>
>
>I doubt that KK can be two values at the same time or depend on itself
>
>-Lasse

No >:-}

And PARAMS don't execute from left to right like certain programming
languages... it's all Algebra... x=4 y=6 is the same as y=6 x=4

[rickman]

On 6/25/2015 8:37 PM, John Larkin wrote:
> On Thu, 25 Jun 2015 17:21:17 -0700 (PDT), Lasse Langwadt Christensen
> <lang...@fonz.dk> wrote:
>
>> Den fredag den 26. juni 2015 kl. 02.04.29 UTC+2 skrev John Larkin:
>>> If I say
>>>
>>> .PARAM RR=50 MX=20 RD=5000/(1.000001-1/MX)
>>>
>>> it executes from left to right.
>>>
>>> But what if I have multiple .PARAM statements, and one calculates a
>>> value that another one uses. What order are they executed in?
>>>
>>
>> does it matter?, isn't everything just expanded and substituted or what
>> ever you want to call it?
>>
>> -Lasse
>
> Well, I could do
>

> ..PARAM KK=4
>
> ..PARAM JJ=KK/7
>
> ..PARAM KK=14*(KK+MM)
>
> so the order matters.

Uh, can you? No only is this very easy to test... after all, LTspice
*is* a simulator, it has a dedicated support group that can be searched.

--

Rick

[John Larkin]

On Thu, 25 Jun 2015 17:49:02 -0700 (PDT), Lasse Langwadt Christensen

<lang...@fonz.dk> wrote:

>Den fredag den 26. juni 2015 kl. 02.37.32 UTC+2 skrev John Larkin:
>> On Thu, 25 Jun 2015 17:21:17 -0700 (PDT), Lasse Langwadt Christensen
>> <lang...@fonz.dk> wrote:
>>
>> >Den fredag den 26. juni 2015 kl. 02.04.29 UTC+2 skrev John Larkin:
>> >> If I say
>> >>
>> >> .PARAM RR=50 MX=20 RD=5000/(1.000001-1/MX)
>> >>
>> >> it executes from left to right.
>> >>
>> >> But what if I have multiple .PARAM statements, and one calculates a
>> >> value that another one uses. What order are they executed in?
>> >>
>> >
>> >does it matter?, isn't everything just expanded and substituted or what
>> >ever you want to call it?
>> >
>> >-Lasse
>>
>> Well, I could do
>>
>> .PARAM KK=4
>>
>> .PARAM JJ=KK/7
>>
>> .PARAM KK=14*(KK+MM)
>>
>> so the order matters.
>>
>
>I doubt that KK can be two values at the same time or depend on itself
>
>-Lasse

I can certainly do those equations in c or any other procedural
language, but in c the order of execution is obvious.

I assume that LT Spice compiles those expressions and executes them
often. Since I can include a node voltage or current in an expression,
it has to evaluate such equations every sim tick. It might be smart
enough to execute invariant expressions just once at startup.

I can also make a chain of behavioral voltage sources with equations
that depend on one another, and the order in which they are executed
could matter.

Some interesting experiments are suggested. I was just hoping that
someone here knew about this issue.

--

John Larkin Highland Technology, Inc

picosecond timing laser drivers and controllers

[RBlack]

On Thu, 25 Jun 2015 17:37:26 -0700, John Larkin
(jla...@highlandtechnology.com) said:
> On Thu, 25 Jun 2015 17:21:17 -0700 (PDT), Lasse Langwadt Christensen
> <lang...@fonz.dk> wrote:
>
> >Den fredag den 26. juni 2015 kl. 02.04.29 UTC+2 skrev John Larkin:
> >> If I say
> >>
> >> .PARAM RR=50 MX=20 RD=5000/(1.000001-1/MX)
> >>
> >> it executes from left to right.
> >>
> >> But what if I have multiple .PARAM statements, and one calculates a
> >> value that another one uses. What order are they executed in?
> >>
> >
> >does it matter?, isn't everything just expanded and substituted or what
> >ever you want to call it?
> >
> >-Lasse
>
> Well, I could do
>
> .PARAM KK=4
>
> .PARAM JJ=KK/7
>
> .PARAM KK=14*(KK+MM)
>
> so the order matters.
>

I had a similar question - if you have several nested .step parameters
(there is a hard limit of 3 layers of nesting IIRC), how is the order of
the nesting controlled?

This matters particularly if you are doing a .op analysis with stepped
parameters, because the .step parameter in the innermost loop is the one
that gets used for the horizontal axis of the plots.
If the order was wrong, nothing I did in the schematic editor seemed to
make any difference. As a last resort I opened the .asc in a text
editor and reversed the order of the .step statements. Bingo!

So the answer is that the .param's are executed in the order in which
you first added them to the schematic. This doesn't seem to be
documented anywhere AFAICT.

[Phil Hobbs]

That does sound interesting. Given Spice's card deck roots, it would be
odd if such order-dependent stuff weren't done in file order as RBlack
said. As the programmer, what else would you do?

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 Fri, 26 Jun 2015 07:38:59 -0400, Phil Hobbs
<pcdhSpamM...@electrooptical.net> wrote:

[snip]

>
>Given Spice's card deck roots, it would be
>odd if such order-dependent stuff weren't done in file order as RBlack
>said. As the programmer, what else would you do?
>
>Cheers
>
>Phil Hobbs

Nope. Read _any_ Spice variant's help file... the _whole_ deck is
read-in, _then_ parsed. PARAM order does not matter _even_ when one
parameter is a function of another... of course circular references
are a no-no >:-}

[Phil Hobbs]

On 6/26/2015 9:23 AM, Jim Thompson wrote:
> On Fri, 26 Jun 2015 07:38:59 -0400, Phil Hobbs
> <pcdhSpamM...@electrooptical.net> wrote:
>
> [snip]
>>
>> Given Spice's card deck roots, it would be
>> odd if such order-dependent stuff weren't done in file order as RBlack
>> said. As the programmer, what else would you do?
>>
>> Cheers
>>
>> Phil Hobbs
>
> Nope. Read _any_ Spice variant's help file... the _whole_ deck is
> read-in, _then_ parsed. PARAM order does not matter _even_ when one
> parameter is a function of another... of course circular references
> are a no-no >:-}

That doesn't prove anything. Every compiler in the universe does the
same thing, regardless of its semantics.

[Jim Thompson]

On Fri, 26 Jun 2015 09:31:50 -0400, Phil Hobbs

<pcdhSpamM...@electrooptical.net> wrote:

>On 6/26/2015 9:23 AM, Jim Thompson wrote:
>> On Fri, 26 Jun 2015 07:38:59 -0400, Phil Hobbs
>> <pcdhSpamM...@electrooptical.net> wrote:
>>
>> [snip]
>>>
>>> Given Spice's card deck roots, it would be
>>> odd if such order-dependent stuff weren't done in file order as RBlack
>>> said. As the programmer, what else would you do?
>>>
>>> Cheers
>>>
>>> Phil Hobbs
>>
>> Nope. Read _any_ Spice variant's help file... the _whole_ deck is
>> read-in, _then_ parsed. PARAM order does not matter _even_ when one
>> parameter is a function of another... of course circular references
>> are a no-no >:-}
>
>That doesn't prove anything. Every compiler in the universe does the
>same thing, regardless of its semantics.
>
>Cheers
>
>Phil Hobbs

Confusion. I thought you were saying PARAM order mattered? It
doesn't in any Spice variant I know of.

[John Larkin]

On Fri, 26 Jun 2015 07:38:59 -0400, Phil Hobbs
<pcdhSpamM...@electrooptical.net> wrote:

It looks like Spice tries to avoid procedural dependencies

.PARAM A=4
.PARAM A=A+1

throws an immediate "duplicate definitions" error.

But you can force procedural paradoxes that outsmart the compiler, and
they tend to produce runtime errors, like never finding the DC
solution, or crashing with singular matrices or something. At any
rate, it doesn't like procedural coding. I haven't time to really
explore it, but it could be that it doesn't control execution order at
all, and tries to not care.

I suppose it does compile .PARAMs, for speed. Hell of a piece of
software.

[John Larkin]

On Fri, 26 Jun 2015 09:50:47 +0100, RBlack <ne...@rblack01.plus.com>
wrote:

That would make sense. And looking at the netlist would let me see
what the actual order is and, as you note, change it.

--

John Larkin Highland Technology, Inc

picosecond timing laser drivers and controllers

[Syd Rumpo]

On 26/06/2015 14:57, John Larkin wrote:

<snip>

>> So the answer is that the .param's are executed in the order in which
>> you first added them to the schematic. This doesn't seem to be
>> documented anywhere AFAICT.
>
> That would make sense. And looking at the netlist would let me see
> what the actual order is and, as you note, change it.

Put them all together on multiple lines in one 'box' and they'll happen
in order.

Cheers
--
Syd

[DecadentLinuxUserNumeroUno]

On Fri, 26 Jun 2015 06:57:17 -0700, John Larkin
<jla...@highlandtechnology.com> Gave us:

They are not executed. They are assigned. That is why a "duplicate"
error occurs if you try to make one. Duh. The assigned param name can
include some execution elements, but only one param name can be named
for each named param derivation.

[John Larkin]

On Fri, 26 Jun 2015 15:26:13 +0100, Syd Rumpo <use...@nononono.co.uk>
wrote:

OK, that suggests left-to-right execution within one line, with the
compiler trying to check (throw errors) to make sure it doesn't
matter. The compiler can try to force the order of .PARAMs to not
matter, but as RB notes, some things do matter.

[John Larkin]

Expressions can contain the realtime values of node voltages or
currents, so they have to be executed. Could be that .PARAM
expressions are executed once, at the start of a sim, but some
equations, like for B devices, have to be executed every tick.

You sounded almost intelligent and almost helpful there for a second,
until you said "Duh." You are determined to be disliked, and you do it
well.

[Lasse Langwadt Christensen]

Den fredag den 26. juni 2015 kl. 16.36.43 UTC+2 skrev John Larkin:
> On Fri, 26 Jun 2015 15:26:13 +0100, Syd Rumpo <use...@nononono.co.uk>
> wrote:
>
> >On 26/06/2015 14:57, John Larkin wrote:
> >
> ><snip>
> >
> >>> So the answer is that the .param's are executed in the order in which
> >>> you first added them to the schematic. This doesn't seem to be
> >>> documented anywhere AFAICT.
> >>
> >> That would make sense. And looking at the netlist would let me see
> >> what the actual order is and, as you note, change it.
> >
> >Put them all together on multiple lines in one 'box' and they'll happen
> >in order.
> >
> >Cheers
>
> OK, that suggests left-to-right execution within one line, with the
> compiler trying to check (throw errors) to make sure it doesn't
> matter. The compiler can try to force the order of .PARAMs to not
> matter, but as RB notes, some things do matter.
>

spice isn't supposed to be programming it is hardware description, everything
need to be expanded and run every time something changes, sometimes that is at startup, sometimes at every time step

.step is different it'll just tell it to run a number of simulations with different settings, order might screw up the plot axis but the data should
still be that same

-Lasse

[Martin Brown]

On 26/06/2015 14:31, Phil Hobbs wrote:
> On 6/26/2015 9:23 AM, Jim Thompson wrote:
>> On Fri, 26 Jun 2015 07:38:59 -0400, Phil Hobbs
>> <pcdhSpamM...@electrooptical.net> wrote:
>>
>> [snip]
>>>
>>> Given Spice's card deck roots, it would be
>>> odd if such order-dependent stuff weren't done in file order as RBlack
>>> said. As the programmer, what else would you do?
>>>
>>> Cheers
>>>
>>> Phil Hobbs
>>
>> Nope. Read _any_ Spice variant's help file... the _whole_ deck is
>> read-in, _then_ parsed. PARAM order does not matter _even_ when one
>> parameter is a function of another... of course circular references
>> are a no-no >:-}

I'd be surprised if it will let you use a parameter before it had been
defined but I could be wrong. Experiment will easily show the answer.

> That doesn't prove anything. Every compiler in the universe does the
> same thing, regardless of its semantics.

The critical thing would be if it will let you set the *same* parameter
to two different values (my guess is that it will fault the second
occurrence).

--
Regards,
Martin Brown

[John Larkin]

In an analog circuit, everything happens at the same time. A computer
compiles and executes sequentially, and sometimes that matters. I've
seen digital sims do strange things in LT Spice, too, which might be
dependant on execution order.

.PARAM does resolve netlist forward references properly. Maybe it runs
the entire .PARAM set multiple times until things settle out.

[John Larkin]

.PARAM barfs if you do two assignments to one variable. It does handle
forward references properly.

[Jim Thompson]

On Fri, 26 Jun 2015 15:26:13 +0100, Syd Rumpo <use...@nononono.co.uk>

PARAM's are NOT executed in order... even if one parameter is a
function of another... irrespective of what any "expert" may be
claiming.

RFTM, "PARAMS:" in a subcircuit declaration/instantiation are handled
differently than .PARAM declarations that are in-line.

There are also "functions" (.FUNC) if you want to play >:-}

[Phil Hobbs]

On 6/26/2015 9:45 AM, Jim Thompson wrote:
> On Fri, 26 Jun 2015 09:31:50 -0400, Phil Hobbs
> <pcdhSpamM...@electrooptical.net> wrote:
>
>> On 6/26/2015 9:23 AM, Jim Thompson wrote:
>>> On Fri, 26 Jun 2015 07:38:59 -0400, Phil Hobbs
>>> <pcdhSpamM...@electrooptical.net> wrote:
>>>
>>> [snip]
>>>>
>>>> Given Spice's card deck roots, it would be
>>>> odd if such order-dependent stuff weren't done in file order as RBlack
>>>> said. As the programmer, what else would you do?
>>>>
>>>> Cheers
>>>>
>>>> Phil Hobbs
>>>
>>> Nope. Read _any_ Spice variant's help file... the _whole_ deck is
>>> read-in, _then_ parsed. PARAM order does not matter _even_ when one
>>> parameter is a function of another... of course circular references
>>> are a no-no >:-}
>>
>> That doesn't prove anything. Every compiler in the universe does the
>> same thing, regardless of its semantics.
>>
>> Cheers
>>
>> Phil Hobbs
>
> Confusion. I thought you were saying PARAM order mattered? It
> doesn't in any Spice variant I know of.
>
> ...Jim Thompson
>

We were discussing parameters depending on other parameters, so that you
can have an order dependence.

Plus I'm down on compilers because I've been fighting a _really_stupid_
compiler bug in Visual Studio 2010--assigning a variable to another one
of the same type doesn't yield equal values. I can see it happening as
I single step with the debugger.

[DecadentLinuxUserNumeroUno]

On Fri, 26 Jun 2015 07:44:32 -0700, John Larkin
<jla...@highlandtechnology.com> Gave us:

>You sounded almost intelligent and almost helpful there for a second,

You just couldn't help it could you, you fucking retard.

Spout off about what little you know about *my* intelligence, and I
will quickly iterate your nil capacity for observation, and convoluted
propensity for displaying no intelligence yourself at all. This has
been your problem for decades, child.

You did not "almost make it through". You never had a chance to start
with.

Your bloodline should be erased from the human gene pool as you muddy
it up, putz.

[DecadentLinuxUserNumeroUno]

On Fri, 26 Jun 2015 16:25:19 +0100, Martin Brown

<|||newspam|||@nezumi.demon.co.uk> Gave us:

>The critical thing would be if it will let you set the *same* parameter
>to two different values (my guess is that it will fault the second
>occurrence).

No.. It will error at runtime, because they are treated like a
variable definition, and you cannot have two variables with the same
name and it will NOT make any presumptions or cast out the first in
favor of the last.

[Jim Thompson]

Not in Spice... any order works.

>
>Plus I'm down on compilers because I've been fighting a _really_stupid_
>compiler bug in Visual Studio 2010--assigning a variable to another one
>of the same type doesn't yield equal values. I can see it happening as
>I single step with the debugger.
>
>Cheers
>
>Phil Hobbs

I leave all my programming needs to son Aaron. The only hassles we
have are I insist on a human-friendly GUI... he responds by adding to
his code comments like, "added because Jim Thompson is too lazy..."
;-)

[Jim Thompson]

[snip]

An example of me simulating a bunch of PVT corners in one pass...

<http://www.analog-innovations.com/SED/PARAMs_OutOfOrder_Sample.png>

[rickman]

On 6/26/2015 9:31 AM, Phil Hobbs wrote:
>
> That doesn't prove anything. Every compiler in the universe does the
> same thing, regardless of its semantics.

Are you referring to crashing? ;)

--

Rick

[RBlack]

On Fri, 26 Jun 2015 06:23:19 -0700, Jim Thompson (To-Email-Use-The-
Envelo...@On-My-Web-Site.com) said:
> On Fri, 26 Jun 2015 07:38:59 -0400, Phil Hobbs
> <pcdhSpamM...@electrooptical.net> wrote:
>
> [snip]
> >
> >Given Spice's card deck roots, it would be
> >odd if such order-dependent stuff weren't done in file order as RBlack
> >said. As the programmer, what else would you do?
> >
> >Cheers
> >
> >Phil Hobbs
>
> Nope. Read _any_ Spice variant's help file... the _whole_ deck is
> read-in, _then_ parsed. PARAM order does not matter _even_ when one
> parameter is a function of another... of course circular references
> are a no-no >:-}
>
> ...Jim Thompson

Just to be clear, I'm not suggesting that changing the order of the
.param's would have any effect on the _values_ output by the simulation,
but at least in LTSPICE - I have no experience of any other variants -
it clearly affects the way the results are displayed.

There are undoubtedly better ways of controlling the output that hacking
the .asc in a text editor. I'm slowly working my way through this

<http://www.amazon.com/LTSpice-IV-Simulator-Methods-
Applications/dp/3899292588>

which is the closest I've seen to a printed manual for LTSPICE. Anybody
have any other recommended reading?

[Jeroen Belleman]

On 2015-06-30 09:05, RBlack wrote:
[Snip!]

>
> <http://www.amazon.com/LTSpice-IV-Simulator-Methods-
> Applications/dp/3899292588>
>
> which is the closest I've seen to a printed manual for LTSPICE. Anybody
> have any other recommended reading?
>

Google for 'scad3.pdf'.

Jeroen Belleman

[Phil Hobbs]

>Just to be clear, I'm not suggesting that changing the order of the
>.param's would have any effect on the _values_ output by the simulation,
>but at least in LTSPICE - I have no experience of any other variants -
>it clearly affects the way the results are displayed.

>There are undoubtedly better ways of controlling the output that hacking
>the .asc in a text editor.

I dunno--I routinely hack .asc files, e.g. when I ship them to customers. To make them easy to use, I put all needed models into the .asc, but there's no way to mke them stay hidden on load, so they take up all the screen space and reduce the actual schematic to a postage stamp.

As a workaround, I usually hack the .asc to make all the lines of the models display on top of each other. The resulting black stripe can be puzzling, but enclosing it in a small rectangle and adding a comment is a reasonable solution.

Cheers

Phil "my editor rocks" Hobbs

[John Larkin]

That explains some things!

I like separate include files, all zipped with my .asc. Keeps things
cleaner.

>
>Cheers
>
>Phil "my editor rocks" Hobbs

I use Crimson, but there are fans of EDIT++ around here.

[Phil Hobbs]

>I like separate include files, all zipped with my .asc. Keeps things
>cleaner.

It does if you're always careful to unzip it into an empty directory, but otherwise it makes a mess and can break other things.

I suppose I could mane a custom library, i.e. fancyTIA.asc would load fancyTIA.lib, but that's much more work to keep up.

Cheers

Phil Hobbs

[Jim Thompson]

I've collected a whole series of tutorials and help files in
"LTspiceTutorials.zip " on the Simulation Tools & Macros Page of my
website.