Add transient model for microstrp lines #7
Comments
ra3xdh
changed the title
|
By placing this issue under qucsator-rf are you not hiding it from those who look at qucs-s issues? |
|
I am placing this at QucsatorRF repository, because it is related to simulator engine, but not related to GUI. I may duplicate this at Discussion/Ideas section of the main repository. No work is required at GUI side to implement microstrip transient models. Everything should be done at QucsatorRF side. |
|
I have started implementation of the transient models for microstrip lines in #16. |
|
Hi Vadim. In case you didn't know, or maybe forgot. Missing models in Qucsator was one of the motivations behind Gnucsator. (It seems QucsatorRF is essentially Qucsator. Is this going to change? I gave up on Qucsator long time ago, and I thought you did so too.) We have the features ready needed to represent and simulate transmission lines (Using Verilog-A). As it now looks like you intend to keep supporting Qucsator netlists, there should be room for collaboration on models.
There is more than one transmission line model, multiple ways to represent it and multiple simulation techniques. It would be nice if Qucs-S had a mechanism to choose a model behind a symbol. I remember the original Qucs had hardwired all the symbols/names/parameters back in the days. A user specified device type (better: user specified parameters, basically the way gEDA did it) would be very useful. cheers |
Maybe you underestimate the complexity. Some ground work was already done but in a PhD thesis [1]. It gives some clues about what commercial tools do nowadays, and what may work. [1] https://sedemos.blogspot.com/2024/04/phd-transient-simulation-of-frequency.html |
|
Hello Felix, Thanks for interest.
What missing models? Could you remember or provide a link?
Yes, QucsatorRF inherits a code from Qucsator-0.0.20. I have no intention to change the netlist syntax etc.
The user feedback show that there exists a need in RF simulation engine and Qucsator still be in use. The SPICE cannot resolve this task. The development of the original Qucsator has been stalled, and I decided to make this fork. See also #1
This may be not a straightforward task. Prof. Mike Brinson has tried to implement MS line mode using Ngspice+OpenVAF about two years ago and failed. He didn't contact me regarding this question in the last year. This also was a motivation to continue support Qucsator. It has many unique RF simulation feature and I am not sure if this could be implemented using SPICE.
Qucs-S still inherit hardcoded C++ system devices library from old Qucs. The redesign of these devices is technically possible (need something like Qucs/qucs#659), but I don't consider this to be done in the near future. This task requires a huge amount of coding. This is beyond of the scope of this issue.
The QucsStudio project has transient model for transmission line for a long time. So, the underlying mathematics should be well known. I am intending at least to reproduce the features implemented in QucsStudio. Unfortunately the developer of QucsStudio has closed the source. |
|
On Tue, Sep 24, 2024 at 09:54:25AM -0700, Vadim Kuznetsov wrote:
> Missing models in Qucsator was one of the motivations behind Gnucsator.
What missing models? Could you remember or provide a link?
Models are everywhere. The real issue is that simulators don't support
them. Qucsator had a few baked-in models, and it needs a fork to add
another one.
Transmission lines come in various flavours, some use subcircuit macros,
some use analog filters. I started to collect a few examples, but the
list is practically endless [1]. Needless to say, it's not (yet) on our
agenda. To make it a priority, I need a collaborator.
The user feedback show that there exists a need in RF simulation
engine and Qucsator still be in use. The SPICE cannot resolve this
task. The development of the original Qucsator has been stalled, and I
decided to make this fork. See also #1
The original Qucsator is maintained as-is, and the development has moved
on to Gnucsator. In the first iteration Gnucsator was supposed to be i/o
compatible with Qucsator, but with the intent to move on.
> We have the features ready needed to represent and simulate transmission lines (Using Verilog-A).
This may be not a straightforward task. Prof. Mike Brinson has tried
to implement MS line mode using Ngspice+OpenVAF about two years ago
and failed.
Did OpenVAF exist 2 years ago? Anyway it still does not provide either
paramset, generate, subdevices or the analog filters I'd use in
transmission line models. Without these features, is there any need to
try?
> Maybe you underestimate the complexity. Some ground work was already done but in a PhD thesis [1].
The QucsStudio project has transient model for transmission line for a
long time. So, the underlying mathematics should be well known. I am
intending at least to reproduce the features implemented in
QucsStudio. Unfortunately the developer of QucsStudio has closed the
source.
Have you asked him to publish it? To my knowledge QS has been
discontinued.
Models need to become user data. Closed models are basically worthless,
and non-portable models will hold everyone back. There are multiple ways
to implement transmission lines. The basic lossless reflection based one
has been in Gnucap for decades (C++, hand coded plugin). This one turned
out to be effectively 5 lines of Verilog-A. We have added AC loss, but
not the general transient support you may be after here.
To get loss into transient, you can discretise RLGC, or employ some
filter tricks. There is more than one way. Verilog-A provides the
framework for this. Also, you may want to infer coefficients from VNA
measurements. It won't end here. With the basics done, you may want to
add cross talk, and simulate more complex circuits, perhaps PCB models.
Looking at it this way, it may be more promising to add Verilog-A/MS to
a Qucs GUI (see my Qucs-s/vcresistor post for a starting point), than
developping yet another simulator.
[1] https://git.savannah.gnu.org/cgit/gnucap/gnucap-modelgen-verilog.git/tree/examples/trln/README?h=develop
|
The OSDI interface looks "production-ready" and may resolve this issue. I have a little interest in implementing OSDI interface for QucsatorRF myself, but I would accept the patch containing the implementation. This question is beyond the scope of this issue.
Yes, the OpenVAF developer provided an interface for Ngspice by the end of 2022.
The QucsStudio still be alive. The developer has recently posted some intention about preparing a new release. I didn't contact with the developer personally, but there were many requests to make QucsStudio open-source or at least cross-platform. The answer from the developer was "no". For example look here: https://qucsstudio.de/forums/topic/linux-support/ P.S.: these questions are beyond the scope of this particular issue. You may open a new discussion here: https://github.com/ra3xdh/qucsator_rf/discussions |
Oh, true. Time flies :/
Really unfortunate that QucsStudio is closed. It might save some time, or at least remove some doubts. Anyway, I am unsure what you are after here. The "help needed" tag and title suggested that you need help with a model implementation. |
See ra3xdh/qucs_s#681 for context. The ideal transmission line has TRAN model. It's need to implement similar for miscrostrips. Contribution is welcome here. Could be a good BS or MS thesis project for someone.
The following devices need to add transient model:
The text was updated successfully, but these errors were encountered: