OSDI/OpenVAF: Verilog-A compact models in ngspice

[Marvelousmay]

I used the precompiled standalone executable of Openvaf. Here I tried compiling a comparator model using Verilog-ams language, but I failed, it reported an error like this:

# openvaf comparator.va
thread '<unnamed>' panicked at 'internal error: entered unreachable code: attempted to read undefined value', openvaf/mir_llvm/src/builder.rs:112:34
note: run with environment variable to display a backtrace

My comparator model is as follows：

`include "disciplines.vams"
`include "constants.vams"

module comparator (sigin, sigref, sigout);
input sigin,sigref;
output sigout;
electrical sigin, sigref, sigout;
parameter real sigout_high = 10;
parameter real sigout_low = -10;
parameter real sigin_offset = 0;
parameter real comp_slope = 1000;

analog begin

@( initial_step) begin
    if (sigout_high <= sigout_low) begin
    $display("Range specification error. sigout_high = (%E) less than sigout_low = (%E).\n",sigout_high,sigout_low);
    $finish;
    end
end

V(sigout) <+ 0.5 * (sigout_high - sigout_low)* tanh(comp_slope*(V(sigin, sigref) - sigin_offset))+(sigout_high + sigout_low)/2;
end
endmodule

I tried another simple model and found that the problem appeared here, and that is that I can only express V like this:
I(p,n) <+ idt(V(p,n))/L;
Instead of using:
V(p,n) <+ L*ddt(I(p,n));
So when I want to express a V relationship for example:
V(n2,n1) <+ gain * sin(2 * `M_PI * freq * $abstime);
How can I modify it?
Looking forward to a reply.

[nicolati]

Hi!
Let me jump in, even I'm not the coder behind OpenVAF.

I have 3 topics:

1. Are you sure the model is correct? I expected to see V(node1, node2). If you don't put node2, then it's ground, but this means your model expresses the voltage at the output against ground. Are you sure about that?
2. SPICE doesn't store ground in the matrix, which means your model has only 1 entry in the matrix, which is not correct, because all nodes give 4 entries
3. SPICE is Nodal Analysis tool (actually MNA, but let's keep it simple), so we need a relationship like I = G(V) * V. We can ofc use V = R(I) * I, but this requires adding a fake node, like Voltage Source (or other models do), but this is not implemented into OpenVAF yet, and I'm not sure how simple is this

Thank you,
Fra

[pascalkuthe]

After fixing this bug the example above works well.
OpenVAF does a lot of black magic to make this work. It took me a long time to figure out how to make that work.

[Marvelousmay]

I'm glad you joined and helped me, in fact it's not a complete circuit, so I'm mostly confused as to why OpenFaf doesn't support V(n1,n2) <+ R*I(n1,n2).

[pascalkuthe]

Thank you @nicolati for jumping in. I sadly didn't have time to reply yet as I was preoccupied today. I just tested this locally.

OpenVAF fully supports voltage sources and this example was just bug in OpenVAF.
All crashes of OpenVAF are bugs no matter how incorrect the model is.
OpenVAF should always report a helpful error message even for incorrect models and will never intentionally crash.

We usually test larger compact models so issues with smaller models (espeically around voltage sources) may have been overlooked. The current release is still a beta version so some issues like this are possible.

I already have found and fixed the bug locally and will push a fix (alogn with fixes for other issues) tomorrow.

[Marvelousmay]

Glad to see your response, I'm just a preliminary attempt at OpenVAF, such as testing a simple voltage source model, but as I described, it's not supported for the time being, looking forward to your bug fix.

[pascalkuthe]

You can download a development version here (for linux, if you need a windows version let me know) where the problem should be fixed.

I will push the fixes to the repo soon but I am still working on this.
But in the meantime you can already continue working

[Marvelousmay]

I just tested it and now it's viable, thanks so much, I'll keep trying more models.
Thank you from the bottom of my heart.

[pascalkuthe]

The appropriate fix has been merged into the master branch and will be included in the next release. Until then it's available in the nightly build I shared above

[nicolati]

Hi Pascal,
it's Francesco here! :)

For sure we don't want any software to crash, so I agree you wanted to fix it.
In fact I said I'm not the coder of OpenVAF ! :)

Still I think my points are still valid. And I'm not saying Voltage equations cannot be used. I'm saying it's complex to use them. So, if you already implemented this part, then congratulations to you, because this part has always been a problem! :)

Fra

[pascalkuthe]

The circuit is still correct tough.
A comperator usually outputs the difference between an input voltage and a reference signal (within circuit rails ofcourse).
This kind of model (in much more complex form) is pretty common. You can ofcourse model this with a proper opamp model to but simple behavioral models like this are nice too) I think.
This model captures that perfectly well.

SPICE doesn't store ground in the matrix, which means your model has only 1 entry in the matrix, which is not correct, because all nodes give 4 entries

nodes only connected to ground can have a single matrix entry and that is perfectly fine. OpenVAF generates the correct derivatives for this case. I tested this model with ngspice and it works great.

In general you don't need to worry about these SPICE details with Verilog-A and OpenVAF.
If your code complies with the Verilog-A standard OpenVAF will just automatically do the right thing.

[pascalkuthe]

Indeed. BTW, I'm studying your code from time to time, because I wanted to try to implement KLU.

I think you need more testcases for that. Maybe Marcel Hendrix can help with some power models.

Fra

You mean CUDA right?
AFAIK KLU is just a sparse matrix solver which doesn't need support from OpenVAF (my own simulator uses KLU without issue).

More testing is definitely welcome.
I usually just add models I run into as an integration test but we have limited development resources so I can't dedicate as much time towards testing as I might like.

[nicolati]

Hi Pascal,
sorry, but I still don't get the first part.
If I say V(nodeout), this means the voltage between that node and ground, while a model should say a voltage between 2 nodes of the model. So, I would say V(nodeout, noderef) is the correct thing, if the intention is the voltage against a reference node.
That's why I asked if the model is correct.

In SPICE, if you say V(nodeout), you have 1row/1col only, because ground is not stored, but if you have V(nodeout, noderef), you have 2rows/2cols and 4 elements.

Regarding KLU and CUDA, I really wanted to have CUDA development, but this requires major effort. I'm not young anymore! :D I have done my work 10years ago! But for KLU as well, I need an extra piece of model coding, because the implementation I coded in NGSPICE supports the swapping between SPARSE, KLU real numbers and KLU complex numbers and only the model knows where to write contributions. This means that I need to change the pointers inside the model at each change of the engine.

Fra

[pascalkuthe]

sorry, but I still don't get the first part.
If I say V(nodeout), this means the voltage between that node and ground, while a model should say a voltage between 2 nodes of the model. So, I would say V(nodeout, noderef) is the correct thing, if the intention is the voltage against a reference node.
That's why I asked if the model is correct.

In SPICE, if you say V(nodeout), you have 1row/1col only, because ground is not stored, but if you have V(nodeout, noderef), you have 2rows/2cols and 4 elements.

In a realworld model you would definitely have a reference node instead of using ground but it works perfectly fine as it. The Verilog-A standard explicitly allows contributions like this. OpenVAF creates a voltage source between ground and the specified node and the simulation converges just fine and behaves exactly as expected.

Regarding KLU and CUDA, I really wanted to have CUDA development, but this requires major effort. I'm not young anymore! :D I have done my work 10years ago! But for KLU as well, I need an extra piece of model coding, because the implementation I coded in NGSPICE supports the swapping between SPARSE, KLU real numbers and KLU complex numbers and only the model knows where to write contributions. This means that I need to change the pointers inside the model at each change of the engine.

OpenVAF already supports this. It compiles the model to a simulator independent interface we invented named OSDI.
The simulator controls the matrix pointers so you just need the change the ngspice OSDI integration. No changes to OpenVAF itself are necessary.

[nicolati]

I'm still not sure, but I have to do some maths on my own. My problem is that this works, ok, fine, but you know you have to implement it in this way... The model doesn't say that, unless Verilog-AMS manual says what to do in this case.
Intuitively, that's not correct. Just this! :)
I will mail you once I have done my homework! :)

Regarding KLU and CUDA, the problem is that I need additional data structure on the model side. That's why I guess I need to modify OpenVAF.
But, also in this case, I have to do my homework before saying more.

Thank you,
Fra