Component modelling with C block

I am experimenting with C blocks. I tried to model various components with software, for example the ideal operational amplifier and I noticed a strange behavior. The circuit implementation and the software implementation realize the same function but the simulation shows totally different results. The circuit works correctly but there is some problem with the software implementation.

Could someone explain what happened here?

BlockOpa.qsch (7.0 KB)
swopamp.cpp (1.1 KB)

1 Like

Hi, Istvan.

C-Block component outputs are always one simulation time-point behind the inputs. The value present at the inverting input at t = n is the output value at t = n-1. In short, C-Block components are not for analog stuff.

Quoting from my first C-Block Basics paper: “Before digging in, let’s clear up a possible misconception: C-Block components are intended for simulating digital stuff. You can do analog-like things for sure. But, if it contains feedback loops, it may not work as you plan.”

You can find that paper on my GitHub QSpice repository.

Hope that helps.

–robert

2 Likes

I thought the C blocks are regular components just their description equations are not “wired” into QSPICE, but we can write it.

Even simple power supply controller ICs have voltage or current feedback from the output. Will these simulations fail too? I saw a PID controller implementation on your repository. How could that work?

Hi, Istvan.

Well, I should have been more careful in my wording and more thorough in my explanation. I should probably also revise that first paper.

Anyway, yes, you can do analog inputs/outputs. But the input/output state change delay between samples introduces inaccuracies like this:

I’ve modified your code and schematic for 64-bit floats and a sin signal input:
swopamp.cpp (1.1 KB)
BlockOpa.qsch (8.0 KB)

You can reduce the inaccuracies by reducing the timestep using “.option maxstep=” or by using the Trunc() function. Here’s what we get with maxstep=100n.

If you zoom in enough, it still has delay inaccuracies though.

Maxstep slows down the entire simulation, of course. A better solution might be to use Trunc(). With Trunc() you can selectively increase the sample rate when the signal is changing rapidly. I’ll try to code up an example and post that shortly.

–robert

2 Likes

OK, here’s something for you to play with. What I’m trying to do is avoid .option maxstep and use Trunc() to limit the timestep only when the output voltage is changing “fast.” I’ve deliberately reduced the timestep only on the rising edge just to demonstrate the difference between when Trunc() is changing the timestep or not.

I should also point out that QSpice uses an adaptive timestep algorithm. This makes analyzing the behavior more difficult. The long .tran time let’s QSpice use longer maximum steps but it may, of course, use smaller steps. Also, adding components can change the simulation points that QSpice selects so, again, more complication when analyzing behavior.

Anyway, you can see that Trunc() tracks the rising edge tightly when the voltage rises rapidly.

BlockOpa.qsch (6.5 KB)
swopampx.cpp (2.8 KB)

See the C-Block Basics #4 & #7 papers for more information about using Trunc().

–robert

2 Likes

Lots of things to think about. Thank you Robert.