ra3xdh / qucs_s

Qucs-S is a circuit simulation program with Qt-based GUI
https://ra3xdh.github.io/
GNU General Public License v2.0
848 stars 110 forks source link

Qucs Voltage Controlled Resistor issue #958

Closed tomhajjar closed 1 week ago

tomhajjar commented 2 weeks ago

Per your discussion with @felix-salfelder, I tested the examples in the qnucsator package and found the VCR Verilog-A device doesn't work in Qucs-S but does work under Qucs. I redid the example but it never worked under Qucs-S. https://github.com/Qucs/gnucsator/tree/develop/examples

Also checked MESFET and it doesn't work. I assume none of the Qucs "verilog-a devices" work.

2024-09-24_175858 2024-09-24_175957

VCR_prj.zip

ra3xdh commented 1 week ago

It is not a bug. The VCRESISTOR is ADMS device defined in Verilog-A. The ADMS dependency for Qucsator_RF made optional and disabled by default because ADMS requires Perl modules to compile. See https://github.com/ra3xdh/qucsator_rf/issues/1 This may be difficult for some platforms. See #51. One have to recompile Qucsator_RF with ADMS support to enable ADMS devices. In the long perspective the ADMS interface should be replaced by OSDI interface. But I don't consider this to be done by myself in the near future.

felix-salfelder commented 1 week ago

On Wed, Sep 25, 2024 at 12:35:24AM -0700, Vadim Kuznetsov wrote:

It is not a bug. The VCRESISTOR is ADMS device defined in Verilog-A. The ADMS dependency for Qucsator_RF made optional and disabled by default because ADMS requires Perl modules to compile. See https://github.com/ra3xdh/qucsator_rf/issues/1 This may be difficult for some platforms. See #51. One have to recompile Qucsator_RF with ADMS support to enable ADMS devices. In the long perspective the ADMS interface should be replaced by OSDI interface. But I don't consider this to be done by myself in the near future.

The problem with Qucsator and ADMS is not so much ADMS, it could have worked reasonably well. You can repeat this with OSDI and Qucsator_RF, or let someone else do it. But please consider an appropriate solution, which may come out much easier to do on your side.

As a matter of fact, the few "Verilog-A" devices originally included with Qucs were not actually visible as such, but rather baked into the default simulator. This approach does not scale, because there are too many models, and nowadays, there are also too many simulators.

For this reason Gnucsator does not include those "Verilog-A" devices. They belong to Qucs, not Qucsator. Anyway I patched them to comply with the standard and they seem to work.

What we need is a rethink of the interchange between editor and simulator. The first step (Schematic interchange) is outlined in the Qucs ROADMAP. The second step, models need to be under user control. (You get the second for free if you do the first...)

Anyway, let's assume you wanted to stick to Qucsator netlist syntax. There is still space at the top of the file to put the models. It's crucial to let the simulator deal with them, so you can recombine. A basic example netlist may look like this.

# Qucs (future version)

// self contained
`models
module vcresistor (C1, C2, P1, P2);
inout P1, P2;
    [ put Richards code here ]
endmodule
`endmodels

// library style alternative
`include_models "vcresistor.va"

# plain Qucsator netlist, for now.
Vrect:V2 in gnd ="1 V" TH="1 ms" TL="1 ms" Tr="1 ns" Tf="1 ns" Td="0 ns"
[..]
vcresistor:VCR1 _net0 _net1 _net2 _net3 gain="10"

This essentially works with Gnucsator, and currently requires manually edited .rc or .net files. For full automation, a little more code is required.

Now this also relates to [1]. We primarily need portable models. Someone will come up with a simulator, or even with a patch against Qucsator_RF.

[1] https://github.com/ra3xdh/qucsator_rf/issues/7