ngspice-devel — Ngspice development list (developers are here).

Re: [Ngspice-devel] [PATCH] Add -flags switch to devhelp command to display flags

[Mikołaj W. <wie...@gm...>]

I've sent a patch to the manual to document the command. Sorry for
taking so long.

-Mikolaj

[Ngspice-devel] [PATCH] Document the new devhelp switches (-flags and -type)

[Mikolaj W. <wie...@gm...>]

---
 manual.lyx | 96 +++++++++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 88 insertions(+), 8 deletions(-)

diff --git a/manual.lyx b/manual.lyx
index 558dee0..f0cfd90 100644
--- a/manual.lyx
+++ b/manual.lyx
@@ -98524,7 +98524,7 @@ status open

 \begin_layout Plain Layout

-devhelp [[-csv | -flags | -type] device_name [parameter]]
+devhelp [-csv] [-type] [-flags] [device_name [parameter]]
 \end_layout

 \end_inset
@@ -98607,25 +98607,100 @@ The
 \family typewriter
 -csv
 \family default
- option prints the fields separated by a comma, for direct import into a
+ option prints the fields, separated by commas, for direct import into a
  spreadsheet.
  This option is used to generate the simulator documentation.

 \end_layout

+\begin_layout Standard
+The
+\family typewriter
+-type
+\family default
+ option prints the type of each parameter, for example
+\family typewriter
+real
+\family default
+,
+\family typewriter
+integer
+\family default
+,
+\family typewriter
+string
+\family default
+.
+ Values ending with
+\family typewriter
+vec
+\family default
+ indicate vectors.
+\end_layout
+
 \begin_layout Standard
 The
 \family typewriter
 -flags
 \family default
- option prints some internal information on parameters, as defined for example
- by macro IOPU in bjt.c.
- The
+ option prints the internal Spice flags for each parameter.
+ A specific string is appended to the result for each flag:
+\end_layout
+
+\begin_layout Description
+X the parameter is not used in sensitivity analysis.
+\end_layout
+
+\begin_layout Description
+Q the parameter must be non-zero for sensitivity analysis of the subsequent
+ parameter.
+\end_layout
+
+\begin_layout Description
+Z the previous parameter must be non-zero for sensitivity analysis.
+\end_layout
+
+\begin_layout Description
+QO Like Q, but or-ed with the previous Q value.
+\end_layout
+
+\begin_layout Description
+A the parameter is significant for time-varying (non-DC) analyses.
+\end_layout
+
+\begin_layout Description
+P the parameter is a principal of the device.
+ Used for naming output variables in sensitivity.
+\end_layout
+
+\begin_layout Description
+AA the parameter is significant for AC analyses only.
+\end_layout
+
+\begin_layout Description
+N the parameter is significant for noise analyses only.
+\end_layout
+
+\begin_layout Description
+U the parameter is not shown in the default
 \family typewriter
--type
+show
+\family default
+ command output.
+\end_layout
+
+\begin_layout Description
+R redundant parameter name (e.g.
+
+\family typewriter
+vto
 \family default
- option prints some internal information on parameters, as defined for example
- by macro IF_REAL in bjt.c.
+ vs.
+
+\family typewriter
+vt0
+\family default
+).
 \end_layout

 \begin_layout Standard
@@ -98671,6 +98746,11 @@ devhelp resistor
 devhelp capacitor ic
 \end_layout

+\begin_layout Plain Layout
+
+devhelp -flags -type bjt
+\end_layout
+
 \end_inset


-- 
2.35.1

[Ngspice-devel] [PATCH] Few minor typo and grammar edits

[Mikolaj W. <wie...@gm...>]

---
 manual.lyx | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/manual.lyx b/manual.lyx
index 83cb297..a4adf6e 100644
--- a/manual.lyx
+++ b/manual.lyx
@@ -5281,7 +5281,7 @@ If input lines get overly long, they may be
split into two or more lines
  (e.g.
  for better readability).
  Internally they will be merged into a single line.
- Each follow-up line starts with charachter '+ ' plus additional space.
+ Each follow-up line starts with character '+' plus additional space.
  Follw-up lines have to follow immediately after each other.
  End-of-line comments will be ignored.
  The following lines do not allow using continuation lines:
@@ -9945,11 +9945,11 @@ Nesting of
 \family typewriter
 .elseif
 \family default
- are allowed per block, of course only one
+ (but of course only one
 \family typewriter
 .else
 \family default
- (please see example
+) are allowed per block (please see example
 \family sans
  ngspice/tests/regression/misc/if-elseif.cir
 \family default
@@ -27250,7 +27250,7 @@ Propagation Constant
 \begin_inset Text

 \begin_layout Plain Layout
-2.0
+1.5
 \end_layout

 \end_inset
@@ -40346,7 +40346,7 @@ HICUM level 0 Model
 \begin_layout Standard
 The HIgh-CUrrent Model (HICUM) Level0 (L0) is a simplified version of the
  HICUM level 2 model.
- Ngspice has implemented version 1.32 in his experimental ADMS tree.
+ Ngspice has implemented version 1.32 in its experimental ADMS tree.
  It will be activated by the BJT model parameter level=7.
 \end_layout

@@ -85730,9 +85730,9 @@ reference "subsec:Circuit-elements-(device"
 ).
  For M only MOSFET models MOS1 to MOS9 are included so far.
  Devices in subcircuits are supported as well.
- The advantage of the data obtained by .savecurrents is that no extra nodes
- are required, because the data are retrieved from internal nodes alraedy
- existing.
+ The advantage of the data obtained by .options savecurrents is that no extra
+ nodes are required, because the data are retrieved from internal nodes
+ alraedy existing.

 \end_layout

@@ -107223,7 +107223,7 @@ netlist for default bipolar transistor

 \begin_layout Plain Layout

-Q1 cc bb ee defbib
+Q1 cc bb ee defbip
 \end_layout

 \begin_layout Plain Layout
@@ -122626,7 +122626,7 @@ The following commands are used to start the
simulator in its own thread,
  tasks in the main thread, e.g.
  watching its own event loop.
  Of course you have to take care that the caller will not exit before ngspice
- is finished, otherwise you immediately will loose all data.
+ is finished, otherwise you immediately will lose all data.
  After having halted the simulator by suspending the background thread,
  you may assess data, change ngspice parameters, or read output data using
  the caller's main thread, before you resume simulation using a background
-- 
2.35.1

[Ngspice-devel] [PATCH] Fix syntax error (unmached closing parenthesis)

[Mikolaj W. <wie...@gm...>]

---
 src/spicelib/analysis/span.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/spicelib/analysis/span.c b/src/spicelib/analysis/span.c
index b895dfd9c..d01e8b97e 100644
--- a/src/spicelib/analysis/span.c
+++ b/src/spicelib/analysis/span.c
@@ -894,7 +894,7 @@ SPan(CKTcircuit* ckt, int restart)

         /* gtri - modify - wbk - 12/19/90 - Send IPC stuff */
 #else
-        error = CKTspDump(ckt, freq, spPlot, job->SPdoNoise));
+        error = CKTspDump(ckt, freq, spPlot, job->SPdoNoise);
 #endif
         if (error) {
             UPDATE_STATS(DOING_AC);
-- 
2.35.1

[Ngspice-devel] S-parameter simulation Qucs-S+Ngspice

[Vadim K. <ra...@gm...>]

Hello Ngspice developers,

I have just added the Ngspice S-parameter simulation support in Qucs-S. 
Now it could be used with Ngspice-36+ from s-parameters-2 branch. The 
both simple S-parameter analysis and noise anylysis are supported. You 
need to compile Qucs-S from git (branch "current") to get access to this 
feature. See https://github.com/ra3xdh/qucs_s/issues/84 for context. I 
have also uploaded some example schematics illustrating the usage of the 
new feature.

Regards,
Vadim

Re: [Ngspice-devel] Patch for S-parameters simulation

[Holger V. <hol...@un...>]

Vadim,

thanks for the patch.

Uploaded to pre-master branch.

Holger

[Ngspice-devel] Patch for S-parameters simulation

[Vadim K. <ra...@gm...>]

Hello Ngspice developers,

Currently I am working on the S-parameter simulation support for Qucs-S. 
See https://github.com/ra3xdh/qucs_s/issues/84 for context. I have 
recently discovered that the S-parameter simulation cannot be executed 
from the .control section like this:

.control
sp dec 100 1 1e6 0
.endc

This is possible for other simulations like AC and TRAN, but not 
possible for SP. The Qucs-S relies on this behavior for netlisting and I 
have prepared a patch that fixes this issue. See the patch below. This 
patch should be applied on the "s-parameters" branch.

Regards,
Vadim Kuznetsov

 From eae489f8e45d8e6e70e4a95df8476ab5a84dc3ca Mon Sep 17 00:00:00 2001
From: Vadim Kuznetsov <ra...@gm...>
Date: Sat, 26 Mar 2022 13:16:44 +0100
Subject: [PATCH] Enable running .sp from control section

---
  src/frontend/spiceif.c | 6 ++++++
  1 file changed, 6 insertions(+)

diff --git a/src/frontend/spiceif.c b/src/frontend/spiceif.c
index dd6f1c51c..26079b3b2 100644
--- a/src/frontend/spiceif.c
+++ b/src/frontend/spiceif.c
@@ -343,6 +343,12 @@ if_run(CKTcircuit *ckt, char *what, wordlist *args, 
INPtables *tab)
          /* SP: Steady State Analysis */
          (eq(what, "pss")) ||
          /* SP */
+#endif
+#ifdef RFSPICE
+        (eq(what, "sp")) ||
+#ifdef WITH_HB
+        (eq(what, "hb")) ||
+#endif
  #endif
          (eq(what, "run")))
      {
-- 
2.17.1

Re: [Ngspice-devel] [PATCH] Add -flags switch to devhelp command to display flags

[Holger V. <hol...@un...>]

Mikolaj,

I have applied your patches to my local pre-master branch. Looks good so 
far. Before uploading:

Do you have a test netlist to show the new options for the devhelp command?

Could you perhaps also provide a short (informal) update to chapter 
17.5.20 Devhelp of our ngspice manual?

Holger

Re: [Ngspice-devel] Digital bidir ports and A/D or D/A in Xspice

[Holger V. <hol...@un...>]

Brian,

Florian Ballenegger suggests to try an approach with existing elements: 
ADC bridge, DAC bridge, digital tri-state buffer and an ideal analog switch.

He is probably right. You may check it out. If not possible, there is 
still a chance to achieve something with generating a new code model.

Holger

Re: [Ngspice-devel] Digital bidir ports and A/D or D/A in Xspice

[Holger V. <hol...@un...>]

Brian,

I guess the best would be to create a new D/A-A/D interface, with a 
logic input to select the direction.

I will have a look.

Holger

[Ngspice-devel] Fwd: Digital bidir ports and A/D or D/A in Xspice

[Brian T. <lb...@co...>]

Sorry, I forgot to subscribe to the devel list.

Here we go again.

-------- Forwarded Message --------
Subject: 	Digital bidir ports and A/D or D/A in Xspice
Date: 	Wed, 16 Mar 2022 12:23:22 -0700
From: 	Brian Taylor <lb...@co...>
To: 	ngs...@li...



I am trying to figure out how to use Xspice adc_bridge and dac_bridge
devices to provide A/D and D/A interfaces for a subckt which has
bidirectional digital ports. This question arises when mapping U* Pspice
elements into Xspice A*.

One circuit is 74als1242 shown at the end:

.subckt 74als1242 gabbar gba a1 a2 a3 a4 b1 b2 b3 b4

from the MicroCap/Pspice digital library dig874.
The a*, b* are bidir ports, I think.

Roughly, the subckt maps to ngspice/Xspice inverter and tristate elements:

      a* ==> INVERTERS (1 per bit) ==> TRISTATE_BUFS (1 per bit) ==> b*
          TRISTATES anabled by NOT gabbar (== gab internally)

      b* ==> INVERTERS (1 per bit) ==> TRISTATE_BUFS (1 per bit) ==> a*
          TRISTATES enabled by gba

When gabbar == 0 and gba == 0, data flows a* ==> b*
When gabbar == 1 and gba == 1, data flows b* ==> a*

For a digital only translated subckt there is no problem. If the ports
are analog, then inputs gabbar and gba can use adc_bridge for A/D.
But how would you provide A/D or D/A for the a*, b* depending on the
direction of the digital signals? Without splitting the a*, b* ports
into separate inputs and outputs which would change the signature of the
subckt? There is no bidir_bridge in Xspice (yet.)

I would appreciate any ideas.

Regards, Brian Taylor

* ----------------------------------------------------------- 74ALS1242 
------
*  Quad Bus Transceivers With 3-State Outputs
*
*  The ALS/AS Logic Data Book, 1986, TI Pages 2-877 to 2-880
*  bss    6/27/94
*
.SUBCKT 74ALS1242 GABBAR GBA A1 A2 A3 A4 B1 B2 B3 B4
+     optional:  DPWR=$G_DPWR DGND=$G_DGND
+     params:  MNTYMXDLY=0 IO_LEVEL=0

U1 inv DPWR DGND
+     GABBAR GAB
+     D0_GATE IO_ALS000 MNTYMXDLY={MNTYMXDLY} IO_LEVEL={IO_LEVEL}

U2 inv3a(4) DPWR DGND
+     A1 A2 A3 A4
+     GAB
+     B1 B2 B3 B4
+     DLY_ALS1242AB IO_ALS000 MNTYMXDLY={MNTYMXDLY} IO_LEVEL={IO_LEVEL}

U3 inv3a(4) DPWR DGND
+     B1 B2 B3 B4
+     GBA
+     A1 A2 A3 A4
+     DLY_ALS1242BA IO_ALS000 MNTYMXDLY={MNTYMXDLY} IO_LEVEL={IO_LEVEL}

.model DLY_ALS1242AB utgate (tplhMN=2ns tplhTY=6ns tplhMX=12ns
+                                 tphlMN=2ns tphlTY=5ns tphlMX=10ns
+                                 tpzhMN=4ns tpzhTY=10ns tpzhMX=17ns
+                                 tpzlMN=5ns tpzlTY=13ns tpzlMX=21ns
+                                 tphzMN=2ns tphzTY=6ns tphzMX=10ns
+                                 tplzMN=2ns tplzTY=5ns tplzMX=10ns)

.model DLY_ALS1242BA utgate (tplhMN=2ns tplhTY=6ns tplhMX=12ns
+                                 tphlMN=2ns tphlTY=5ns tphlMX=10ns
+                                 tpzhMN=5ns tpzhTY=12ns tpzhMX=20ns
+                                 tpzlMN=6ns tpzlTY=14ns tpzlMX=23ns
+                                 tphzMN=2ns tphzTY=6ns tphzMX=10ns
+                                 tplzMN=2ns tplzTY=6ns tplzMX=12ns)

.ENDS 74ALS1242

[Ngspice-devel] Digital bidir ports and A/D or D/A in Xspice

[Brian T. <lb...@co...>]

I am trying to figure out how to use Xspice adc_bridge and dac_bridge
devices to provide A/D and D/A interfaces for a subckt which has
bidirectional digital ports. This question arises when mapping U* Pspice
elements into Xspice A*.

One circuit is 74als1242 shown at the end:

.subckt 74als1242 gabbar gba a1 a2 a3 a4 b1 b2 b3 b4

from the MicroCap/Pspice digital library dig874.
The a*, b* are bidir ports, I think.

Roughly, the subckt maps to ngspice/Xspice inverter and tristate elements:

      a* ==> INVERTERS (1 per bit) ==> TRISTATE_BUFS (1 per bit) ==> b*
          TRISTATES anabled by NOT gabbar (== gab internally)

      b* ==> INVERTERS (1 per bit) ==> TRISTATE_BUFS (1 per bit) ==> a*
          TRISTATES enabled by gba

When gabbar == 0 and gba == 0, data flows a* ==> b*
When gabbar == 1 and gba == 1, data flows b* ==> a*

For a digital only translated subckt there is no problem. If the ports
are analog, then inputs gabbar and gba can use adc_bridge for A/D.
But how would you provide A/D or D/A for the a*, b* depending on the
direction of the digital signals? Without splitting the a*, b* ports
into separate inputs and outputs which would change the signature of the
subckt? There is no bidir_bridge in Xspice (yet.)

I would appreciate any ideas.

Regards, Brian Taylor

* ----------------------------------------------------------- 74ALS1242 
------
*  Quad Bus Transceivers With 3-State Outputs
*
*  The ALS/AS Logic Data Book, 1986, TI Pages 2-877 to 2-880
*  bss    6/27/94
*
.SUBCKT 74ALS1242 GABBAR GBA A1 A2 A3 A4 B1 B2 B3 B4
+     optional:  DPWR=$G_DPWR DGND=$G_DGND
+     params:  MNTYMXDLY=0 IO_LEVEL=0

U1 inv DPWR DGND
+     GABBAR GAB
+     D0_GATE IO_ALS000 MNTYMXDLY={MNTYMXDLY} IO_LEVEL={IO_LEVEL}

U2 inv3a(4) DPWR DGND
+     A1 A2 A3 A4
+     GAB
+     B1 B2 B3 B4
+     DLY_ALS1242AB IO_ALS000 MNTYMXDLY={MNTYMXDLY} IO_LEVEL={IO_LEVEL}

U3 inv3a(4) DPWR DGND
+     B1 B2 B3 B4
+     GBA
+     A1 A2 A3 A4
+     DLY_ALS1242BA IO_ALS000 MNTYMXDLY={MNTYMXDLY} IO_LEVEL={IO_LEVEL}

.model DLY_ALS1242AB utgate (tplhMN=2ns tplhTY=6ns tplhMX=12ns
+                                 tphlMN=2ns tphlTY=5ns tphlMX=10ns
+                                 tpzhMN=4ns tpzhTY=10ns tpzhMX=17ns
+                                 tpzlMN=5ns tpzlTY=13ns tpzlMX=21ns
+                                 tphzMN=2ns tphzTY=6ns tphzMX=10ns
+                                 tplzMN=2ns tplzTY=5ns tplzMX=10ns)

.model DLY_ALS1242BA utgate (tplhMN=2ns tplhTY=6ns tplhMX=12ns
+                                 tphlMN=2ns tphlTY=5ns tphlMX=10ns
+                                 tpzhMN=5ns tpzhTY=12ns tpzhMX=20ns
+                                 tpzlMN=6ns tpzlTY=14ns tpzlMX=23ns
+                                 tphzMN=2ns tphzTY=6ns tphzMX=10ns
+                                 tplzMN=2ns tplzTY=6ns tplzMX=12ns)

.ENDS 74ALS1242

[Ngspice-devel] [PATCH] Add -flags switch to devhelp command to display flags

[Mikolaj W. <wie...@gm...>]

The `IFparm` struct holds some flags that are be used to determine
whether a parameter is superfluous, uninteresting to display, or not
applicable to a given simulation type. This patch makes it possible to
read these flags by passing a -flags switch to the devhelp command
---
This patch is to be applied on top of the previous patch I sent to this
mailing list

 src/frontend/device.c | 167 ++++++++++++++++++++++++++++--------------
 src/frontend/device.h |   4 +-
 2 files changed, 113 insertions(+), 58 deletions(-)

diff --git a/src/frontend/device.c b/src/frontend/device.c
index aef4f9974..9ff7a865c 100644
--- a/src/frontend/device.c
+++ b/src/frontend/device.c
@@ -39,6 +39,7 @@ static void if_set_binned_model(CKTcircuit *, char
*, char *, struct dvec *);
  *   devhelp devname parname : shows parameter meaning
  *   Options: -csv (comma separated value for generating docs)
  *            -type (show parameter types)
+ *            -flags (show parameter flags)
  */

 void
@@ -55,8 +56,9 @@ devhelp(wordlist *wl)
     int i, k = 0;
     int devindex = -1, devInstParNo = 0, devModParNo = 0;
     bool found = FALSE;
-    bool csv = FALSE;
-    bool type = FALSE;
+    bool print_type = FALSE;
+    bool print_flags = FALSE;
+    bool print_csv = FALSE;
     wordlist *wlist;
     IFparm *plist;

@@ -77,21 +79,20 @@ devhelp(wordlist *wl)
     }

     while (TRUE) {
-        /* -csv or -type options can be passed as the initial arguments */
+        /* -type, -csv, -flags options can be passed as the initial
arguments */
         if (wlist && wlist->wl_word && eq(wlist->wl_word, "-type")) {
-            type = TRUE;
-            if (wlist->wl_next)
-                wlist = wlist->wl_next;
-            else
-                return;
+            print_type = TRUE;
+        } else if (wlist && wlist->wl_word && eq(wlist->wl_word, "-flags")) {
+            print_flags = TRUE;
         } else if (wlist && wlist->wl_word && eq(wlist->wl_word, "-csv")) {
-            csv = TRUE;
-            if (wlist->wl_next)
-                wlist = wlist->wl_next;
-            else
-                return;
+            print_csv = TRUE;
         } else
             break;
+
+        if (wlist->wl_next)
+            wlist = wlist->wl_next;
+        else
+            return;
     }

     /* This argument, if exists, must be the device name */
@@ -134,8 +135,8 @@ devhelp(wordlist *wl)
                 found = TRUE;
                 out_init();
                 out_printf("Model Parameters\n");
-                printheaders(type, csv);
-                printdesc(plist[i], type, csv);
+                printheaders(print_type, print_flags, print_csv);
+                printdesc(plist[i], print_type, print_flags, print_csv);
                 out_send("\n");
             }
         }
@@ -147,7 +148,7 @@ devhelp(wordlist *wl)
                     found = TRUE;
                     out_init();
                     out_printf("Instance Parameters\n");
-                    printdesc(plist[i], type, csv);
+                    printdesc(plist[i], print_type, print_flags, print_csv);
                     out_send("\n");
                 }
             }
@@ -163,18 +164,18 @@ devhelp(wordlist *wl)
     out_init();
     out_printf("%s - %s\n\n", ft_sim->devices[devindex]->name,
ft_sim->devices[devindex]->description);
     out_printf("Model Parameters\n");
-    printheaders(type, csv);
+    printheaders(print_type, print_flags, print_csv);

     plist = ft_sim->devices[devindex]->modelParms;
     for (i = 0; i < devModParNo; i++)
-        printdesc(plist[i], type, csv);
+        printdesc(plist[i], print_type, print_flags, print_csv);
     out_printf("\n");
     out_printf("Instance Parameters\n");
-    printheaders(type, csv);
+    printheaders(print_type, print_flags, print_csv);

     plist = ft_sim->devices[devindex]->instanceParms;
     for (i = 0; i < devInstParNo; i++)
-        printdesc(plist[i], type, csv);
+        printdesc(plist[i], print_type, print_flags, print_csv);

     out_send("\n");
 }
@@ -185,16 +186,28 @@ devhelp(wordlist *wl)
  */

 void
-printheaders(bool type, bool csv)
+printheaders(bool print_type, bool print_flags, bool csv)
 {
-    if (type && csv)
-        out_printf("id#, Name, Dir, Type, Description\n");
-    else if (type && !csv)
-        out_printf("%5s\t %-10s\t Dir\t %-10s\t Description\n",
"id#", "Name", "Type");
-    else if (!type && csv)
-        out_printf("id#, Name, Dir, Description\n");
-    else /* !type && !csv */
-        out_printf("%5s\t %-10s\t Dir\t Description\n", "id#", "Name");
+    if (csv)
+        out_printf("id#, Name, Dir, ");
+    else
+        out_printf("%5s\t %-10s\t Dir\t ", "id#", "Name");
+
+    if (print_type) {
+        if (csv)
+            out_printf("Type, ");
+        else
+            out_printf("%-10s\t ", "Type");
+    }
+
+    if (print_flags) {
+        if (csv)
+            out_printf("Flags, ");
+        else
+            out_printf("%-6s\t ", "Flags");
+    }
+
+    out_printf("Description\n");
 }


@@ -204,25 +217,27 @@ printheaders(bool type, bool csv)
  */

 void
-printdesc(IFparm p, bool type, bool csv)
+printdesc(IFparm p, bool print_type, bool print_flags, bool csv)
 {
     char sep;
-    int spacer1, spacer2, spacer3;
+    int id_spacer, keyword_spacer, type_spacer, flags_spacer;

     /* First we indentify the separator */
     if (csv) {
         sep = ',';
-        spacer1 = 0;
-        spacer2 = 0;
-        spacer3 = 0;
+        id_spacer = 0;
+        keyword_spacer = 0;
+        type_spacer = 0;
+        flags_spacer = 0;
     } else {
         sep = '\t';
-        spacer1 = 5;
-        spacer2 = 10;
-        spacer3 = 10;
+        id_spacer = 5;
+        keyword_spacer = 10;
+        type_spacer = 10;
+        flags_spacer = 5;
     }

-    out_printf("%*d%c %-*s%c ", spacer1, p.id, sep, spacer2, p.keyword, sep);
+    out_printf("%*d%c %-*s%c ", id_spacer, p.id, sep, keyword_spacer,
p.keyword, sep);

     if (p.dataType & IF_SET)
         if (p.dataType & IF_ASK)
@@ -232,61 +247,101 @@ printdesc(IFparm p, bool type, bool csv)
     else
         out_printf("out%c ", sep);

-    if (type) {
+    if (print_type) {
         switch (p.dataType & IF_VARTYPES) {
         case IF_FLAG:
-            out_printf("%-*s%c ", spacer3, "flag", sep);
+            out_printf("%-*s%c ", type_spacer, "flag", sep);
             break;
         case IF_INTEGER:
-            out_printf("%-*s%c ", spacer3, "integer", sep);
+            out_printf("%-*s%c ", type_spacer, "integer", sep);
             break;
         case IF_REAL:
-            out_printf("%-*s%c ", spacer3, "real", sep);
+            out_printf("%-*s%c ", type_spacer, "real", sep);
             break;
         case IF_COMPLEX:
-            out_printf("%-*s%c ", spacer3, "complex", sep);
+            out_printf("%-*s%c ", type_spacer, "complex", sep);
             break;
         case IF_NODE:
-            out_printf("%-*s%c ", spacer3, "node", sep);
+            out_printf("%-*s%c ", type_spacer, "node", sep);
             break;
         case IF_INSTANCE:
-            out_printf("%-*s%c ", spacer3, "instance", sep);
+            out_printf("%-*s%c ", type_spacer, "instance", sep);
             break;
         case IF_STRING:
-            out_printf("%-*s%c ", spacer3, "string", sep);
+            out_printf("%-*s%c ", type_spacer, "string", sep);
             break;
         case IF_PARSETREE:
-            out_printf("%-*s%c ", spacer3, "parsetree", sep);
+            out_printf("%-*s%c ", type_spacer, "parsetree", sep);
             break;
         case IF_VECTOR: /* A few variables have only the vector
vartype bit set */
-            out_printf("%-*s%c ", spacer3, "vector", sep);
+            out_printf("%-*s%c ", type_spacer, "vector", sep);
             break;
         case IF_FLAGVEC:
-            out_printf("%-*s%c ", spacer3, "flagvec", sep);
+            out_printf("%-*s%c ", type_spacer, "flagvec", sep);
             break;
         case IF_INTVEC:
-            out_printf("%-*s%c ", spacer3, "intvec", sep);
+            out_printf("%-*s%c ", type_spacer, "intvec", sep);
             break;
         case IF_REALVEC:
-            out_printf("%-*s%c ", spacer3, "realvec", sep);
+            out_printf("%-*s%c ", type_spacer, "realvec", sep);
             break;
         case IF_CPLXVEC:
-            out_printf("%-*s%c ", spacer3, "cplxvec", sep);
+            out_printf("%-*s%c ", type_spacer, "cplxvec", sep);
             break;
         case IF_NODEVEC:
-            out_printf("%-*s%c ", spacer3, "nodevec", sep);
+            out_printf("%-*s%c ", type_spacer, "nodevec", sep);
             break;
         case IF_INSTVEC:
-            out_printf("%-*s%c ", spacer3, "instvec", sep);
+            out_printf("%-*s%c ", type_spacer, "instvec", sep);
             break;
         case IF_STRINGVEC:
-            out_printf("%-*s%c ", spacer3, "stringvec", sep);
+            out_printf("%-*s%c ", type_spacer, "stringvec", sep);
             break;
         default:
-            out_printf("%-*s%c ", spacer3, "?????????", sep);
+            out_printf("%-*s%c ", type_spacer, "?????????", sep);
         }
     }

+    if (print_flags) {
+        char flags_str[20 + 1] = "";
+
+        if (p.dataType & IF_NONSENSE)
+            strncat(flags_str, "X", 20);
+
+        if (p.dataType & IF_SETQUERY)
+            strncat(flags_str, "Q", 20);
+
+        if (p.dataType & IF_CHKQUERY)
+            strncat(flags_str, "Z", 20);
+
+        if (p.dataType & IF_ORQUERY)
+            strncat(flags_str, "QO", 20);
+
+        if (p.dataType & IF_AC)
+            strncat(flags_str, "A", 20);
+
+        if (p.dataType & IF_PRINCIPAL)
+            strncat(flags_str, "P", 20);
+
+        if (p.dataType & IF_AC_ONLY)
+            strncat(flags_str, "AA", 20);
+
+        if (p.dataType & IF_NOISE)
+            strncat(flags_str, "N", 20);
+
+        if (p.dataType & IF_UNINTERESTING)
+            strncat(flags_str, "U", 20);
+
+        if (p.dataType & IF_REDUNDANT)
+            strncat(flags_str, "R", 20);
+
+        // Is empty?
+        if (flags_str[0] == '\0')
+            strncat(flags_str, "-", 20);
+
+        out_printf("%-*s%c ", flags_spacer, flags_str, sep);
+    }
+
     if (p.description)
         out_printf("%s\n", p.description);
     else
diff --git a/src/frontend/device.h b/src/frontend/device.h
index 1f8c7977b..30bada513 100644
--- a/src/frontend/device.h
+++ b/src/frontend/device.h
@@ -23,8 +23,8 @@ void old_show(wordlist *wl);

 /* DEVHELP*/
 void devhelp(wordlist *wl);
-void printheaders(bool type, bool csv);
-void printdesc(IFparm p, bool type, bool csv);
+void printheaders(bool print_type, bool print_flags, bool csv);
+void printdesc(IFparm p, bool print_type, bool print_flags, bool csv);



-- 
2.35.1

Re: [Ngspice-devel] Qucs-S 0.0.23 released

[Vadim K. <ra...@gm...>]

Hello,

the installation instruction on the Quc-S website need to be updated. It 
also refers to outdated installation root C:\SPICE for Windows package.

Regards,
Vadim


On 21.02.22 12:00, mh...@ia... wrote:
> On 2022-02-20 21:04, Vadim Kuznetsov wrote:
>> Hello Qucs and Ngspice developers and users,
>
> on https://ra3xdh.github.io/ it is stated:
>> It's recommended special build of Ngspice-26 for Windows 
>> Ngspice26_QucsS.zip .
>
> That is not a good idea.
>
>
>> The Qucs-S project is risen from the dead! I am glad to announce the
>> Qucs-S 0.0.23 release. The application is now fully ported to Qt5 and
>> could be packaged for modern Linux distribution. Qucs-S is an
>> independent package forked from Qucs-S-0.0.19 codebase.  Qucs-S is not
>> related to "modular Qucs" that has been developed by the mainline
>> project. Please note that Qucs-S doesn't provide simulation kernel and
>> it should be installed separately (Ngspice is recommended now).
>>
>>
>> The summary of the major changes:
>>     * The Qucs-S application is now fully ported to Qt5 and be
>> compiled on modern Linux distributions;
>>     * Added two new component libraries: containing two-gate MOSFET
>> and vacuum tubes (triodes and penthodes) models;
>>     * Windows binary switched to 64-bit build. The old 32-bit binaries
>> are not provided anymore;
>>     * Ngspice is now the default simulation kernel on the first
>> application start;
>>     * The Qucs-S doesn't use a shared settings file with Qucs anymore
>>
>> Also the release contains a number of bugfixes and small improvements.
>>
>>
>> I am providing source tarball, Linux AppImage, Windows binary and
>> Debian/Ubuntu OBS repository. The download links could be found on the
>> release page on GitHub:
>> https://github.com/ra3xdh/qucs_s/releases/tag/0.0.23
>>
>>
>> See also project webpage: https://ra3xdh.github.io/
>>
>>
>> For bug reports and contributions use the issue tracker:
>> https://github.com/ra3xdh/qucs_s/issues
>>
>>
>> Regards,
>>
>> Vadim

Re: [Ngspice-devel] Qucs-S 0.0.23 released

[<mh...@ia...>]

On 2022-02-20 21:04, Vadim Kuznetsov wrote:
> Hello Qucs and Ngspice developers and users,

on https://ra3xdh.github.io/ it is stated:
> It's recommended special build of Ngspice-26 for Windows 
> Ngspice26_QucsS.zip .

That is not a good idea.


> The Qucs-S project is risen from the dead! I am glad to announce the
> Qucs-S 0.0.23 release. The application is now fully ported to Qt5 and
> could be packaged for modern Linux distribution. Qucs-S is an
> independent package forked from Qucs-S-0.0.19 codebase.  Qucs-S is not
> related to "modular Qucs" that has been developed by the mainline
> project. Please note that Qucs-S doesn't provide simulation kernel and
> it should be installed separately (Ngspice is recommended now).
> 
> 
> The summary of the major changes:
>     * The Qucs-S application is now fully ported to Qt5 and be
> compiled on modern Linux distributions;
>     * Added two new component libraries: containing two-gate MOSFET
> and vacuum tubes (triodes and penthodes) models;
>     * Windows binary switched to 64-bit build. The old 32-bit binaries
> are not provided anymore;
>     * Ngspice is now the default simulation kernel on the first
> application start;
>     * The Qucs-S doesn't use a shared settings file with Qucs anymore
> 
> Also the release contains a number of bugfixes and small improvements.
> 
> 
> I am providing source tarball, Linux AppImage, Windows binary and
> Debian/Ubuntu OBS repository. The download links could be found on the
> release page on GitHub:
> https://github.com/ra3xdh/qucs_s/releases/tag/0.0.23
> 
> 
> See also project webpage: https://ra3xdh.github.io/
> 
> 
> For bug reports and contributions use the issue tracker:
> https://github.com/ra3xdh/qucs_s/issues
> 
> 
> Regards,
> 
> Vadim

[Ngspice-devel] Qucs-S 0.0.23 released

[Vadim K. <ra...@gm...>]

Hello Qucs and Ngspice developers and users,


The Qucs-S project is risen from the dead! I am glad to announce the 
Qucs-S 0.0.23 release. The application is now fully ported to Qt5 and 
could be packaged for modern Linux distribution. Qucs-S is an 
independent package forked from Qucs-S-0.0.19 codebase.  Qucs-S is not 
related to "modular Qucs" that has been developed by the mainline 
project. Please note that Qucs-S doesn't provide simulation kernel and 
it should be installed separately (Ngspice is recommended now).


The summary of the major changes:
     * The Qucs-S application is now fully ported to Qt5 and be compiled 
on modern Linux distributions;
     * Added two new component libraries: containing two-gate MOSFET and 
vacuum tubes (triodes and penthodes) models;
     * Windows binary switched to 64-bit build. The old 32-bit binaries 
are not provided anymore;
     * Ngspice is now the default simulation kernel on the first 
application start;
     * The Qucs-S doesn't use a shared settings file with Qucs anymore

Also the release contains a number of bugfixes and small improvements.


I am providing source tarball, Linux AppImage, Windows binary and 
Debian/Ubuntu OBS repository. The download links could be found on the 
release page on GitHub: 
https://github.com/ra3xdh/qucs_s/releases/tag/0.0.23


See also project webpage: https://ra3xdh.github.io/


For bug reports and contributions use the issue tracker: 
https://github.com/ra3xdh/qucs_s/issues


Regards,

Vadim

[Ngspice-devel] [PATCH] Add -type switch to devhelp command to display types

[Mikolaj W. <wie...@gm...>]

It is possible to display the ID, name, direction, and description of
each model (and instance) parameter using the `devhelp` command. For
each parameter, this information is stored in an `IFparm` struct.

However, `IFparm` also holds information about the type (e.g. flag,
integer, real, complex) of the parameter, which `devhelp` does not
display. This patch adds a `-type` switch to the `devhelp` command that
makes it also display that information. Otherwise the command behaves
the same.
---
 src/frontend/device.c | 131 ++++++++++++++++++++++++++++++++----------
 src/frontend/device.h |   3 +-
 2 files changed, 104 insertions(+), 30 deletions(-)

diff --git a/src/frontend/device.c b/src/frontend/device.c
index a549edad7..aef4f9974 100644
--- a/src/frontend/device.c
+++ b/src/frontend/device.c
@@ -38,6 +38,7 @@ static void if_set_binned_model(CKTcircuit *, char
*, char *, struct dvec *);
  *   devhelp devname         : shows all parameters of that model/instance
  *   devhelp devname parname : shows parameter meaning
  *   Options: -csv (comma separated value for generating docs)
+ *            -type (show parameter types)
  */

 void
@@ -55,6 +56,7 @@ devhelp(wordlist *wl)
     int devindex = -1, devInstParNo = 0, devModParNo = 0;
     bool found = FALSE;
     bool csv = FALSE;
+    bool type = FALSE;
     wordlist *wlist;
     IFparm *plist;

@@ -74,13 +76,22 @@ devhelp(wordlist *wl)
         return;
     }

-    /* The first argument must be the csv option or a device name */
-    if (wlist && wlist->wl_word && eq(wlist->wl_word, "-csv")) {
-        csv = TRUE;
-        if (wlist->wl_next)
-            wlist = wlist->wl_next;
-        else
-            return;
+    while (TRUE) {
+        /* -csv or -type options can be passed as the initial arguments */
+        if (wlist && wlist->wl_word && eq(wlist->wl_word, "-type")) {
+            type = TRUE;
+            if (wlist->wl_next)
+                wlist = wlist->wl_next;
+            else
+                return;
+        } else if (wlist && wlist->wl_word && eq(wlist->wl_word, "-csv")) {
+            csv = TRUE;
+            if (wlist->wl_next)
+                wlist = wlist->wl_next;
+            else
+                return;
+        } else
+            break;
     }

     /* This argument, if exists, must be the device name */
@@ -123,11 +134,8 @@ devhelp(wordlist *wl)
                 found = TRUE;
                 out_init();
                 out_printf("Model Parameters\n");
-                if (csv)
-                    out_printf("id#, Name, Dir, Description\n");
-                else
-                    out_printf("%5s\t %-10s\t Dir\t Description\n",
"id#", "Name");
-                printdesc(plist[i], csv);
+                printheaders(type, csv);
+                printdesc(plist[i], type, csv);
                 out_send("\n");
             }
         }
@@ -139,11 +147,7 @@ devhelp(wordlist *wl)
                     found = TRUE;
                     out_init();
                     out_printf("Instance Parameters\n");
-                    if (csv)
-                        out_printf("id#, Name, Dir, Description\n");
-                    else
-                        out_printf("%5s\t %-10s\t Dir\t
Description\n", "id#", "Name");
-                    printdesc(plist[i], csv);
+                    printdesc(plist[i], type, csv);
                     out_send("\n");
                 }
             }
@@ -159,49 +163,63 @@ devhelp(wordlist *wl)
     out_init();
     out_printf("%s - %s\n\n", ft_sim->devices[devindex]->name,
ft_sim->devices[devindex]->description);
     out_printf("Model Parameters\n");
-    if (csv)
-        out_printf("id#, Name, Dir, Description\n");
-    else
-        out_printf("%5s\t %-10s\t Dir\t Description\n", "id#", "Name");
+    printheaders(type, csv);

     plist = ft_sim->devices[devindex]->modelParms;
     for (i = 0; i < devModParNo; i++)
-        printdesc(plist[i], csv);
+        printdesc(plist[i], type, csv);
     out_printf("\n");
     out_printf("Instance Parameters\n");
-    if (csv)
-        out_printf("id#, Name, Dir, Description\n");
-    else
-        out_printf("%5s\t %-10s\t Dir\t Description\n", "id#", "Name");
+    printheaders(type, csv);

     plist = ft_sim->devices[devindex]->instanceParms;
     for (i = 0; i < devInstParNo; i++)
-        printdesc(plist[i], csv);
+        printdesc(plist[i], type, csv);

     out_send("\n");
 }


+/*
+ * Print headers for printdesc()
+ */
+
+void
+printheaders(bool type, bool csv)
+{
+    if (type && csv)
+        out_printf("id#, Name, Dir, Type, Description\n");
+    else if (type && !csv)
+        out_printf("%5s\t %-10s\t Dir\t %-10s\t Description\n",
"id#", "Name", "Type");
+    else if (!type && csv)
+        out_printf("id#, Name, Dir, Description\n");
+    else /* !type && !csv */
+        out_printf("%5s\t %-10s\t Dir\t Description\n", "id#", "Name");
+}
+
+
 /*
  * Pretty print parameter descriptions
  * This function prints description of device parameters
  */

 void
-printdesc(IFparm p, bool csv)
+printdesc(IFparm p, bool type, bool csv)
 {
     char sep;
-    int spacer1, spacer2;
+    int spacer1, spacer2, spacer3;

     /* First we indentify the separator */
     if (csv) {
         sep = ',';
         spacer1 = 0;
         spacer2 = 0;
+        spacer3 = 0;
     } else {
         sep = '\t';
         spacer1 = 5;
         spacer2 = 10;
+        spacer3 = 10;
     }

     out_printf("%*d%c %-*s%c ", spacer1, p.id, sep, spacer2, p.keyword, sep);
@@ -214,6 +232,61 @@ printdesc(IFparm p, bool csv)
     else
         out_printf("out%c ", sep);

+    if (type) {
+        switch (p.dataType & IF_VARTYPES) {
+        case IF_FLAG:
+            out_printf("%-*s%c ", spacer3, "flag", sep);
+            break;
+        case IF_INTEGER:
+            out_printf("%-*s%c ", spacer3, "integer", sep);
+            break;
+        case IF_REAL:
+            out_printf("%-*s%c ", spacer3, "real", sep);
+            break;
+        case IF_COMPLEX:
+            out_printf("%-*s%c ", spacer3, "complex", sep);
+            break;
+        case IF_NODE:
+            out_printf("%-*s%c ", spacer3, "node", sep);
+            break;
+        case IF_INSTANCE:
+            out_printf("%-*s%c ", spacer3, "instance", sep);
+            break;
+        case IF_STRING:
+            out_printf("%-*s%c ", spacer3, "string", sep);
+            break;
+        case IF_PARSETREE:
+            out_printf("%-*s%c ", spacer3, "parsetree", sep);
+            break;
+        case IF_VECTOR: /* A few variables have only the vector
vartype bit set */
+            out_printf("%-*s%c ", spacer3, "vector", sep);
+            break;
+        case IF_FLAGVEC:
+            out_printf("%-*s%c ", spacer3, "flagvec", sep);
+            break;
+        case IF_INTVEC:
+            out_printf("%-*s%c ", spacer3, "intvec", sep);
+            break;
+        case IF_REALVEC:
+            out_printf("%-*s%c ", spacer3, "realvec", sep);
+            break;
+        case IF_CPLXVEC:
+            out_printf("%-*s%c ", spacer3, "cplxvec", sep);
+            break;
+        case IF_NODEVEC:
+            out_printf("%-*s%c ", spacer3, "nodevec", sep);
+            break;
+        case IF_INSTVEC:
+            out_printf("%-*s%c ", spacer3, "instvec", sep);
+            break;
+        case IF_STRINGVEC:
+            out_printf("%-*s%c ", spacer3, "stringvec", sep);
+            break;
+        default:
+            out_printf("%-*s%c ", spacer3, "?????????", sep);
+        }
+    }
+
     if (p.description)
         out_printf("%s\n", p.description);
     else
diff --git a/src/frontend/device.h b/src/frontend/device.h
index c047c07d2..1f8c7977b 100644
--- a/src/frontend/device.h
+++ b/src/frontend/device.h
@@ -23,7 +23,8 @@ void old_show(wordlist *wl);

 /* DEVHELP*/
 void devhelp(wordlist *wl);
-void printdesc(IFparm p, bool csv);
+void printheaders(bool type, bool csv);
+void printdesc(IFparm p, bool type, bool csv);



-- 
2.35.1

Re: [Ngspice-devel] Querying Ngspice for model parameters

[Mikołaj W. <wie...@gm...>]

I'm going to start writing the patch now. I'll give a short
explanation the changes I'm going to make,

The information about each parameter that is shown by the `devhelp`
command is stored in the following C structure in the ifsim.h header:

```
struct IFparm {
    char *keyword;
    int id;
    int dataType;
    char *description;
};
```

I'm going to add members that will store all the information I want to
be able to obtain from `devhelp`.

Each parameter defined in the <model>.c files is defined through
`IOP()`, `IOPP()`, `IOPA()`, and similar macros defined in devdefs.h.
I will modify these macros to work with the new IFparm structure,
however I won't modify their argument lists. Instead, for each of
these macros, I'll create an "extended" macro, correspondingly named
`IOPX()`, `IOPPX()`, `IOPAX()`, and so on. These macros will take more
parameters that will allow to set up the `IFparm` structure with the
new parameters. That way it won't be necessary to modify all parameter
definition lines, only the relevant ones, at least at once.

-Mikolaj

Re: [Ngspice-devel] Querying Ngspice for model parameters

[Mikołaj W. <wie...@gm...>]

> > As an extra, we would be
> > interested in also displaying example values and scale factors (as in
> > the Ngspice documentation).
>
> Could you elaborate a little more in this? What are example values?
> Where are scale factors used?

Example values and scale factors would be displayed for documentation
purposes. That's why they're just an "extra". Both of these fields are
displayed in the Ngspice documentation for some devices. For example,
they are displayed for BJTs in the table of the section this link
points to: http://ngspice.sourceforge.net/docs/ngspice-html-manual/manual.xhtml#magicparlabel-367247.

> > parameters in categories, so that the user would be able to show/hide
>  > the groups of parameters they are interested in.
>
> What kind of categories do you suggest?

Like the categories of the diode model in this section:
http://ngspice.sourceforge.net/docs/ngspice-html-manual/manual.xhtml#magicparlabel-365757

As you can see, diode model parameters are split into the following categories:

- Junction DC parameters
- Junction capacitance parameters
- Metal and Polysilicon Overlap Capacitances (level=3)
- Temperature effects
- Noise modeling

I expect most of the semiconductor model parameters to be
categorizable into at least "DC parameters", "Capacitance parameters",
"Temperature effect parameters", "Noise modeling parameters".

> >
> > 1. We can contribute patches to make `devhelp` supply the remaining
> > information. Would Ngspice accept them?
> >
> Yes, if they are 'compatible', complete and don't break anything. You
> may have noticed that some models use more than 400 parameters. Type and
> unit may be added to to the parameter tables available in <model>.c.
> With the default values it is a little more tricky because they are set
>   in <model>set.c only while a circuit is being parsed.

Obviously, displaying the additional information would be hidden under
a switch, probably "-all".

Do you agree for these parameter tables to be extended in the
<model>.c files? Yesterday I took a look at that code, and a
substantial amount of lines in many files, as well as the structure
holding each parameter, appear the same as in the original Spice 3f5
from 1993. Is changing a substantial amount of code lines that have
been doing their job for 29 years any problem?

> > 2. Is there any Ngspice shared library API to query for the parameters
> > along and their properties without having to parse a command output?
> > We may try to contribute that as well.
> >
>
> There is no API right now. Changing the API would only be possible by
> enhancing it, keeping compatibility. This could for example be done by
> adding a new setup function for accessing new export functions. This
> setup could have several spare (NULL) entries to allow later adding new
> export functions without changing compatibility again. But as long asa
> command exists, I would suggest not to touch the API.

Then we'll just parse the command output on the KiCad side.

-Mikolaj

Re: [Ngspice-devel] Querying Ngspice for model parameters

[Holger V. <hol...@un...>]

Mikolaj,


> As an extra, we would be
> interested in also displaying example values and scale factors (as in
> the Ngspice documentation). 

Could you elaborate a little more in this? What are example values? 
Where are scale factors used?



> parameters in categories, so that the user would be able to show/hide
 > the groups of parameters they are interested in.

What kind of categories do you suggest?

> 
> 1. We can contribute patches to make `devhelp` supply the remaining
> information. Would Ngspice accept them?
> 
Yes, if they are 'compatible', complete and don't break anything. You 
may have noticed that some models use more than 400 parameters. Type and 
unit may be added to to the parameter tables available in <model>.c. 
With the default values it is a little more tricky because they are set 
  in <model>set.c only while a circuit is being parsed.

> 2. Is there any Ngspice shared library API to query for the parameters
> along and their properties without having to parse a command output?
> We may try to contribute that as well.
> 

There is no API right now. Changing the API would only be possible by 
enhancing it, keeping compatibility. This could for example be done by 
adding a new setup function for accessing new export functions. This 
setup could have several spare (NULL) entries to allow later adding new 
export functions without changing compatibility again. But as long asa 
command exists, I would suggest not to touch the API.


Holger

[Ngspice-devel] Querying Ngspice for model parameters

[Mikołaj W. <wie...@gm...>]

Hi,

As you know, KiCad is developing a new interface for Spice simulation.

One of the things we would like to have in our GUI is a list of
parameters for a particular device model. Next to each parameter, we
would like to display its properties: its description, physical unit,
type (e,g, integer or float), default value. As an extra, we would be
interested in also displaying example values and scale factors (as in
the Ngspice documentation). It would also be nice to put the
parameters in categories, so that the user would be able to show/hide
the groups of parameters they are interested in.

We'd like to obtain this parameter information straight from Ngspice,
instead of writing and maintaining our own data table. Using the
`devhelp` command we can query for a list of parameters for each
device model along with their directions (in, out, inout) and
descriptions. However, the other information is missing.

I'd like to ask some questions:

1. We can contribute patches to make `devhelp` supply the remaining
information. Would Ngspice accept them?

2. Is there any Ngspice shared library API to query for the parameters
along and their properties without having to parse a command output?
We may try to contribute that as well.

-Mikolaj

Re: [Ngspice-devel] Further questions on contributing to ngspice

[Holger V. <hol...@un...>]

The link to Fabien Corona's work is here:

https://gitlab.com/Drinausaur/kicad/-/tree/ibis

Re: [Ngspice-devel] Further questions on contributing to ngspice

[Holger V. <hol...@un...>]

Concerning IBIS modeling:

Chip manufacturers distribute IBIS models for their (digital) products, 
see for example 
https://www.microchip.com/doclisting/techdoc.aspx?type=ibis .

IBIS models do not describe the inner functionality of a circuit, but 
the behavior of input and output ports. Parasitics (LRC) of the chip 
packages may be included.

They may be used to simulate (with the help of a circuit simulator) the 
interconnects between different chips.

So you need a driver (parametrized by the IBIS model parameters for chip 
number 1), a receiver (also parameterized by the IBIS model parameters 
for chip number 2) and the interconnect, e.g. on a PCB, described by 
RCLG lumped elements and/or transmission lines (user provided, not 
provided by the IBIS model).

The simulator then determines waveforms and delivers an information on 
signal integrity.

All commercial simulators are more or less supporting IBIS. Micro-Cap 
and PSPICE seem to translate the IBIS model data into equivalent 
circuits to run such a simulation.

I am not an IBIS specialist, but I would imagine the following:

   Read and parse the IBIS model file data.

   Use an appropriate driver or receiver circuit model (as probably 
given in the IBIS specs), in conjuntion with ngspice provided current or 
voltage sources that have their output from tables (PWL: piece-wise 
linear sources). There are several available in ngspice.

   Driver and receiver are delivered by ngspice with their IBIS data 
driven outputs and inputs, interconnect circuits are delivered by the 
user (simple RC would be sufficient in the beginning, more sophisticated 
transmission line models are available in ngspice).

   Run the (transient) simulation.

   Evaluate the resulting waveforms (manually for now)

How to start?

*********************************************
Become aquainted with the IBIS specs.

Check what other simulators are offering (spectre, ADS, PSPICE, 
Micro-Cap ...)

Run some tests (may be on Micro-Cap, which is now freely available at 
http://www.spectrum-soft.com/download/download.shtm )

Set up a specification for integrating IBIS into ngspice (what to offer 
and how to integrate it, what IBIS version to support etc.).

Generate a parser to read the IBIS parameter files.

Set up a ngspice circuit construct with suitable table controlled elements.

Fill the circuit construct with the data from the parser.

Set up a simulation environment.

Run the simulation, using a known test case.
************************************************


No work has been started on integrating IBIS directly into ngspice. Some 
activity has been proposed to integrate IBIS into KiCad (see discussions 
at https://lists.launchpad.net/kicad-developers/msg45312.html ff), and 
use ngspice as the simulator, which I think is not the optimum approach. 
But I have not heard any news from Fabien Corona. Maybe you want to 
contact him.

Unfortunately I cannot tell you or guarantee any size of the amount on 
the efforts you will have to spend.

[Ngspice-devel] Further questions on contributing to ngspice

[Sujay Chuttar. <suj...@ni...>]

Thank you Dr. Holger Vogt, John Doty and others who reached out to us.
Really helped us understand more about the clientele of ngspice.


We are planning on working on this project until the end of March 2022. We
will be able to devote 5 hours per week.


Relating to the ideas Dr. Holger shared in the mail he wrote we have the
following questions


ADMS interface



   1.

   What is the current state of ADMS?

>From our understanding of the problem, we want ADMS to support more verilog
A constructs.And currently it supports conversion of 4 models

Source of information: http://ngspice.sourceforge.net/admshowto.html



   1.

   https://en.wikipedia.org/wiki/Ngspice XML filters used by ADMS do not
   support many devices and programming constructs.So we should focus on
   overcoming the limitations mentioned one at a time, or do you have any
   specific limitation on your mind that we can take on.



Upgrading event driven simulation

   1.

   What work needs to be done in relation to this?



Add IBIS modelling

   1.

   Is this about building an interface to automate IBIS to SPICE model
   conversion or vice versa?

2. From https://www.tina.com/ibis-simulation/ we have gathered that TINA
spice allows specification of components using IBIS models. Does Ngspice
need a similar feature?

Re: [Ngspice-devel] Advice on contributing to ngspice

[John D. <jp...@no...>]

> On Oct 15, 2021, at 5:22 PM, Holger Vogt <hol...@un...> wrote:
> 
> John,
> 
> thanks for the info.
> 
> I have just scanned the manual at https://lepton-eda.github.io/lepton-manual.html/index.html#SEC_Contents .
> 
> In the table of contents there is not a single mention of ngspice.
> 
> So does this really provide an interface to ngspice?

The examples at https://github.com/noqsi/gnet-spice-noqsi/wiki <https://github.com/noqsi/gnet-spice-noqsi/wiki> all use Lepton to feed ngspice, although I haven’t expunged all references to gEDA in the text. They probably still work with gEDA, too, but I haven’t used gEDA in years.

> 
> Holger
> 
> 
> _______________________________________________
> Ngspice-devel mailing list
> Ngs...@li...
> https://lists.sourceforge.net/lists/listinfo/ngspice-devel
> 

John Doty              Noqsi Aerospace, Ltd.
jp...@no...