.SENS problem

[Rick &Dick (quizas)]

Hello Xyce team,

I'm trying to use .SENS to analyze the sensitivity of the output voltage to a W of a transistor.:

.sens objfunc={v(out)}  param=mnm12:w 

however, it reported an error as:

Netlist error: Function or variable MNM12:W is not defined

I declare the MNM12 in a subcircuit, and I'm sure I've included this subcircuit file in the main file. I want to know if the Xyce couldn't analyze the param defined in a subcircuit?

Thanks,

rick

[Tom Russo]

You would have to specify the transistor with the full "path" into the subcircuit.  So if mnm12 is inside a subcircuit that's been instantiated as "X1" it would be "X1:mnm12:W", meaning "The transistor MNM12 inside subcircuit instance X1".

[aside to Xyce team:  thinking maybe I would suggest using the "-namesfile" option here, I tried it out only to discover that the namesfile output contains the "spice" mangling of the name rather than the actual name Xyce uses, which may well be a bug.  A user trying to specify a name using the name reported by namesfile might very well be confused.]

--
You received this message because you are subscribed to the Google Groups "xyce-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xyce-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/040c8a84-4a7d-4ee6-a4ee-7784d49808bbn%40googlegroups.com.

--

Tom Russo    KM5VY 
Tijeras, NM 

 echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]

[Tom Russo]

[continuing aside to Xyce team, as it is somewhat unrelated to the original question posted:  -namesfile was originally written for ease of comparison to SPICE, but I have seen over the years that it has been mentioned time and again as a way of figuring out what solution variable names are --- in the case of subcircuiting, the fact that it outputs the spice style name (e.g. "M:X1:foo:variable" instead of "X1:Mfoo:variable") may not be the best choice anymore, given that a Xyce user couldn't just pick a name out of the namesfile and use it in, say, a print statement or whatever, without also knowing that the name is mangled and knowing how to unmangle it.]

[Rick &Dick (quizas)]

Thanks so much， I gonna try later

[Rick &Dick (quizas)]

Hi Tom,

It still doesn't work. I instantiate the subcircuit as follow:

X1 out inp out pd xpd vdda 0  OPAMP1
In subcircuit, I wrote this:

mnm12 net13 net56 vssa vssa nmos1 L=2e-7 W=1e-7

In main file,  I use

.sens objfunc={v(out)} param=x1:mn001:w

to analyze the sensitivity.

However, it still report the same error:

Netlist error: Function or variable X1:MN001:W is not defined

I have no idea about that.

[Tom Russo]

If you're doing exactly what you said in this email, it's because you've called the transistor "mnm12" in the subcircuit, but you're asking for the W parameter of mn001 in the sens line.  It should be X1:mnm12:W.

To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/2061f48d-4504-4d63-854d-add2c8e8c14dn%40googlegroups.com.

[Rick &Dick (quizas)]

Sorry, I called mn001 actually,  I made a mistake in writing.

[Rick &Dick (quizas)]

I finally found the problem：I use -hspice-ext all  when I run my netlist before， and I deleted it， everything works well！

[Tom Russo]

Ah.  That's because "-hspice-ext all" includes enabling "-hspice-ext separator" which changes the subcircuit path separator from ":" to "." to match HSPICE's usage.

With "-hspice-ext all" or "-hspice-ext separator" you'd have to specify "X1.MNM12.W" instead of "X1:MNM12:W"

--

You received this message because you are subscribed to the Google Groups "xyce-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xyce-users+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/9de794d4-c209-4b65-a366-cf70679be913n%40googlegroups.com.

[Rick &Dick (quizas)]

I see， Thanks Tom.  And now I've encountered a few issues：

1. I want to analyze the sensitivity of the PP to param, however, I don't know when the voltage rises highest, so in the .sens line, I use objfunc={MAX v(out)/v(in)}, and it doesn't work. 

2. I use + adjointTimePoints to specify the time points, however, I want to specify a time interval， Are there any methods?

Thanks,

Rick

[xyce-users]

Regarding question 1, the maximum value of a transient signal is an "event-based" objective function. This is a more complicated type of objective function, and the current state of Xyce's sensitivity capability doesn't handle those.   We actually had a paper on this topic a few years ago, but the ideas from that paper aren't in Xyce yet.  See:

 10.1109/ICCAD.2017.8203773

and https://doi.org/10.2172/1761808

This topic came up in another thread recently. There are ways to do some event-based objectives (like max) if you add extra expressions, etc, to the netlist, or can do some extra post-processing.  I'll see if I can find that thread.   You are not the first person to ask about this.

Regarding question 2, you can do adjoint transient sensitivities over the entire transient, or over selected points, or over user-specified range of points.   In the current implementation, every time point you use will require an additional backward integration, and that doesn't scale well when you have large numbers of time points.   There was a paper from a few years ago (not by us) where this expense was mitigated, but I haven't had time to incorporate those ideas into Xyce yet.   Essentially, the motivation for doing sensitivities w.r.t. lots of times points is to compute sensitivities w.r.t. to an objective function that is a function of a window of time, and not just one point.   If this type of objective is formulated properly, then it can be computed via adjoints with just a single reverse integration.  But like I said, that isn't in the code yet.

thanks,

Eric

[xyce-users]

Just to follow up, the other thread about event-based objectives is here:

https://groups.google.com/g/xyce-users/c/d3NoBeYnYGg/m/nTdLJTOCCAAJ

That thread is more interested in computing delay sensitivity, however, rather than a max function.    Delay is also an event-based objective.

Also, to set a range of time points for transient adjoint sensitivities, you can use the parameters ADJOINTBEGINTIME and ADJOINTFINALTIME.    These can be set on the ".options SENSITIVITY" line.  For an example circuit that uses this feature, see the test case:

Xyce_Regression/Netlists/SENS/bsim6invAdjoint.cir

thanks,

Eric

[Rick &Dick (quizas)]

Hi， there

Thank you for your prompt and thorough answers, which helped me solve many problems. However, today I encountered another strange issue:
I added a dc analysis:

.dc dc_v 0 20e-6 1e-7

where dc_v is a param.

And I use

.meas dc iq_0 find PAR('1e6*abs(i(vddd))') at=0

to check the current of node vddd , besides,
.sens objfunc={1e6*abs(i(vddd))} param=XOTA.XI13.MM0.M, XOTA.XI13.MM1.M

is added to analyze the sensitivity of the parameters listed above.

After the simulation, I found 

in the simulation log file, however, in the sensitivity file, it shows:

There are two things I don't understand here: first, for the same expression, the sensitivity analysis yields a different value from the measurement (one is 8.679080e+03 and the other is 1.8006900Be+06), and second, the expression shows a sensitivity of 0 for all parameters.

[xyce-users]

Hmm. That is strange.  Is this a circuit you could share?

You could also check the value by simply putting {1e6*abs(i(vddd))} on the conventional .PRINT line.   I would expect that it would match the .SENS output value(s).  I am guessing this is an issue with .MEASURE.

Also, to double check that this is indeed something that should have a nonzero sensitivity, you could compute them in a brute force manner.  ie, run the circuit twice with 2 different values for one of the params, and compare the difference in {1e6*abs(i(vddd))}.  You wouldn't do this as a long term solution, but it could at least give you evidence that the sensitivities are nonzero.  You can do this from inside the same netlist.  To seen an example of this see the regression circuit Xyce_Regression/Netlists/SENS/diodeTranFD.cir.   That circuit is a reference circuit for the diodeTran.cir test.

thanks,

Eric

[Rick &Dick (quizas)]

Hi, Eric

I added a print:

.print dc {1e6*abs(i(vddd))} 

It shows the same value as  .meas output, not .sens.

When I changed the value of the params, it's sensitivity still stayed 0.

[Rick &Dick (quizas)]

It seems like .sens can't recognize I(vddd),  vddd is a node connected to a voltage source：

 

In the output of  .sens file, It print the voltage value of the vddd, although I use .sens objfunc={I(vddd)}.
Is there any bug ?
Thanks,

Rick

[Rick &Dick (quizas)]

I found the problem, the current source has the same name as the node, which is vddd, so Xyce couldn't tell it, I changed the name of the node, and everything goes well.

[Eugene Zelenko]

Hi!

I think will be good idea if parser will show warnings about such name ambiguities.

Eugene.

[xyce-users]

If the sensitivity code is conflating I(VDDD) with V(VDDD), then you have indeed uncovered a bug.

Many years ago (at least 10), Xyce didn't allow devices and nodes to share names like this.   However, most SPICE-style simulators allow it, so for compatibility we changed it.

In most of the parser, I'm certain this won't cause any problem.  But parsing of expressions (which is where the .SENS objective function is handled) is handled in a different part of Xyce.  The expression library got completely rewritten and replaced a few years ago, and that is where this bug is almost certainly happening.  

Sorry for the inconvenience!  I'll open a bug on this in our internal issue tracker.

thanks,

Eric

[xyce-users]

Here is an update on this issue.  The aspect of .SENS that was conflating I(VDDD) with V(VDDD) was indeed a real bug.   Today, I had some time to work on it and it turned out to be an easy fix.  I've fixed it on our internal git repository, and it will eventually appear in the public git repo.

thanks,

Eric

[Rick &Dick (quizas)]

Thanks for your kind reply, Eric. I got another problem: Can I set the frequency point when I use the adjoint AC sensitivity analysys, just like I set the  adjointTimePoints when I use TRAN adjoint sensitivity analysis?

在2023年10月19日星期四 UTC+8 23:30:46<Rick &Dick (quizas)> 写道：

[xyce-users]

Currently, I don't think so;  the sensitivity analysis will be run for every frequency in the sweep.   But that shouldn't be especially expensive, which was my concern for transient adjoints.

For transient adjoints, it was important to allow the user specify specific time points for the analysis, because each time point requires a unique reverse time integration.  Doing one of these reverse integrations is more efficient than the direct method for large numbers of parameters.   But if you have to do a lot of them (for example, one for every forward time step), it gets really expensive really fast. So expensive, most people wouldn't bother with that calculations.  So, it is important to avoid multiple reverse integrations if you can.

For steady-state analysis like DC and AC,  there really isn't a comparable efficiency issue.   Which is not to say that there are no efficiency issues at all, just not the extreme one caused by multiple reverse time integrations.  Steady state analyses don't require reverse time integrations, as they don't rely in time integrations at all.  So, it never occurred to me to restrict the calculations in that way for those analyses.

Are you seeing efficiency problems with AC adjoints?  Or is this more to keep your outputs manageable?  (perfectly reasonable)

thanks,
Eric

[Rick &Dick (quizas)]

Hi, Eric
Thanks for your kind reply. I got something strange. I use Xyce to simulate a chargepump circuit with TRAN analysis :
.tran 2p 200n 0
and everything goes well. , when I add the sensitivity analysize  like：

.sens objfunc={I(xi0:vupper)} param=xi0:xi40:xnm1:m1:l,xi0:xi40:xnm0:m1:l,.sens objfunc={I(xi0:vupper)} param=xi0:xi40:xnm1:m1:l,xi0:xi40:xnm0:m1:l

.options sensitivity direct=0 adjoint=1 stdoutput=1 .options sensitivity direct=0 adjoint=1 stdoutput=1

.print sens format=csv

.print sens format=csv

It can also work out. I want to get the sens of obj in terms of more params, and I add:

+xi0:xpm3:m1:w,xi0:xpm1:m1:w,xi0:xpm2:m1:w,xi0:xpm4:m1:w
problems happens:

function OneStep::rejectStep:
   Maximum number of failures at time 5.03906e-14
*** Xyce Abort ***
function OneStep::rejectStep:
   Maximum number of failures at time 5.03906e-14

Is it a problem about solver? Can I eliminate it by set some solve settings?

Rick

[Rick &Dick (quizas)]

And if I use the .sens line, the original .measure line couldn't work:
.measure tran up_imin min i(xi0.vupper) from=20e-9 to=100e-9
It return FAILED, while it returns 9.05e-5 without .sens line

[Rick &Dick (quizas)]

I take place the adjoint=1 with direct=1 , the normal measure result comes back, Are there some limitations when I use adjoint?

[xyce-users]

Hi there, 

If you are getting different solver behavior with different sets of sensitivity parameters (and nothing else about the netlist changes) that is pretty strange and I'm not sure why that would happen, unless there is yet another bug in the code that I haven't found yet.  Is this a circuit you can share with me?

The sensitivity analysis feature is basically a post-process calculation, so adding it shouldn't cause the transient forward time stepping to fail, if it wasn't failing before.   And, changing the list of parameters should not change the transient forward calculation either.

The variable stepsize algorithm (local truncation error) ignores anything happening with sensitivity analysis, so the time stepping should be identical with or without sensitivity analysis.    Also, it should be the same for different numbers of parameters.  Like I said, all of the .SENS code is basically a post-process, from the point of view of the solver.

There is one legitimate way that transient adjoints (that I can think of) would potentially cause the time stepping to be different and that is if you set specific adjoint time points for calculation.  If you do that, the code will set breakpoints at those user-specified time points, and that will change the time stepping somewhat, at least near those time points.   Possibly that could throw things off.

As to replacing adjoint=1 with direct=1, if that works for you, I'd keep doing that.      Depending on your number of parameters, the direct method might be a better choice anyway.

thanks,

Eric