[Top][All Lists]

[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

From: Hugo Coolens
Subject: [Help-gnucap] Re: using a pipe to make gnucap accept input from other program
Date: Thu, 11 Jan 2007 08:33:57 +0100
User-agent: 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 parts

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"

thanks, that is exactly what I needed

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 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

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++))
      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'
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.
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?

best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]