Re: [Gnucap-devel] SPICE to gnucap transition

[al davis]

On Saturday 17 March 2007 13:30, Scott Dattalo wrote:
> (perhaps this should go to the 'help-gnucap' list?)

Try it.  You will get a more user oriented answer there.

> I'd like to give gnucap a chance. I suspect most potential
> gnucap users are similar to me: familiar with SPICE but
> wishing for something 'better'.
>
> 1) What is the recommended approach for users wishing to
> transition from SPICE to gnucap?
>
> So far, I've done the following:
>
>  - looked at the GNUCAP website
>  - looked at the mailing list archives for ~ last 6 months.
>  - downloaded and installed the snapshot release from 21FEB07
>  - learned the basic overview of gnucap from
> man/gnucap-man.pdf - ran a few of the examples in examples/
>  - tried (but failed) to run gnucap on some sample SPICE
> decks

The most common failure has to do with sorting of commands.  
Gnucap treats the file as a script.  Spice treats it as a box 
of cards.  The order of commands matters to gnucap.  It does 
not matter to spice,

The most common issue with that is the ".print" command and the 
analysis commands.  Spice users think of doing the analysis in 
the background, saving "everything", then printing only some.  
Spice users have a very narrow notion of what is the meaning 
of "everything".  They typically don't realize that there is 
more to simulation than node voltages.

Gnucap is closer to what you do with a real breadboard.  You 
attach probes, turn it on, and observe what happens.

Gnucap is designed primarily to run interactively, secondarily 
in a script style,  Spice is designed primarily to run as a box 
of cards, checklist batch.  Scripting through ".control" was 
added later.  Interactive operation through nutmeg was added 
later.  Both after the script style in gnucap (ACS) was already 
done.

There is a need for documentation here.  If you want to help, it 
would be very much appreciated.  I have been concentrating on 
enhancing the program itself, with the idea that the transition 
will come in time.

Compatibility will improve when the language plug-in capability 
is working, but actually I consider Spice to be very crippled.  
For a real challenge, try to move the other way .. gnucap to 
spice, and see what is missing.

If you tell us the specifics about the ones that don't work, I 
my be able to help more.

There are also issues with models.  This is better now with 
plugins.  Most of the spice models work as plugins, including 
the new BSIM460, just released by Berkeley in December.


> 2) Are there any gnucap unit-test style examples?

I do have a test suite that I probably should package up.


> For example, most people familiar with electronics will
> understand basic things like say the step response of an RC
> low pass filter. Has anyone designed a set of examples that
> attempt to minimize circuit complexity but maximize gnucap's
> capabilities? I google'd around but didn't find anything
> useful.

Not much.  I agree that it is needed.  

> 3) What is the preferred waveform viewer? From the archives
> it appears that gwave is the one. (Or, at least gwave is the
> only one that accepts the ASCII tabular output of gnucap.)

gwave ..

I find it strange that gwave is the only one that accepts the 
gnucap files.  The gnucap files can be read by anything that is 
not spice specific, easily.  The only viewers that have a 
problem are the ones specifically written for the bizarre 
format that spice uses.  There are many of these.

gwave was not written for gnucap.  The reader that reads gnucap 
files was originally written for CaZM. By some stroke of magic, 
gnucap and CaZM use the same file format, even though neither 
project knew about the other at the time.  Maybe that is 
because the format is obvious.

You can also read the files with gnuplot, octave, most 
spreadsheets, and many others.

There are plans to have output plugins, which will make the 
interface to postprocessor programs better.