Re: gEDA: some observations/experiences with geda as a simulation frontend

[sdb-at-NOSPAMcloud9_dot_net (Stuart Brorson)]

> 
> 
> Inspired by Stuarts recent work on the spice backend for gnetlist, I wrote
> a switcap backend and created a set of symbols for it.  This experience
> has brought out a few items of note which can be a bit of a pain in using
> geda for driving simulations.  They are (in no particular order):
> 
> 
> - some simulators like switcap have restrictions on node name length.
>   With switcap, this is 7 characters which makes 'unnamed_net37' not work. 
>   It wouldn't suprise me if some other simulator somewhere doesn't like
>   nodes to have anything other than numbers.

In the C code, there is a mode you can set (SPICE_MODE or something
like that) which suppresses the long net names, and replaces them with
net numbers a la SPICE classic.  This could presumably be generalized
to e.g. SHORT_NETNAME_MODE for other net name formats.

(The question here is, if I'm gonna hack the C code, how do I check in
my changes with the main developent branch?  Ales, do you oversee
development?  What changes get into the code base & how is the
decision made?  I suppose I need to learn how to handle CVS. . . . .)

> - it would be quite nice to be able to have the schematic show the
>   netnames without having to manually name them all.  The reason for this,
>   is you might do a spice simulation and then decide you want to plot 
>   some node which you didn't explicitly name.  In the current approach,
>   you're pretty much stuck since nets without explicit names don't get
>   named until gnetlist is run.

The problem here is that -- at least in SPICE -- the nets are renamed
by the netlister, so knowing what they are in gschem doesn't tell you
what they will be in the netlist.

(Although they may be related. . . . I need to look.)

> - this last one is probably a much bigger task, but it might be nice to be
>   able to use scheme to create some sort of GUI for setting up analyses.
>   I've been trying to finish up the switcap support by adding some symbols
>   which will cause an analysis statement in the netlist.  The problem is
>   its a bit cumbersome to deal with all the possible options you might
>   want.  For the current system, I'll probably just have an include file
>   element where you can have it insert a text file with the analysis
>   commands.

The same holds in SPICE -- you need to embedd the analysis commands in
the netlist.  What I have done is this:

1.  Put the analysis commands in a file "Simulation.cmd".

2.  In the schematic, embedd a .INCLUDE pointing to "Simulation.cmd".

3.  I then run LTSpice to do the analysis.  If I want to change the
simulation I just edit "Simulation.cmd" & re-run LTSpice.  Since
LTSpice reads the .INCLUDE at run time I don't need to edit the
schematic & re-netlist just to do a different analysis.

Of course, this is more cumbersome than just having SPICE analysis
built into gschem's GUI.  Ideally, gschem would have a SPICE analysis
pull-down menu just like MicroSim's old "Schematics with PSpice", or
Orcad.  Doing this, however, is a very big project. . . .

> All in all though, it was pretty easy and pretty quick to produce a
> working backend (which I will post here after a little more testing and
> verification).

Yup.   It was easy and fun.  Although I was originally a little leery
about dealing with Scheme, in retrospect it was quite easy to hack.

Stuart