gEDA-user: Updated spice-sdb available (version of 9.9.2003)

[sdb@cloud9.net (Stuart Brorson)]

Hello --

I have been busily hacking away on spice-sdb for the last few days, at
least partially due to popular demand for some features, as well as
the realization that there were a few (minor) bugs in the code.  I
think I am ready for another release.  Here's what's new:

*  I have introduced a -I flag to gnetlist.  If you set -I when
   netlisting using spice-sdb, then .MODEL and .SUBCKT files are *not*
   included in the output netlist.  Instead, a .INCLUDE <filename>
   card is inserted.  If you don't set -I, then the model file's
   contents are dumped into the output netlist, as usual.  The impetus
   for this feature came from Wojciech Kazubski.

*  I made the  spew depend upon the -v command line flag.  In
   the past, my prog just spewed its progress whether you wanted to
   see it or not.  Now, if you want to see what it is doing while
   processing your schematic, you must set the -v (verbose) command
   line flag. 

*  I moved some of the command line processing functions into
   gnetlist.scm so that other people may use them in their
   netlisters.  There are two relevant functions here:

   --  calling-flag? 
       This returns #t or #f depending upon if searched-4-flag was set in
       calling-flag-list.   Calling form:
       (calling-flag? searched-4-flag calling-flag-list)
       Note that you will usually call it using the calling flags from
       the command line.  Therefore, the usual calling form is:
       (calling-flag? searched-4-flag (gnetlist:get-calling-flags))

       The valid searched-4-flag values are: verbose_mode,
       interactive_mode, quiet_mode, include_mode, sort_mode.  More
       info is available by perusing src/parsecmd.c.  To add support for
       your command line flags, you need to edit src/parsecmd.c,
       src/globals.c, and include/globals.h.

   --  debug-spew
       This is a fcn which outputs text to STDOUT if the -v flag was
       set.  Otherwise it does nothing.  Calling form:
       (debug-spew "verbose debug text . . .\n")

*  I fixed a bug in which parts with a refdes U, and a model-name 
   but no attached file attribute would not get an 'X' prepended to
   the refdes if the model was a .SUBCKT.  The old work-around was to
   name all parts having a .SUBCKT model in a file with 'X' 
   instead of 'U' refdeses.

   I simultaneously fixed a bug noticed by others in which a model
   file which was referenced multiple times would be put in the output
   netlist multiple times.

   To accomplish this, I built upon the suggestion of Carlos Nieves
   Onega and Wojciech Kazubski to construct a list of model files in
   order to keep track of which files had been previously used.
   I generalized their idea by building a proper two-pass compiler:
   The first pass finds all .MODEL and .SUBCKT files and constructs a
   list of them and their properties.  The second pass then outputs
   all the spice cards.  It turns out that you need to know what type
   of model you have during this second pass through the circuit in
   order to handle the X and U refdeses correctly.  After that, I run
   through the model file list and write out the model files. 

*  I have one remaining bug which was pointed out to me by Tom Russo.
   He says:

   "According to your documentation, when labeling the
   spice-subcircuit-IO-1.sym pins I should label them in lexicographic
   order (P1, P2, P3), and they'll appear in that order in the .SUBCKT
   line.  But in all the tests I've done so far I find that it
   actually labels them in exactly the opposite order!"

   I checked this out, and found that what he says is true.  The bug
   is due to the fact that the list of IOs I create when building a
   .SUBCKT is done using recursion, instead of e.g. a do loop.
   (Notice my Fortran heritage. . . .)  Therefore, the list is
   constructed from back to front, instead of the other way around.

   So now my question:  I can easily fix this bug by reversing the
   list before I return from the function which creates the .SUBCKT
   IOs.  However, if I do this, then all hierarchical schematics built
   which use this facility will break.  Do people care if I fix it?
   Does anybody out there have legacy schematics incorporating
   file-based models which they simulate using spice-sdb?  Are you
   prepared to fix your schematics?

   I see three options:

   1.  Just fix it & let people's hierarchical schematics (if there
       are any) break.  To fix the breakage, you just need to reverse
       the order of the SUBCKT-IO-PINS in your .SUBCKT schematics.  No
       big deal.

   2.  I could make the fix a command line option, so that if you have
       legacy schematics, you need to netlist with -L (for legacy)
       set.

   3.  I could just leave well enough alone.  But then the
       documentation won't match spice-sdb's behavior.  :-(

   Please voice your opinions like people vote in Chicago: early and
   often.  I am inclinded to option 1, but will change course if there
   is sufficient outcry.

As always, the new stuff is available at my website:

http://www.brorson.com/gEDA/SPICE/

I have built it against gEDA-20030901, although it should also build
against 20030525 if you install the additional files I provide.  To
use it, you will need to 
stick the files in the places directed, and then re-build & re-install
gnetlist.  

Please send my your opinions about fixing the .SUBCKT IO pin bug, as
well as any other suggestions/complaints/flames.

Stuart