[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Help-gnucap] Re: using a pipe to make gnucap accept input from other pr
[Help-gnucap] Re: using a pipe to make gnucap accept input from other program
Thu, 11 Jan 2007 08:33:57 +0100
Debian Thunderbird 1.0.2 (X11/20061113)
al davis wrote:
Thanks for the reply Al. It clarifies lots of things. Because the
message has become rather large, I hope you don't mind I just quote some
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.
"./makespicefile 2 | gnucap -b /dev/stdin"
thanks, that is exactly what I needed
I have used it to discover the maximum number of nodes some
Spice-version accept. I didn't perform "speed tests" with it yet.
If I found an example which demonstrates differences in accuracy I'll
let you know
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
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.
I understand what you mean but wouldn't it be nicer to have gnucap do
itself the task of choosing the right statement order when using batch-mode?
#use: makespicefile number_of_sections
echo 'vin 1 0 ac 1'
for ((i=1; i<$1+1 ; i++))
echo r$i $i $((i+1)) '1'
echo c$i $((i+1)) 0 '1'
echo '.print ac' 'v('$i')'
#print-statement _before_ analysis necessary for gnucap
echo '.options numdgt=7'
echo '.ac dec 20 10m 1000 basic'
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
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.