Re: [Help-gnucap] named nodes

[al davis]

On Wednesday 10 May 2006 15:52, Vadim through wrote:
> I just tried out both the 0.34 release and the latest
> (gnucap-2006-05-06.tar.gz)
> built fresh from source. It seems that named nodes don't work
> correctly in either.

Named nodes work in recent development snapshots, but not in 
0.34.

0.34 has an undocumented option "namednodes" that allows it to 
read netlists with named nodes, converting to numbers on read 
in.  From then on, everything is by number.  It is there only 
as part of incomplete code for a future feature, and useful 
only as a translation mechanism.

Recent development snapshots, within the last year, have full 
support for named nodes.  The option "namednodes" has been 
removed, because nodes are always named.

>
> Here's the input:
>
> * This is a comment
>
> .option namednodes
>
> Vin x 0 1 ac 1
> rin x 2 1k
> cin 2 0 1p
>
> .op
> .print op x v{x} v(x) v(2)
> .end

I see two problems:
1. The syntax of the print statement is incorrect.
2. The print statement is placed incorrectly.

The problems here are not related to named nodes.  Since they 
are not, I will only explain what 2006-05-06 said..

> and the latest build gives this:
> $ gnucap-2006-05-06/src/O/gnucap -b myfile.gc
> Gnucap 2006.05.06 RCS 25.82
> The Gnu Circuit Analysis Package
> Never trust any version less than 1.0
> Copyright 1982-2002, Albert Davis
> Gnucap comes with ABSOLUTELY NO WARRANTY
> This is free software, and you are welcome
> to redistribute it under certain conditions
> according to the GNU General Public License.
> See the file "COPYING" for details.
> * This is a comment
> option namednodes
>        ^ ? what's this?
There is no option "namednodes".  It was only there as an 
undocumented way to enable some incomplete development code, 
which is now complete and non-optional.


> #
>  27.

You need to put the print statement before the op command.  
Otherwise it doesn't print anything.  This behavior is 
different from Spice, but much more flexible.

> print op x v{x} v(x) v(2)
>            ^ ? no match
> print op x v{x} v(x) v(2)
>                 ^ ? no match
> print op x v{x} v(x) v(2)
>                   ^ ? need )
> print op x v{x} v(x) v(2)
>                    ^ ? need device or node
> print op x v{x} v(x) v(2)
>                      ^ ? need )

This line is syntactically incorrect.

1. Just listing the name of something (x) is not enough.  You 
need to specify what about it you want to see.  That is v(x) if 
you want the parameter v of x, which is usually voltage.

2. v{x} is incorrect.  The curlys are incorrect here.  Use v(x).

The multiple messages result from parsing getting out of sync.  
Sometimes after the first error, others are suspect. 

> Also, is there support for libraries, of the sort Dan
> mentioned on Wed, 18 Jan 2006 21:53:17 -0500 on Gnucap-devel?
> Foundries generally give a set of binned models of devices
> rather
> than a single model, and library support would make it
> feasible to at least compare gnucap to Spice (or in my case,
> Spectre.)

Binning has been supported for a long time.  I believe the 
format is HSPICE compatible.  ".param" also works, but with no 
expressions yet, and all .param statements are interpreted as 
if they are in the global scope.  Note that I didn't say 
parameters, I said ".param statements".  Scoping is correct 
with other methods of assigning values to parameters, such as 
passing values to subckts.

Unlike some other simulators, you can change a param and rerun 
any time.  Parameter substitution is at run time, not read 
time.

The ".LIB" statement is not done yet.