Re: [Help-gnucap] Re: using a pipe to make gnucap accept input from other program

[al davis]

On Wednesday 10 January 2007 04:23, Hugo Coolens wrote:
> Can you give me some examples of those features?

You can interactively change the circuit and re-analyze.  That 
is arbitrary changes, not just value changes.

You can build a circuit interactively.  You can partially build 
and test, just like you would do with a real circuit.

Expressions as component values (unfortunately not complete 
expressions, but it's a start.)

A Fourier analysis that works well enough to do distortion 
analysis.

You can do AC analysis at a point in time.  Contrast -- Spice 
lets you do AC only at a stable operating point.

You can continue a transient analysis, possibly with changes to 
values and options.  This lets you do things like start an 
oscillator with coarse control then tighten the specs and do a 
detailed analysis in steady state.

You can do a DC sweep on any simple value, not just sources.

You can probe lots of internal values in models.  You can probe 
current, power, port impedance, etc on most devices.  This is 
not just for DC.  It works in transient too.  

It has a true mixed-mode engine, that enhances performance even 
for linear circuits.

The ".param" command lets you use a named parameter as a value.  
You can change it interactively.

Parameterized subcircuits.

Some HSPICE compatible behavioral elements.

A model compiler that works.  (Does anyone use 
XSPICE "code-models"?)

Commands can be directed to a file or pipe.

The next official release will support plug-ins.  Models, 
functions, and commands can be added as plug-ins.  With a 
simple wrapper, Spice models can be used as plug-ins with no 
changes.  The latest development snapshot supports plug-ins.


> > Spice has some features gnucap does not have.

Models.

NG-spice adds more models, "XSPICE" extensions which give it 
limited mixed-mode capability and a poor model compiler,

Commercial Spice derivatives add assorted other stuff, each one 
different from all others.


> > You could 
> > have the same problem moving between versions of spice.
> > Maybe you could post your script, some data, and what it
> > does. In your mail, put it in line as plain text, not as an
> > attachment.  Attachments really mess up the digest and
> > archives.
>
> Here is the script (it produces cascaded normalized
> RC-sections) 

Thanks -- I understand now.
> Save it to a file called makespicefile, chmod 
> 755 makespicefile and try ./makespicefile 2
> then you see the inputfile for an rc-filter with two sections
> if you execute ./makespicefile 2 |spice you'll see the result
> immediately. 

> Gnucap however does not accept the standard unix 
> way to handle pipes unfortunately. 

Yes it does accept the standard unix way, but stdin as a pipe is 
compatible with the interactive mode, not the Spice batch files.  
It is more in line with the Verilog simulators of the future.

Gnucap is designed (back around 1980) to have the main input be 
commands, and you load the circuit as a separate file, (or enter 
it with the "build" command).  The idea is that extracting from 
a schematic just gives you a circuit.  Just load it, then do 
the commands separately.  I have found this way to be much more 
useful for real work.  Gnucap input is more like a script, 
where Spice is more like a checklist.

Now I see what you are asking for ..  You want the stdin pipe to 
act like the "-b" batch mode, and would probably accept 
the "-b" option with no file to represent that. 

How about:

"./makespicefile 2 | gnucap -b /dev/stdin"

That works for me.

I thought of changing it, but I am planning to change the native 
language to Verilog-AMS anyway, and getting Spice language 
support with a plugin.  To change it now will mean changing it 
again soon, and I would rather change it only once.

With the plugin approach, the compatibility could be exact.  A 
choice of plugins could make exact compatibility with several 
versions of Spice.

> when you start making real large circuits this is not elegant
> to do and a waste of time and resources.
> The script can be used to produce real large circuits to
> compare different spice-versions (accuracy, maximum number of
> nodes ...)

I am not convinced that you get a meaningful comparison this 
way.  I would like to know what you find out.

I have found that usually gnucap is faster than spice.  There 
are cases where spice is faster, but not by much.  I have test 
cases where gnucap is a lot faster, including one that takes 40 
seconds for gnucap, 8 hours for ng-spice.  Gnucap run time is 
roughly linearly proportional to size.  Spice run time is 
quadratic.  Circuits that are small, very connected, and very 
nonlinear tend to run faster in Spice.  Circuits that are 
large, sparsely connected, have significant linear or nearly 
linear content, tend to run faster in gnucap.  Gnucap AC 
analysis is nothing special, except you should get linear time 
instead of quadratic.


> The script:
>
> #! /bin/bash
> #use: makespicefile number_of_sections
> echo 'test'
> echo 'vin 1 0 ac 1'
> for ((i=1; i<$1+1 ; i++))
>      do
>        echo r$i $i $((i+1)) '1'
>        echo c$i $((i+1)) 0  '1'
>      done
> echo '.print ac' 'v('$i')'
> #print-statement _before_ analysis necessary for gnucap
> echo '.options numdgt=7'
> echo '.ac dec 20 10m 1000 basic'
> echo '.end'

The "print statement before analysis" is done for good reasons.  
For one, analyzing and saving "all data" is very inefficient, 
and you don't really save "all data".  This is what lets you 
probe anything.  Really saving "all data" including internal 
values of models would really be inefficient.  The way it is, 
you pick what you want to see, and are not burdened with what 
you don't care about today.

In real life, you attach probes to a circuit, then turn it on 
and observe the instruments.  The gnucap way is more like the 
real lab.

The reason Spice does it the way it does goes back to the small 
computers of the 70's, where you needed overlays to fit a large 
program into small memory.  It is a multi-pass system.  
The "raw file" is the interface between the simulator engine 
and a post-processor.  Computers are bigger now, so we don't 
need to do it that way anymore.