Parametric measurements with sim time impact

Dear all,
I get wrong results from the required measurement in the specific case the duration of the simulation transient is dependent on the parameter on which the variation is set (the switching frequency F in the example below). Has anyone else experienced a similar behaviour?

  1. Case 1 (single step):
    .tran 0 1000/F 995/F 10n
    .param F=56.6K
    .meas SoftSW_factor max(V(V_Cd1))/V(Vi)
    => good result, that is:
    .meas softsw_factor max(v(v_cd1))/v(vi):
    1.12163 (at Time=0.0176014)

  2. Case 2 (parametric)
    .tran 0 1000/F 995/F 10n
    .step param F 55K 57.5K 250
    .meas SoftSW_factor max(V(V_Cd1))/V(Vi)
    => desired sim conditions but wrong results:

  3. Case 3 (parametric with fixed Tsim)
    .tran 0 18m 17m 10n
    .step param F 55K 57.5K 250
    .meas SoftSW_factor max(V(V_Cd1))/V(Vi)
    => not so elegant form but good results (in line with case 1):

Note: Steady-state condition is guaranteed in all sim runs…

Thx

Try to increase relative tolerance. Here:
.options reltol=1u
You can lower it to increase simulation speed.

Best regards

It feels like you might get incorrect results if Tstart keeps changing in each .step.

In a .step simulation, do not change Tstart in .tran (i.e. Tstart not to depends on a changing paramerter). In .step, it looks for the time to go backward to separate datasets. If you change Tstart during the simulation, .step may confuse the datasets for each step and provide you with incorrect results.

Thanks a lot for your suggestion …
Unfortunately it seems not a issue related to accuracy …
On the contrary, it seems that the measurement statement is not able to operate distinctly in the different time intervals “created” at each simulated step. I’ve also tried to add some time conditions to the statement but without benefits.
I suppose this condition is not properly managed by the SW, but I cannot be sure.
Here is a capture of the time domain results for the parameter involved in the measurement:


Vi is a constant.

This characteristic has been discussed with Mike Engelhardt, and this is a quote from Mike’s reply
QSPICE looks for the time to go backwards to detect one step from the next.
Don’t change TSTART if you want a flawless step recognition.

This characteristic is firstly discussed in this post, and solution is to prevent to modify Tstart in .tran
Step analysis on FRA analysis - QSPICE - Qorvo Tech Forum

1 Like

Ok, many thanks for the info.
So, starting from this SW limitation, it can be solved in this way:

  1. Case 4 (parametric with fixed Tstart)
    .tran 0 Tstart+5/F Tstart 10n
    .param Tstart=17m
    .step param F 55K 57.5K 250
    .meas SoftSW_factor max(V(V_Cd1))/V(Vi)
    => same good results of case 3

It allows to operate in different time intervals, maintaining the parametric dependance. In fact, it’s really important to maintain it for certain types of measurements.