#70 Timestep too small using s_xfer

[jpcgt]

Hello!

I'm getting the following error:

doAnalyses: TRAN:  Timestep too small; time = 1.99167e-09, timestep = 0: trouble with node "ctle_out"

My circuit is very simple:

a14 in ctle_out ctle

.model ctle s_xfer(in_offset=0.0 gain=3141.5926535897934 int_ic=[0 0]
+ num_coeff=[1.0 -6.283185307179586]
+ den_coeff=[1.0 -376.9911184307752 19739.208802178717]
+ denormalized_freq=1e9)

.probe V(ctle_out)

Vin in 0 SIN(0 0.5 10e9)

.tran 0.1p 5n

The coefficients of the s_xfer are not huge. I though that may be the problem earlier and that is why I'm using denormalized_freq. An AC analysis simulates just fine.

I'm running ngspice-42 in Ubuntu 22.04.

Thanks in advance for any help!

[Holger Vogt]

If you do not use denormalized frequency, the simulation runs just fine.

[marcel hendrix]

Are you sure about the "denormalized_freq=1e9" part? Without it the simulation runs without errors, but gives only 45nVpp output @ 10 GHz.

[jpcgt]

For completeness, I'm defining a filter with 1 zero at 1 GHz, one pole at 10 GHz and one pole at 50 GHz. Nothing unusual there.

After some math, the transfer function is:

(s - 6283185307.17959)/(s**2 - 376991118430.775*s + 1.97392088021787e+22)

Using those coefficients in s_xfer directly, without denormalized_freq, fails in the same way. I thought it was because of the large coefficients.

From the manual:

The denormalized_freq term allows you to specify coefficients for a normalized filter (i.e. one
in which the frequency of interest is 1 rad/s). Once these coefficients are included, specifying
the denormalized frequency value ‘shifts’ the corner frequency to the actual one of interest.

So I redefined the filter with the zeros and poles frequencies devided by 1e9, thus 1 Hz, 10Hz and 50 Hz. Which results in more reasonable coefficients:

(s - 6.28318530717959)/(s**2 - 376.991118430775*s + 19739.2088021787)

But now we need the denormalized_freq=1e9 parameter. The AC result looks just as expected (see attachment).

In summary, w/o denormalized_freq we get the wrong circuit. I'm certain that using denormalized_freq the way I am is correct jast as far as the manual indicates.

[marcel hendrix]

I could be wrong, but my calculation indicates that the poles of your transfer function are in the right half-plane:

H =
       3142 s - 1.974e13
  --------------------------
  s^2 - 3.77e11 s + 1.974e22

  >> zpk(H)

zpk(H) =
     3141.6 (s-6.283e09)
  -------------------------
  (s-3.142e11) (s-6.283e10)

On top of that, the max. gain is -160 dB, at 20GHz. I guess something went wrong?

The above would also explain why the .AC worked but the .TRAN fails.

[jpcgt]

Marcel, you are right. The poles were on the right half-plane. After correcting my definition it works with and without frequency normalization. Thanks!

You are seeing -160 dB because it needs a gain term to have 0dB at DC. This is the full definition:

.model ctle s_xfer(in_offset=0.0 gain=3141592653589.7935 int_ic=[0 0]
+ num_coeff=[1.0 6283185307.179586]
+ den_coeff=[1.0 376991118430.77515 1.9739208802178716e+22]
+ )

Why would transient not work? Don't the right half-plane poles just make it unstable? What's wrong with that in the time domain?

If this is theoretically non-simulatable in transient perhaps NGSpice could check ahead of time, report it and bail early?

Thanks!

[marcel hendrix]

Why would transient not work?

Just a tiny bit of (numeric) noise (or a real signal <> 0) and the filter output goes to infinity, which leads to a numeric exception.

A .AC calculation has no notion of stability (only the phase should be funny), but a .TRAN will show it when given a real input signal.

gain=3141592653589.7935

That is 3.141593e12 ... I wouldn't feel comfortable with that in a practical setting (the filter is simulated with pV signals (if not atto, yotta or zettavolts), and then scaled up again. DP floating point has a range of only 16 significant digits.

If this is theoretically non-simulatable in transient perhaps NGSpice could check ahead of > time, report it and bail early?

It is of course possible to check in s_xfer (I would be against that), but not in a general .TRAN simulation. E.g., we do want to simulate oscillators and chaos.

[jpcgt]

My comment is about trying to give the user better feedback as to what happened. Maybe it comes from the ODE solver state when the timestep goes to 0. Does it mean some dv/dt became to big or just v became too large? It would be useful to know. That's probably in the last iteration of the ODE solver.