Re: gEDA-user: simulation advice

[al davis <ad136@xxxxxxxxxxxxxxxx>]

On Tuesday 03 April 2007 11:17, Patrick Doyle wrote:
> ok, attached (perhaps) is a tarball of my work-in-progress
> directory, including my gschem schematic, my models
> directory, my Makefile that runs gnetlist (and ngspice).  I
> just checked before I packaged it up, and my version of
> Gnucap still doesn't like the netlist when I invoke it as:
>
> $ gnucap mictest.ckt

The reason it works with ng-spice and not gnucap is that it was 
written for ng-spice not gnucap.

Gnucap doesn't have levels for the BJT unless you use plugins.  
You uncovered a bug that came about with the plugins -- in how 
it handles that.  The old version would just ignore the level 
keyword.  The current one got an error because it only found 
a "PNP" with no level, as opposed to a PNP level 1.  The bug is 
that the arrow points to the wrong place.  Spice 3f5 would not 
accept the level either.  It still gets a warning on the "NK" 
parameter, and ignores it.  That is the same in gnucap or 
ngspice, or in gnucap with spice3f5 of ngspice models.

Since you mentioned it, and I didn't think of it before, it is 
easy to change it, so I did ..

Here's the patch ..
in the file "d_bjt.model"
Find:
  public_keys {
    NPN polarity=pN;
    PNP polarity=pP;
  }
Change it to:
  public_keys {
    NPN polarity=pN;
    PNP polarity=pP;
    NPN1 polarity=pN;
    PNP1 polarity=pP;
  }
 -- and recompile.

There is a way to make it as a plugin, so you don't need to 
recompile, but I will skip it for now.

This model would have problems with the old version because of 
the extra blank lines embedded between extended lines.  There 
is no spec on the spice format, so I made it to what seemed 
correct, it worked for everything I did.  Later, I found out 
that spice allows blank lines and comments inside extended 
lines.  That is fixed in the snapshot.  The old one is an 
example of where, although it isn't really a bug, the 
compatibility isn't perfect.  It underscores a big reason why 
moving away from the spice format is long overdue.

Then you have the ".include Simulation.cmd" in the middle of the 
circuit description.  Inside it, you have the print after the 
tran command.  You need to put that before, because in gnucap 
that means "attach probes here".  So you get a transient run 
with no instrumentation hooked up.  That (the commands) are 
another place where the compatibility is not perfect.  The way 
gnucap does it brings in big advantages with the ability to do 
multiple analyses that I don't want to give up.  I really need 
to write up that class-B amplifier example to show why.

Putting the simulation commands in the middle of the circuit 
description gives you a simulation of the part of the circuit 
you have up to that point.  It works, but gives a different 
result than the whole circuit would.  This is another 
difference between gnucap and spice.  The gnucap way allows you 
to build a circuit in steps and test after each step.  Build 
part, test it, build another stage, test it.  Or .. build it, 
test it, change it, test again, ...  You can't do this in 
spice.

Usually I prefer not to put commands in with the circuit 
description anyway.  For real work, either I run it 
interactively or make the command script a separate file from 
the circuit.  I like being able to do it either way.



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user