Bump on ngSpice Simulation

I am very inexperienced with simulations, but am learning, and am now working on a multi-phase PWM circuit to get a high resolution DC signal. During the design, I quickly wanted to disable 3 of the 4 channels by shorting their outputs together. See attached schematic:

However, when I simulate this, I get a bump on the output signal between 16ms and 24ms, and I do not understand why. It is somehow related to the 3 disabled channels. If I completely remove these (together with R4, R5 and R6) then the bump disappears in the simulation.


My project:
2023-09-03_spice_pwm.zip (7.8 KB)

Application: KiCad x86_64 on x86_64

Version: 7.0.7-7.0.7~ubuntu20.04.1, release build

	wxWidgets 3.2.1
	FreeType 2.10.1
	HarfBuzz 6.0.0
	FontConfig 2.13.1
	libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3

Platform: Linux Mint 20.3, 64 bit, Little endian, wxGTK, xfce, x11

Build Info:
	Date: Aug 13 2023 23:14:53
	wxWidgets: 3.2.1 (wchar_t,wx containers) GTK+ 3.24
	Boost: 1.71.0
	OCC: 7.5.2
	Curl: 7.88.1
	ngspice: 38
	Compiler: GCC 9.4.0 with C++ ABI 1013

Build settings:

I’m not knowledgeable enough with NGspice but, have used it (I prefer LTspice). That said,
is your circuit correct?

Your DC source’s +(out) has a GND on that pin and no GND on the lines tied to the Cap’s GND

For me it is very simple. It is either ngSpice or no Spice at all.
The only way for me to even consider another spice variant is if it is natively bundled with KiCad.

Yes this is correct.
The DC offset is only to overcome another ngSpice problem. The 3rd order filter has a ripple residual of about 1uV, and I can not zoom in on that if it is at 1V output. Therefore I force a -1V starting point to let the output voltage settle on 100uVdc (with the current settings).

As an extra, I removed the DC source:

and this has an influence on the simulation. Te bump is now from 16ms to 32ms, so it is longer.


I also noticed that all these numbers are multiples of 8ms, and 8us is the tw parameter of those 3 disabled pulse sources.

Yet another minor *&^%$#@! is the overlapping text at the bottom of the graph. I encounter such small flaws nearly daily now I’m working a bit more with KiCad.

intertesting… I wager @holger has a solution…

If I probe the output of the 3rd filter stage (top of C3) with the offset and zoom in, I can clearly see the 1uV ripple. Note that the Y axis has nice numbers in microvolts.


But when I remove the 1V dc source then it looks like the figure below. You can still see the ripple, but the labels are all “1V” and I can not see the scale.


This may help: Right-Click on the Values on desired Axis, select Zoom-In. Then, Drag your Mouse Cursor’s tip along the Axis

Also, the Sim-Command tool as value/axis settings

This is one reason I use LTspice (and, I run LTspice from Inside Kicad :grinning:) I do understand a reluctance to go in that direction…)

A post was split to a new topic: Is there LTspice for Linux?

It is not a reluctance. My main motivation is improving KiCad and things around it. “Getting stuff done” is a secondary goal. And much rather, I would edit out and delete all LTspice references in this thread before Holger even sees it. (But I won’t just go deleting other peoples posts without permission. @BlackCoffee Feel free to edit / delete my posts concerning the LTspice related parts.

1 Like

I did one change to your circuit: tr and tf now are 1n. 1p is TeraHertz, never achievable with any reasonable circuit (except for very special ones of course). Then I get with your project unchanged otherwise:

1 Like

I did not give much thought about the pico second thing, but I did notice that when I left the rise and fall times at zero, then it uses the default simulation step, which is 1us at the moment. My goals is to first design the filter with “perfect” PWM signals, and later examine the faults introduced by real parts such as 74HC logic.

I also did notice my simulation was quite slow sometimes (Taking more than a minute to run instead of milli seconds (with an 8% CPU load on a single of the 12 available threads, sigh).

So at this moment, I’m glad to have some insight , but I do not know whether I am to blame for setting up silly values, or whether ngSpice should be able to handle such input without showing that weird bump.

Increasing tr and tf to 1n also adds 100uV to the final DC value. (And a realistic 6ns (for 74HC TTL adds 600uV) so this needs more thought later. I am planning to build the circuit both on a breadboard and on a real PCB when further debugged, and 100uV is an important deviation to me. My goal is to get an adjustable DC voltage with 50ms settling time to 10ppm, as a part of a bigger project.

Not pushing LTspice… Just want to show a Comparison… This took about 8 minutes to build circuit.

Running simulation was finished before I took my finger off the button…

Yes you are :slight_smile:

but it would be nice if ngSpice would “just work” without all those strange issues.
Setting up the basic simulation is pretty easy, but with my experiments in this project I already encountered 3 issues.

  1. The weird bump by the 1ps resolution.
  2. No proper axis indices when zooming in at a 1uV ripple on a 1V signal.
  3. Text on X-axis overlapping.

And maybe add a 4th and a fifth.
4. Simulation taking a long time (sometimes) just because a rise time is short.
5. ngSpice running on a single thread on a 6-core 12 thead Ryzen 5600G.

okay, perhaps I am pushing it a bit, sort of like pushing a Covid Vaccination - works for me and hate to see someone suffering… but, if someone doesn’t want one, it’s okay with me…

Never had a problem with LTspice and it’s Free and produced by one of the biggest Chip companies…

This is what you will get with ngspice-41 and the original 1p rise and fall times, where we have renewed the pulse option for the voltage source:

Quite annoying, but I believe recently fixed in nightly (the simulator plotting interface is massively improved in 7.99)

That I like!
Separating the units from the values leaves more room for those values, especially on the horizontal axis.
I also hope that these “round numbers” are persistent when zooming in.

Is there a way to influence drawing order? The noisy blue trace obscures the others, It would be nice if for example you can drag the names in the “Signals” part up or down with the mouse to change the drawing order.

I also noticed in the “Post V7” thread there were lots of improvement in the plotting window. Including cursors and measurements :slight_smile:

Unfortunately the nightlies don’t work for me at the moment, but that is (yet) another topic.