Which errpreset takes precedence, APS accuracy+speed or tran analysis?

Dear fireonthesee,

The errpreset you selected in the transient analysis GUI panel will be chosen for the transient analysis. I just checked by selecting an errpreset of “liberal” in the APS GUI panel and an errpreset of “conservative” in the transient analysis GUI panel for the version of Cadence I am using and the latter is selected for the transient analysis. Two comments if I may...

1. An easy way to check the value of errpreset used is to examine the relevant analysis statement in the netlist file (input.scs file in the netlist directory), I am displaying the transient analysis command for the test case I performed below:

tran tran stop=210n errpreset=conservative noisefmax=10e9 noisefmin=1 \
noiseseed=1 noisescale=1 noiseoff=[ R12 E2 V25 C3 C2 E12 E11 E9 E10 \
C6] maxstep=1e-12 write="spectre.ic" writefinal="spectre.fc" \
annotate=status maxiters=5

2. Within the APS GUI panel, you should see a “Do not override” radio button under the Accuracy Setting”. Selecting this option will guarantee your APS errpreset option has a lower priority than the value you select in an analysis.

Does this help fireonthesee?

Shawn

Hi Shawn,

Actually, the setting on the High Performance Simulation form does override the transient analysis setting (the clue is in the presence of the "Do not override" choice; if it didn't override, there would be no need to have that button).

The point is that when setting APS you may well want to override the settings that an individual has put on the analysis. It's not unusual for users to overdo the accuracy settings unnecessarily.

If you specify it on the High Performance Simulation form for APS then errpreset gets passed on the command line and the netlist retains the analysis options as on the form. The way you can tell what it's doing is to look at the Important parameter values section of the output log. In this case below I had moderate on the tran form and liberal on the High Performance Simulation form:

***********************************************
Transient Analysis `tran': time = (0 s -> 1 us)
***********************************************
DC simulation time: CPU = 2.999 ms, elapsed = 3.21388 ms.

Opening the PSFXL file ../psf/tran.tran.tran ...
Important parameter values:
start = 0 s
outputstart = 0 s
stop = 1 us
step = 1 ns
maxstep = 20 ns
ic = all
useprevic = no
skipdc = no
reltol = 10e-03
abstol(V) = 1 uV
abstol(I) = 1 pA
temp = 27 C
tnom = 27 C
tempeffects = all
errpreset = liberal
method = trapgear2
lteratio = 3.5
relref = sigglobal
cmin = 0 F
gmin = 1 pS
rabsshort = 1 mOhm

As you can see, the result was liberal (the other red settings are because of liberal having been picked).

Regards,

Andrew.

Hi Andrew,

Hmmm...very interesting. Is there any chance the behavior has changed with IC version?

Unlike the case you are showing, the behavior I am experiencing is not consistent with your result. I've attached a png of my High Performance Simulation and Transient analysis GUI panels noting the difference in errpreset settings. In the second png I've included, I'm showing two sections of the resulting spectre.out file. As you correctly indicated the "liberal" setting is passed on the spectre command line. However, in the transient analysis summary (which I am quite familiar with), note that an errpreset of "conservative" is selected - consistent with the transient analysis command line in the input.scs file for the transient analysis and transient analysis GUI panel. I've also displayed the IC and MMSIM versions I am using in case there has been a change in the behavior....

My apologies, to both fireonthesee and you, if I am overlooking something!  However, I did check the behavior prior to responding to fireonthesee as I was trying to be sure my response was accurate...(sigh)...

Shawn

Thanks Andrew. I tried on my end (virtuoso IC6.1.6) and confirmed your explanation matches what I see on my test bench. The High Performance Simulation Options page does take precedence over transient analysis form, unless "Do not override" is selected.

Thanks for Shawn for helping on this as well.

Cheers,

Fireonthesee 

Dear fireonthesee,

Unknown said:

Thanks Andrew. I tried on my end (virtuoso IC6.1.6) and confirmed your explanation matches what I see on my test bench. The High Performance Simulation Options page does take precedence over transient analysis form, unless "Do not override" is selected.

Thank you for letting me know. I'm not sure I can explain why the transient analysis setting overrides the APS setting in the example I tried based on your and Andrew's result. Nevertheless, I am glad you are all set fireonthesee!

Shawn

Dear fireonthesee and Andrew,

Curiosity got the better of me and I had to study the difference in behavior in how the errpreset is selected between the High Performance Simulation GUI and the transient analysis GUI panels. I had a thought and, sure enough, I believe I have found the reason for our two different results. In my example, as I do not select the aps++ radio button in the High Performance simulation GUI (please refer to the prior png attachment detailing the panel). This resulted in an errpreset of conservative in the simulation (the selection from the transient analysis GUI panel as shown above) in lieu of the "liberal" errpreset value in the High Performance simulation GUI panel. . However, if I do select the ++aps radio button in the High Performance simulation GUI (shown in the attached png file), the errpreset chosen for the simulation is "liberal" consistent with that in the High Performance simulation GUI and not the "conservative" errpreset selected in the Transient analysis GUI panel shown above.

Hence, I do not know if it is by "design" or not, but the use of the aps++ APS feature appears to impact which GUI errpreset setting is chosen.

Comments are welcomed....

Shawn

Hi Shawn,

I've figured out why you're seeing this behaviour. See your command line settings:

You have +aps specified twice - and so the second one (which doesn't have an errpreset specified) is overriding the first - this means that it's essentially using the "do not override" mode because +aps was specified second.

I expect that if you look at Setup->Environment you have +aps (and probably +dcopt) in the "User Command-Line Options" field. You should probably remove those (at least remove the +aps). That will avoid the duplication of settings which is causing it to misbehave. This is not version-specific - I reproduced your problem both with SPECTRE18.1 ISR6 (like you) and the latest SPECTRE19.1 ISR (and I couldn't reproduce it without the User Command Line Options +aps).

The reason why it works with ++aps is because then it would have ++aps=liberal +aps - and ++aps overrides +aps.

Regards,

Andrew.

Dear Andrew,

I am so sorry you had to waste your time on my observation!

Andrew Beckett said:

I expect that if you look at Setup->Environment you have +aps (and probably +dcopt) in the "User Command-Line Options" field.

Absolutely. Well before the High Performance GUI existed, this is how I called APS (and +dcopt). I fully understand your explanation. As I often saw the duplicate instances of +aps in the spectre command line, I wondered if there was any issue with the duplicate instances I never noticed any undesirable "side-effects'. However, I did not appreciate that the second instance would take precedence over the first instance in the command line.

Once again, I'm humbled and appreciate your extensive insight. Thank you,

Shawn

Unknown said:

I am so sorry you had to waste your time on my observation!

Hi Shawn,

Don't worry! It took me only a few minutes and I was intrigued as to what could possibly be causing this. This is precisely the kind of problem that is fun to figure out (yes, I'm a bit sad like that!)

Andrew.

Hi Andrew,

Andrew Beckett said:

This is precisely the kind of problem that is fun to figure out (yes, I'm a bit sad like that!)

Well, I very much appreciate your effort...and I guess I must admit to the same "addiction" as I could not drop the issue when I found it...

Thank you and enjoy the weekend (I hope!).

Shawn

Hi Andrew,

Andrew Beckett said:

This is precisely the kind of problem that is fun to figure out (yes, I'm a bit sad like that!)

Well, I very much appreciate your effort...and I guess I must admit to the same "addiction" as I could not drop the issue when I found it...

Thank you and enjoy the weekend (I hope!).

Shawn