Simulation Issues with s2p File-based Inductors

[rupokdas147]

I encountered a problem while designing an amplifier using the IHP Open Source PDK with the following tools:

Qucs-S 24.3: For schematic design
Ngspice 43 and Xyce: For simulation

Design Process:
Initially, I completed the amplifier design using ideal components from Qucs-S.
I replaced the ideal resistors and capacitors with the PDK-provided resistors and capacitors. The S-parameter values remained consistent, confirming proper functionality.

To replace the ideal inductors (50 pH each):
Designed the inductor layout.
Simulated it in OpenEMS to generate the s2p file.
Replaced the ideal inductors (L1, L2, L3) with the corresponding s2p files in the schematic.

Problem:
Replacing L3 with its s2p file works fine, and the simulation completes successfully.
However, replacing L1 or L2 (or both) with their respective s2p files causes:
Ngspice 43: The simulation does not start.
Xyce: The simulation produces NaN (Not a Number) values in the results.

Steps to Reproduce:
Design an amplifier schematic in Qucs-S with three 50 pH inductors: L1, L2, L3.
Replace ideal resistors and capacitors with PDK components.
Replace inductors as follows:
Replace L3 with its s2p file: simulation works fine.
Replace L1 and/or L2 with their s2p files: simulations fail as described.
Run simulations in Ngspice 43 and Xyce to observe the issue.

Additional Details:
All s2p files were generated using OpenEMS simulations and validated to ensure physical feasibility.
The issue occurs consistently when L1 or L2 (or both) are replaced with s2p files, regardless of whether L3 remains an ideal inductor or is also replaced with its s2p file.

Expected Behavior:
The simulations should complete successfully for all combinations of s2p-based inductors, just as they do for ideal inductors and for s2p-based L3.

Request:
Please investigate why Ngspice fails to start and Xyce produces NaN values when specific s2p-based inductors (L1, L2) are used. I attached the s2p file, schematic and Netlist.

Thank you!

Amplifier.zip

Ngspice 43:

Xyce:

[KrzysztofHerman]

@rupokdas147 thank you for reporting this case. I was able to reproduce it and indeed it behaves odd.
As @dwarning mentioned in the issue #310 ngspice is not able to leverage noise data form passives components so I turned off the donoise oprion from S-parameter simulation. My initial guess is that ngspice has issues finding DC operating point using file elements although there is an entry in S2P file which reports
S-parameter at 0 Hz.

[dwarning]

I can confirm that ngspice has problems in finding OP if L1 is replaced by an s-parameter file. We have to simplify the testcase and analyze it more in detail.

[dwarning]

@rupokdas147
ngspice with s-parameter has problems to find operating point in your circuit - as said.
A workaround would be to connect the base bias for first transistor direct to base, means after the inductor s2p file. That worked for me, even I don't know the rf performance consequences.

[rupokdas147]

@dwarning Thanks... I managed to achieve almost the same results after removing L1 and L2 with some modifications. But I cannot replace the Inductor in the feedback path with s2p, same problem the DC does not pass. Removing the Inductor significantly affects my results.

[dwarning]

All this problems stem from the unpredictable DC behavior of the x_sfer function in ngspice. I would recommend to scale down the testcase as much as possible to show the issue (e.g. only one stage with one s2p file) and open an bug ticket in the ngspice forum.

[VolkerMuehlhaus]

I'm not surprised that S-parameter can cause issues here. Strictly speaking, the FDTD EM simulation doesn't solve for an accurate result at DC, because that would require to simulate an infinite number of time steps. Simulation stops when residual energy in the system is below a certain limit, and then S-parameter are usually close to the correct answers, but there can always be some small residual ripple. And unfortunately, tiny errors in S-parameters can result in small leakage currents in shunt path, for example, which will cause issues depending on the location where you place the S2P block in your model.

When I was working for Sonnet EM support (i.e. an EM solver know to be very accurate) for many years we heard about issues with using the S2P EM data directly in Cadence Spectre, and this finally lead to two developments: equivalent circuit model fit (well behaved due to predefined physical structure that prevents unphysical DC leakage) and broad band model fit (math based, no underlying phyiscal model, but forced to be passive and causal). Also, Cadence improved the Spectre engine for more robust handling of "imperfect" S-parameter data.

Recommended workaround: In those cases where you only need a narrow band representation of your inductor, a simple solution would be to extract series L and series C at one target frequency, and possibly add a shunt C to the substrate, so that you have a well-behaved physical PI model. This is not the ideal broad band model we would like to have, but it will capture the Q factor at your target frequency and you get rid of the issues often seen with S2P data.

BR, Volker

[KrzysztofHerman]

I dived into the documentation of the ngspice and found this example.

So the file element, which sources a touchstone file is being translated to the XSPICE xfer function documented in chapter 8.2.19 of the ngspice manual.
Unfortunately as one can read there: "This code model is useful only in AC analysis, where it applies a complex transfer function to its input. ".

The reason why Xyce is not even staring since the file element is handled differently using YLIN device is documented in the Xyce Reference manual: "At present, the YLIN device is only supported in the frequency domain for HB analyses."

[felix-salfelder]

Volkers workaround may be valid for this case. But for sure, workarouds do not scale. What is simple must remain simple.

Time domain simulation of these systems is a research topic. Reportedly, vector fitting (VF) & convolution is a basic approach offered in commercial tools, mostly not based on Spice. The first and (to my knowledge) only attempt to tackle this in F/OSS is here [1].

Unfortunately, the candidate student has been hired immediately after, what a surprise. Who is going to finish their work?

Verilog-AMS defines frequency domain, "laplace" filters for such applications, see LRM 4.5.11. Here, the filter parameters are the coefficients computed using VF. I started playing with it some time ago [1] wth some notes here [2]. There's some fun in it, and it's on the agenda. We could use some degree of collaboration to make this a higher priority.

[0] https://sedemos.blogspot.com/2024/04/phd-transient-simulation-of-frequency.html
[1] https://codeberg.org/gnucap/gnucap-transient-sparam/src/branch/bump
[2] https://codeberg.org/gnucap/gnucap-modelgen-verilog/src/branch/develop/examples/trln

[VolkerMuehlhaus]

I'm afraid that my previous post can be misunderstood. I want to emphasize that a physics based model fit is much more robust than a mathematical "black box" solution based on convolution, because we can enforce a topology that prevents unphysical current paths etc. Using the EM data "as is" is the road to desaster for time domain circuit simulators, from my experience, even if the software allows to go that route. In particular, devices with low loss can easily become non-passive in some weird frequency range after convolution.
In addition to that, the underlying S-parameters are never exact (whatever that means) and fitting them to a suitable physical topology avoids a lot of issues. And as a side effect, the resulting model gives valid noise results.

Based on this thread, I started to think about building a Python-based inductor model extraction, to convert S-parameters from EM to a simple PI model. This will be less sophisticated than my Inductor Model Fit for ADS, at least initially, but it should help to get started. Question: what would you prefer as output from this tool, write a netlist file or just dump component values, so that the user can build the circuit model himself?

[metroid120]

I agree with much of what has been said here. The solution at DC of EM simulations is always a huge problem, even using commercial tools one might run into issues.

I just want to add: Recently there has been a pretty big implementation effort to generate RLC based networks based on EM simulation data in scikit-rf. That might already do all that we need here! See:

discussion in scit-rf
pull request

I guess this could be integrated into the design flow pretty easily.

Thanks to @fnordpole

[fnordpole]

Glad to hear there is some interest in the vector fitting code in scikit-rf! I quickly read this thread and here are some comments:

In the vector fitting process, poles and residues are fitted such that the least squares error between the Sparameter data and the model represented by the poles and residues is minimized.

This works good, as long as no discontinuities are present in the data. Unfortunately this is often the case with the DC point. It's not because the DC point is wrong or anything, it's more that the DC transfer is substantially different to the transfer at the first non-DC point.

In the vector fit, the dc point will be considered just like any other sample and the least squares error around DC might be quite high but still, the fit converges because all other samples match pretty good.

There are methods available in the literature about flattening out this discontinuity by modifying the poles/residue pairs at low frequencies, sacrificing accuracy around low frequencies in favor of reducing the discontinuity to dc. None of these are implemented right now in scikit-rf.

Of course the actual computation of the DC point in the Sparameter data is a completely different story and depends on the EM solvers. If the DC point is wrong right from the beginning, then the vector fit can't do anything about it. It will try to fit what there is.

So the bad news is, that this problem won't be solved even with the new circuit synthesizer that I wrote for scikit-rf, but maybe in the future someone might implement one of those discontinuity reduction algorithms in scikit-rf vector fitting.

---

Some off-topic but related comments:

The vector fitting will also get some upgrades soon hopefully:
scikit-rf/scikit-rf#1231

Also the new circuit synthesizer code might get an update to go from admittance-based to impedance-based because this seems to simulate faster in ngspice (~factor 1000x) in Xyce (~factor 4) and in ltspice (~factor 1).
scikit-rf/scikit-rf#1228

It might take a bit of time for this synthesizer fix, because its not clear yet, why it has absolutely no influence in ltspice but so much more in Xyce and ngspice. We asked the Xyce developers for advice and maybe they have a clue:
Xyce/Xyce#123

[metroid120]

@fnordpole thanks for your answer. Just to clarify: Using the current scikit-rf implementation might be inaccurate toward DC as we are missing data points there.

But since an equivalent circuit is generated, I suppose it would still allow convergence of the circuit for normal DC and transient analysis usually, am I right?

Do you know what ADS or Microwave Office are doing in these cases?

[fnordpole]

If there are no data points around DC, the least-squares fit will do whatever it wants at those frequencies because there is no equation for it in the system matrix. But that's not specific to the vector fitting implementation in scikit-rf. It will be the same for any vector fit implementation.

If there is no DC point or no frequency samples for very low frequencies, the rational fit model at DC can be anything from "OK" to "crazy" I would guess. It's definitely worth to plot the frequency response of the fitted model including DC and also up to frequencies way higher than your design-bandwidth because the model behavior outside of the sampled data can be anything.

Also related to this is passivity. Make sure to run the passivity checks with is_passive() and if required the enforce_passivity(). If it's not passive, the simulator might not converge.

About ADS and MWO I have no idea what they do. That's why we are working on making a really good vector fit implementation so that we can all investigate what's goin' on in our models instead of having to rely on a closed source black box that does something and costs a lot of money ;D