When you say you used a "G" source, what do you mean? G is a current source and E is a voltage source . Norton versus Thevenin. Are you saying internal calculations use G to simplify the math but the output file uses E?
The following lib file fragment was generated by your program. E source is used.
I haven't had a lot of free time. Frankly, I don't know enough about ngSpice to test the proposed workaround. In my opinion, the "right" thing to do would be to have ngSpice accept the E or G source with table driven frequency dependent multiplication by the reference nodal voltage. For AC analysis this devolves to doing one extra complex multiply per source for each frequency. There is some trickyness in interpolating the complex numbers in the frequency domain but that's not too hard to get right.
The real challenge is .TRAN analysis. LTspice gets that right a lot more often than one would think and it is very useful.
I can modify S2spice to create a .MODEL frequency table as proposed in this thread but don't have any way to test it because I don't know how to add the new model code to ngSpice. If someone wants to do that and then do the testing I can work on having S2spice create the .MODEL data. If possible, I would like a simple but fully working circuit file that shows the new .MODEL statement for several frequencies so I can verify S2spice is producing the right stuff.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Small-Signal" S-parameter data is measured and processed by a VNA. As such "AC" analysis is appropriate.
"Large-Signal" S-parameter data required for TRAN analysis is another kettle of fish and very few manufacturers provide it.
If I have both Spice and S-parameter data for a device, I use both to compare the results. Qucs and QucsStudio allow this. Without a conversion program, Qucs-S via ngspice doesn't.
Holger (h_vogt)
Is there any way Dan's suggestions can be implemented?
Last edit: Tom Hajjar 2023-04-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I made a prototype implementation of what I think is the required function. It is in two parts:
a new XSPICE analogue code model (XSPICE device) that multiplies an input by a frequency-dependent voltage taken from a table. DC and AC are supported, but TRAN acts like DC. This is very simple.
Changes to s2spice.c, found above, so that a compatible subcircuit is generated from a Touchstone file. The syntax is different as XSPICE does not support per-device parameters; the table must be attached to a .model line.
The results seem reasonable, but I am somewhat hampered in testing by a lack of good test material and RF experience. One somewhat convincing test is to place the generated subcircuit in a simulation and run a SP analysis. If the frequencies align, the original S-parameters should be recovered. That seems to work.
If this approach seems good, some further work may make it suitable for integration:
handle the table format keywords (currently only R_I works);
add conversion of the EFREQ P/Ltspice devices to netlist parsing;
make TRAN work.
I am not convinced that the last one is worth the effort, but there should be at least a warning message.
The attached file contains the code and some simple circuits. It should be expanded at ngspice/src/xspice/icm/analog to add the XSPICE component, xfer.
I have some interest in this effort but I am having issues with getting it to work.
I enclose a testcase:
test5.cir : testcase, notice two different subcircuits can be selectively included
FL455kHz.s2p : S-parameter data, originally from measurements
FL455kHz.lib : XSPICE compatible model generated with provided s2spice.c code. Hand modified to remove zero frequency entries with "-inf" value.
FL455kHz.net : Simulation compatible netlist obtained via MATLAB synthesis of S-parameters to SPICE. Select this instead in test5.cir to see functionality.
FL455kHz.cir : PSPICE version from a different version of s2spice.c that I downloaded from the web. Not directly useful by can be compared to FL455kHz.lib. Nothing seems amiss between the two.
The simulation results for FL455kHz.lib are not correct.
I am using the s2spice.c code included in xfer.zip provided by Giles.
I set:
1) #define PREFER_DB
2) # //define PSPICE
I have a gain/phase type S-parameter file and I want NGSPICE format, not PSPICE.
I believe this is required to get an XSPICE compliant model (A initial character). My understanding is that the VCVS (E initial character) format you are showing is a PSPICE and perhaps other simulator compatible methodology.
As the QUCS results you are showing based on NGSPICE simulations ?
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have resolved my issue with the enclosed updates to s2spice.c
It was not properly handling case where R/I output was requested with gain/phase input .
This now shows the NGSPICE simulation results of the XSPICE S-parameter model and my MATLAB derived netlist.
I don't know what I'm doing wrong. I used DuSpice to launch ngspice. Getting the following error.
Error on line:
a.x_x0.a11 %vd x_x0.10 0 %vd x_x0.11 x_x0.12 x_x0:xfer1
MIF-ERROR - unable to find definition of model x_x0:xfer1
Simulation interrupted due to error!
I believe this is indicating the xfer code model provided by Giles in xfer.zip has not been added to the NGSPICE executable. See manual section 28. I placed his code in the directory he indicated and used the compile_linux.sh script which worked well.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With this .lib example I believe I can modify the Windows s2spice to produce this format. It is sufficiently similar to what it does not that it should not be that hard. Really busy these days so give me a little time and I will come back when I have something to test.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@gatk555, Please submit your XSPICE device to the Ngspice upstream to make it available for all Ngspice users. The out-of-tree build of XSPICE models is broken at least in the version distributed with Ubuntu. Now it requires to recompile an entire Ngspice to add external XSPICE device. It is user unfriendly. Once your model will be submitted to upstream it will be available for all users without need to compile anything. Once this frequency dependent XSPICE source will be available in the Ngspice upstream I will add a GUI entry to the Qucs-S. So it fills the gap and will add the support of the S2P defined device.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now it requires to recompile an entire Ngspice to add external XSPICE device. It is user unfriendly.
This statement is surely exxagerated. Re-compilation of ngspice by ./compile_linux.sh takes 1 min on my machine. And you have or are going to cancel the XSPICE generator in QUCS-S.
We will put a code model into the standard distribution when it is ready and when it has been tested.
I would like to ask you to test it and provide the results here.
Finally ngspice will support E and G sources with the freq option (by adding a translator from E, G to A), as we already have for other PSPICE/LTSPICE components like the VSWITCH.
So please provide test results (as we ngspice developers are not RF specialists).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I consider the XSPICE code to be very much unfinished, so much so that it is not even committed to my local repository. I do not expect to look at it again very soon, but anyone is welcome to pick this up..
If it will aid experiment, I can post my binary of analog.cm. It is built on Debian stable so I would expect it to work on Ubuntu. Indeed, as the only dependency is glibc6, it will probably be fine on any X86-64 Linux. For Windows I have 32 and 64-bit builds, but made with MINGW, so may not play with the standard builds.
Before much effort is put into re-writing tools, I should repeat that the original plan is to add code to ngspice's netlist parser that rewrites the PSPICE syntax to this new form. There is plenty of precedent for that, so it should not be difficult. (Indeed the PSPICE-compatible digital U-devices are implemented entirely by rewriting.) Holger also mentioned this, above.
One future possibility should be mentioned. It seems possible to add two parameters, "span" and "offset", to the XSPICE model so that it can pick values from the table selectively. Then standard sub-circuits can be written for common cases that can be used directly, with no re-writing tool.
So the syntax for a two-port "black box" defined by S-parameters might become:
xsp p1 p2 0 sp2 table = {
...
The only issue I see is that there will be multiple copies of a possibly large table in memory. That may be avoided if XSPICE models gain per-instance parameters.
Giles
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a number RF analysis where I have both manufacturer supplied S-parameter files and Spice models of active devices. The resultant test data is never the same however.
Qucs can export S-parameter data in Touchstone file format using "qucsconv" so one can create an S-parameter file from any active/passive circuit. This feature is not in Qucs-S.
The CM files should be compiled with the same compiler version as Ngspice itseltf. Otherwise you will get application crash. I faced similar errors while experimenting with other XSPICE models. The same is valid for Windows version. Providing the CM file will not help users. I am able to recompile the Ngspice, so I will probably provide some feedback in the future on your new device operation.
So, I am waiting for the final solution that may be accepted for Qucs-S.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The XSPICE code model and parsing/translation code is available in Sourceforge branch ga_sp_dev. It would be helpful if this gets some independent testing before being considered for merging.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dan
When you say you used a "G" source, what do you mean? G is a current source and E is a voltage source . Norton versus Thevenin. Are you saying internal calculations use G to simplify the math but the output file uses E?
The following lib file fragment was generated by your program. E source is used.
E0101 101 102 FREQ {V(100,3)}= MAG
+( 4.000000e+07Hz, 7.540000e-01, -1.500000e+01)
Last edit: Tom Hajjar 2023-03-06
Dan
Did you have a chance to revisit this?
I haven't had a lot of free time. Frankly, I don't know enough about ngSpice to test the proposed workaround. In my opinion, the "right" thing to do would be to have ngSpice accept the E or G source with table driven frequency dependent multiplication by the reference nodal voltage. For AC analysis this devolves to doing one extra complex multiply per source for each frequency. There is some trickyness in interpolating the complex numbers in the frequency domain but that's not too hard to get right.
The real challenge is .TRAN analysis. LTspice gets that right a lot more often than one would think and it is very useful.
I can modify S2spice to create a .MODEL frequency table as proposed in this thread but don't have any way to test it because I don't know how to add the new model code to ngSpice. If someone wants to do that and then do the testing I can work on having S2spice create the .MODEL data. If possible, I would like a simple but fully working circuit file that shows the new .MODEL statement for several frequencies so I can verify S2spice is producing the right stuff.
Dan
"Small-Signal" S-parameter data is measured and processed by a VNA. As such "AC" analysis is appropriate.
"Large-Signal" S-parameter data required for TRAN analysis is another kettle of fish and very few manufacturers provide it.
If I have both Spice and S-parameter data for a device, I use both to compare the results. Qucs and QucsStudio allow this. Without a conversion program, Qucs-S via ngspice doesn't.
Holger (h_vogt)
Is there any way Dan's suggestions can be implemented?
Last edit: Tom Hajjar 2023-04-11
I am clueless about what code is available for use but can the source for Berkeley Spice be used?
https://space.mit.edu/RADIO/CST_online/mergedProjects/DES/components/block/import/spiceimportblock.htm
I made a prototype implementation of what I think is the required function. It is in two parts:
a new XSPICE analogue code model (XSPICE device) that multiplies an input by a frequency-dependent voltage taken from a table. DC and AC are supported, but TRAN acts like DC. This is very simple.
Changes to s2spice.c, found above, so that a compatible subcircuit is generated from a Touchstone file. The syntax is different as XSPICE does not support per-device parameters; the table must be attached to a .model line.
*S11 FREQ R_I
A11 %vd(10 3) %vd(11, 12) xfer1
.model xfer1 xfer R_I=true table=
+ 1.000000e+09Hz 3.926000e-01 -1.211000e-01
+ 2.000000e+09Hz 3.517000e-01 -3.054000e-01
+ 1.000000e+10Hz 3.419000e-01 3.336000e-01
+
The results seem reasonable, but I am somewhat hampered in testing by a lack of good test material and RF experience. One somewhat convincing test is to place the generated subcircuit in a simulation and run a SP analysis. If the frequencies align, the original S-parameters should be recovered. That seems to work.
If this approach seems good, some further work may make it suitable for integration:
handle the table format keywords (currently only R_I works);
add conversion of the EFREQ P/Ltspice devices to netlist parsing;
make TRAN work.
I am not convinced that the last one is worth the effort, but there should be at least a warning message.
The attached file contains the code and some simple circuits. It should be expanded at ngspice/src/xspice/icm/analog to add the XSPICE component, xfer.
I have some interest in this effort but I am having issues with getting it to work.
I enclose a testcase:
test5.cir : testcase, notice two different subcircuits can be selectively included
FL455kHz.s2p : S-parameter data, originally from measurements
FL455kHz.lib : XSPICE compatible model generated with provided s2spice.c code. Hand modified to remove zero frequency entries with "-inf" value.
FL455kHz.net : Simulation compatible netlist obtained via MATLAB synthesis of S-parameters to SPICE. Select this instead in test5.cir to see functionality.
FL455kHz.cir : PSPICE version from a different version of s2spice.c that I downloaded from the web. Not directly useful by can be compared to FL455kHz.lib. Nothing seems amiss between the two.
The simulation results for FL455kHz.lib are not correct.
Any feedback would be appreciated.
Jim
Can you explain what modifications you did to s2spice.c so it generates FL455kHz.lib:
*S11 FREQ DB PHASE
A11 %vd(10 3) %vd(11 12) xfer1
.model xfer1 xfer DB=true table=[
+ 4.250000e+05Hz -1.180771e+00 -1.283063e+02
Versus FL455kHz_S2spice.lib I created using the Windows version of S2spice by Dan Dicky
*S11 FREQ MAG
E0101 101 102 FREQ {V(100,3)}= MAG
+( 4.250000e+05Hz, 8.728939e-01, -1.283063e+02)
Attached is a plot of FL455kHz.s2p done in Qucs 0.0.20
Last edit: Tom Hajjar 2023-04-21
Tom
I am using the s2spice.c code included in xfer.zip provided by Giles.
I set:
1) #define PREFER_DB
2) # //define PSPICE
I have a gain/phase type S-parameter file and I want NGSPICE format, not PSPICE.
I believe this is required to get an XSPICE compliant model (A initial character). My understanding is that the VCVS (E initial character) format you are showing is a PSPICE and perhaps other simulator compatible methodology.
As the QUCS results you are showing based on NGSPICE simulations ?
Thanks
"As the QUCS results you are showing based on NGSPICE simulations ?"
Results are using the "Qucs" simulation engine Qucsator not ngspice. I just wanted to confirm what the S-parameter and phase data looked like.
Hoping for a solution to this issue so I can use only Qucs-S and ngspice.
Qucsator is unusable for even simple TRANS simulations so it's a deal killer....
I just noticed this key sentence in Giles' post:
handle the table format keywords (currently only R_I works);
I am trying to use gain/phase and not real/imag.
This is likely my issue...
I have resolved my issue with the enclosed updates to s2spice.c
It was not properly handling case where R/I output was requested with gain/phase input .
This now shows the NGSPICE simulation results of the XSPICE S-parameter model and my MATLAB derived netlist.
Proper 455kHz.lib also now attached.
Proper 455kHz.lib also now attached with actual attachment.
I don't know what I'm doing wrong. I used DuSpice to launch ngspice. Getting the following error.
Error on line:
a.x_x0.a11 %vd x_x0.10 0 %vd x_x0.11 x_x0.12 x_x0:xfer1
MIF-ERROR - unable to find definition of model x_x0:xfer1
Simulation interrupted due to error!
I believe this is indicating the xfer code model provided by Giles in xfer.zip has not been added to the NGSPICE executable. See manual section 28. I placed his code in the directory he indicated and used the compile_linux.sh script which worked well.
This is fabulous progress. Since I'm a Windows user, a few things need to happen.
Windows version of ngspice with the new capability
Windows version of S2spice updated to offer ltspice or ngspice output file format.
With this .lib example I believe I can modify the Windows s2spice to produce this format. It is sufficiently similar to what it does not that it should not be that hard. Really busy these days so give me a little time and I will come back when I have something to test.
@gatk555, Please submit your XSPICE device to the Ngspice upstream to make it available for all Ngspice users. The out-of-tree build of XSPICE models is broken at least in the version distributed with Ubuntu. Now it requires to recompile an entire Ngspice to add external XSPICE device. It is user unfriendly. Once your model will be submitted to upstream it will be available for all users without need to compile anything. Once this frequency dependent XSPICE source will be available in the Ngspice upstream I will add a GUI entry to the Qucs-S. So it fills the gap and will add the support of the S2P defined device.
See also discussion in the Qucs-S issue tracker on the S2P device support: https://github.com/ra3xdh/qucs_s/issues/233
This statement is surely exxagerated. Re-compilation of ngspice by ./compile_linux.sh takes 1 min on my machine. And you have or are going to cancel the XSPICE generator in QUCS-S.
We will put a code model into the standard distribution when it is ready and when it has been tested.
I would like to ask you to test it and provide the results here.
Finally ngspice will support E and G sources with the freq option (by adding a translator from E, G to A), as we already have for other PSPICE/LTSPICE components like the VSWITCH.
So please provide test results (as we ngspice developers are not RF specialists).
Vadim,
I consider the XSPICE code to be very much unfinished, so much so that it is not even committed to my local repository. I do not expect to look at it again very soon, but anyone is welcome to pick this up..
If it will aid experiment, I can post my binary of analog.cm. It is built on Debian stable so I would expect it to work on Ubuntu. Indeed, as the only dependency is glibc6, it will probably be fine on any X86-64 Linux. For Windows I have 32 and 64-bit builds, but made with MINGW, so may not play with the standard builds.
Before much effort is put into re-writing tools, I should repeat that the original plan is to add code to ngspice's netlist parser that rewrites the PSPICE syntax to this new form. There is plenty of precedent for that, so it should not be difficult. (Indeed the PSPICE-compatible digital U-devices are implemented entirely by rewriting.) Holger also mentioned this, above.
One future possibility should be mentioned. It seems possible to add two parameters, "span" and "offset", to the XSPICE model so that it can pick values from the table selectively. Then standard sub-circuits can be written for common cases that can be used directly, with no re-writing tool.
So the syntax for a two-port "black box" defined by S-parameters might become:
xsp p1 p2 0 sp2 table = {
...
The only issue I see is that there will be multiple copies of a possibly large table in memory. That may be avoided if XSPICE models gain per-instance parameters.
Giles
I have a number RF analysis where I have both manufacturer supplied S-parameter files and Spice models of active devices. The resultant test data is never the same however.
Qucs can export S-parameter data in Touchstone file format using "qucsconv" so one can create an S-parameter file from any active/passive circuit. This feature is not in Qucs-S.
Last edit: Tom Hajjar 2023-04-23
The CM files should be compiled with the same compiler version as Ngspice itseltf. Otherwise you will get application crash. I faced similar errors while experimenting with other XSPICE models. The same is valid for Windows version. Providing the CM file will not help users. I am able to recompile the Ngspice, so I will probably provide some feedback in the future on your new device operation.
So, I am waiting for the final solution that may be accepted for Qucs-S.
The XSPICE code model and parsing/translation code is available in Sourceforge branch ga_sp_dev. It would be helpful if this gets some independent testing before being considered for merging.